Un agente no debería escribir directamente en el ERP o WMS
Por Equipo Quantum Developers
Resumir:
Tesis operativa
Un agente puede decidir que una recepción debe corregirse, pero no debería construir por sí mismo una llamada específica al WMS y ejecutarla con una credencial amplia. Entre la decisión y el sistema de registro debe existir una intención gobernada, idempotente y verificable que un adaptador especializado traduzca y pueda reconciliar. Esa frontera protege tanto al ERP como al agente de cambios semánticos, reintentos y estados inciertos.
Microsoft describe la capa anticorrupción como una fachada o adaptador que traduce entre modelos para impedir que la semántica de un sistema contamine otro. Aquí, su trabajo no es ocultar el ERP: es preservar sus reglas mientras el agente habla en términos de objeto y resultado de negocio.
La arquitectura de intención
Separe cinco responsabilidades:
- Agente: interpreta evidencia y propone una intención limitada.
- Política: valida elegibilidad, permisos, límites y aprobación.
- Registro de intención: asigna identidad, versión y estado duradero.
- Adaptador ERP/WMS: traduce, valida precondiciones y ejecuta con privilegio mínimo.
- Reconciliador: consulta el sistema de registro y confirma, compensa o escala.
El agente nunca recibe una credencial capaz de escribir libremente. Tampoco decide nombres de tablas, transacciones o códigos internos. Su salida es un comando de negocio cerrado: reservar inventario, proponer ajuste, crear borrador de orden o bloquear expedición, con esquema y versión.
Artefacto: contrato de integración
| Campo | Función |
|---|---|
| intent_id | identidad global e inmutable |
| idempotency_key | identifica la misma intención en reintentos |
| business_object | tipo, ID y versión esperada |
| operation | verbo permitido del catálogo |
| requested_state | cambio de negocio solicitado |
| preconditions | estado, saldo, versión o autorización esperados |
| evidence_refs | documentos y eventos que justifican |
| policy_version | regla que autorizó la solicitud |
| approval_ref | aprobación independiente cuando aplica |
| actor | agente y principal técnico ejecutor |
| expires_at | momento después del cual no puede actuar |
| compensation | operación o runbook ante resultado no deseado |
| correlation_id | vínculo con trazas, logs y resultado |
| outcome | estado confirmado por el sistema de registro |
El contrato se versiona. Un adaptador rechaza campos desconocidos o una versión no compatible; no intenta “adivinar”. La precondición evita que una decisión tomada sobre inventario anterior se aplique a un estado nuevo.
Idempotencia con semántica de negocio
Las redes fallan en el peor momento: después de enviar y antes de recibir respuesta. AWS explica en Making retries safe with idempotent APIs que una clave aportada por el cliente permite reconocer reintentos de la misma solicitud, y también advierte sobre solicitudes tardías y parámetros distintos bajo la misma intención.
La clave no debería ser un hash ingenuo de campos. Dos ajustes idénticos en importe pueden ser operaciones legítimas diferentes. Un mismo intent_id reintentado debe devolver el resultado anterior; una intención nueva obtiene identidad nueva. El adaptador almacena clave, huella semántica, estado y respuesta. Si la misma clave llega con datos diferentes, rechaza y alerta.
Idempotencia no significa que toda operación sea segura. Significa que el sistema puede distinguir “repetir la misma intención” de “crear otra”.
Máquina de estados y resultado incierto
La intención recorre estados explícitos:
propuesta → autorizada → despachada → confirmada, con ramas rechazada, expirada, incierta, compensando y compensada.
“Despachada” no equivale a confirmada. Si la conexión se pierde, el reconciliador consulta por referencia externa, objeto y versión. Solo si el sistema autoritativo demuestra que no ocurrió puede reintentar. Si no puede saberlo, el caso queda incierto y sale de la automatización general.
El evento final incluye ID nativo, versión nueva, hora y estado leído después de la escritura. Un código HTTP exitoso sin verificación no siempre demuestra el resultado de negocio.
La compensación no es Ctrl+Z
En procesos distribuidos, no siempre existe rollback atómico. El patrón de transacción compensatoria plantea registrar cómo deshacer pasos completados cuando una operación de varios sistemas falla, reconociendo que la compensación depende del dominio y puede no ejecutarse en orden inverso.
Cancelar una reserva, emitir una nota o crear un movimiento correctivo son nuevas acciones con su propia autorización y evidencia. Algunas consecuencias no pueden deshacerse: un embarque ya salió o un tercero vio una orden. El contrato debe declarar “no compensable” y escalar antes del punto irreversible.
Ejemplo ilustrativo: diferencia de recepción
Un agente compara orden, aviso y conteo físico, y propone ajustar una recepción. El registro de intención congela objeto y versión. La política permite solo propuesta; un supervisor aprueba. El adaptador consulta el WMS y descubre que el conteo cambió después de la evidencia. La precondición falla y la intención vuelve a revisión; no sobrescribe.
En otro caso, el WMS acepta el ajuste pero la respuesta se pierde. El reconciliador encuentra la referencia nativa y marca confirmada sin reintentar. Si después el ERP rechaza el asiento relacionado, el flujo no borra el ajuste de almacén: inicia la compensación definida o escala, conservando ambos resultados. El ejemplo es ilustrativo y no prescribe reglas universales.
Permisos y doble frontera
El adaptador usa una identidad por operación o dominio con privilegio mínimo. La política autoriza intención; el ERP/WMS vuelve a autorizar ejecución según sus controles nativos. Ninguna aprobación del plano sustituye límites del sistema de registro.
Cambios de maestro, pagos, liberaciones o anulaciones merecen una ruta distinta de ajustes reversibles. El contrato puede exigir aprobación, doble control o ejecución humana. El agente no debería transformar una excepción en una operación genérica para evitar la puerta.
Observabilidad y reconciliación diaria
Mida intenciones por estado, edad, reintentos, conflictos de idempotencia, precondiciones fallidas, resultados inciertos y compensaciones abiertas. Segmente por sistema y operación. Una cola pequeña de casos inciertos puede importar más que miles de confirmados.
En Quantum Automation Center, estados de ejecución, cronologías, artefactos, logs, permisos y aprobaciones pueden mostrar la intención de extremo a extremo. El ERP o WMS sigue siendo autoridad del resultado; Quantum conserva la relación entre decisión, autorización y acción.
El mejor contraargumento
La capa añade latencia, componentes y operación. Para una integración pequeña puede duplicar validaciones nativas y crear otro lugar donde fallar. Mantener adaptadores por versión también cuesta.
La objeción es válida. Use el mínimo necesario: si la API nativa ya ofrece idempotencia, autorización granular, auditoría y precondiciones, el adaptador puede ser delgado. La separación sigue siendo útil para impedir credenciales amplias y conservar intención, pero no necesita reimplementar funciones existentes.
Cuándo no usar este enfoque
No construya el contrato completo para consultas de solo lectura o escrituras reversibles de bajo impacto cuando el sistema ya ofrece una API idempotente, auditada y con permisos adecuados. Tampoco lo use para disfrazar una integración frágil con más colas.
Sí es necesario cuando una acción cambia inventario, contabilidad, pedidos o compromisos y puede reintentarse. En ese contexto, la pregunta no es si el agente “sabe usar el ERP”. Es si cada intención puede ejecutarse una vez, probarse después y corregirse sin inventar el estado.
Sources
Temas del artículo
