Don’t Let Your Agent Decide the Write Sequence

That leaves a design question that teams often answer by accident: when one agent action has to update three systems, what decides the order, what happens on a retry, and what gets undone if the third write fails? If the agent is wired directly to each system’s APIs, the answer defaults to the model. The Autonomous Commerce Reference Architecture we published argues for a different owner, which it calls the capability layer. The report works through it with a running example: Ardmore, a fictional cabinet manufacturer whose agent finds and makes a substitution when the plant can’t fill a line on a builder’s order. That one substitution writes to the ERP, to the project system the builder sees, and to the plant schedule. Each of those writes also leaves a record, and how you store that record decides how quickly you can answer the hard questions later.

Durante años, las integraciones han expuesto las funciones de cada sistema por separado y han dejado que la aplicación que las invoca se encargue de secuenciarlas. Eso funciona cuando una persona escribe la secuencia, la prueba y la revisa. Un agente elige sus pasos sobre la marcha, así que si lo apuntas a esas mismas APIs, improvisa el orden de actualización en cada ejecución y nadie verifica la decisión. La secuencia termina viviendo en un prompt, donde puede cambiar de una ejecución a la siguiente, y revisarla significa leer una transcripción en lugar de leer código.

La respuesta del informe es una capa entre los agentes y los sistemas sobre los que actúan. Una capacidad es una operación de negocio única con condiciones previas definidas, efectos declarados y una reversión establecida, orquestada a través de todos los sistemas que sean necesarios. "Sustituir una línea en un pedido liberado" lee de cuatro sistemas y escribe en tres, y el agente lo percibe como una única llamada que ocurrió o no ocurrió.

Dentro de la capacidad, el orden de escritura es fijo. En el ejemplo del informe, nuestra empresa de referencia Ardmore escribe primero en el ERP porque este contiene el registro comercial con el que todo lo que viene después se reconcilia. El sistema de proyectos ocupa el segundo lugar porque contiene el compromiso que ve el constructor, y la planificación de planta viene en último lugar porque escribir allí libera el material. Ninguna transacción abarca los tres sistemas, por lo que la capacidad es el elemento que gestiona la secuencia.

La primera es la idempotencia. Los reintentos son habituales en el trabajo de los agentes: las ejecuciones se agotan y se reanudan, los modelos devuelven respuestas con formato incorrecto y las llamadas de red fallan de forma ambigua después de que ya podrían haber tenido éxito. Toda capacidad que realice escrituras debe aceptar una clave de idempotencia y respetarla durante un período establecido, de modo que una segunda llamada con la misma intención no produzca una segunda sustitución. El período debe cubrir el horizonte de reanudación del entorno de ejecución, porque una clave válida durante una hora no protegerá una ejecución que se reanude a la mañana siguiente, y esa es precisamente la ejecución con mayor probabilidad de repetirse.

La segunda es la compensación. Una reversión deshace un cambio que nunca llegó a ser visible, mientras que una compensación es una nueva acción que revierte uno que sí lo fue, de la misma manera en que un reembolso contrarresta un pago en lugar de eliminarlo. Si las escrituras en el ERP y en el sistema de proyectos tienen éxito pero la escritura en el calendario de planta falla, el informe contempla tres respuestas posibles: reintentar dentro de un presupuesto establecido, compensar las dos escrituras exitosas e informar que la llamada no ocurrió, o detener y escalar con el estado parcial descrito con suficiente precisión para que una persona pueda actuar. Un reintento sin presupuesto no figura en esa lista porque nunca alcanza un estado final. El informe añade un requisito fácil de pasar por alto: registrar cada compensación como una acción por derecho propio, de modo que el registro de auditoría refleje lo que realmente ocurrió.

Una capacidad se define en términos de negocio, por lo que su implementación puede cambiar por debajo de ella. Cuando se reemplaza el ERP, la descripción de la capacidad, el agente y la descripción del trabajo permanecen tal como están, y solo se reescribe una implementación. Para muchos CIOs, eso es razón suficiente para construir la capa como parte de sus primeros casos de uso agéntico, no después de ellos.

La misma lógica se aplica a la venta a agentes que no se controlan. El Agentic Commerce Protocol de OpenAI y Stripe, y el Universal Commerce Protocol de Google, definen cómo los agentes externos llaman al proceso de pago de un vendedor. Cada protocolo establece el formato y el protocolo de enlace, y el proceso de pago detrás de él aún necesita un orden de escritura fijo, idempotencia y una reversión definida. Un vendedor que construya esa capacidad una sola vez puede exponerla a través de ambos.

El informe le pide que registre cada compensación como una acción independiente. Añadiríamos un paso más: decidir dónde vivirá ese registro completo mientras construye sus primeros casos de uso agénticos. Cada llamada a una capacidad deja un rastro de lo que el agente intentaba hacer, lo que leyó, lo que escribió y cualquier cosa que revirtió. La mayoría de los equipos mantienen ese rastro como un registro. Un registro está bien para verificar lo que ocurrió en una llamada, pero es mucho menos útil cuando descubre que un campo era incorrecto y necesita saber todo lo que dependía de él.

Esa es una pregunta sobre conexiones. Este pedido usó ese campo, el campo provino de ese sistema, y el mismo campo alimentó estos otros pedidos. Una base de datos de grafos como Neo4j almacena los registros con esas conexiones ya establecidas, de modo que puede hacer la pregunta directamente en lugar de reconstruir la respuesta a partir de registros. En Neo4j, "¿qué pedidos dependían de este campo?" es una sola consulta. Con unas pocas capacidades y un historial breve, es una tarea sencilla, y cada nueva capacidad se suma al mismo registro. Si espera, termina reconstruyendo esas conexiones a partir de registros que nunca fueron diseñados para mostrarlas, generalmente en medio de un problema.

Una capacidad que gestiona correctamente el orden de escritura, los reintentos y la reversión puede aun así registrar una decisión incorrecta de forma impecable. El capítulo 15 sigue una sustitución de Ardmore que superó las cinco condiciones de límite y la verificación de actualización, y escribió en los tres sistemas en el orden correcto. Aun así fue incorrecta, porque un campo en el sistema de proyectos era reciente e inexacto. Nadie lo notó durante nueve semanas. Reconstruir la decisión tomó veinte minutos, pero encontrar los demás pedidos que dependían del mismo campo llevó cuatro días de trabajo de ingeniería. El capítulo explica qué cambió Ardmore después y por qué el modelo, el prompt y el agente no estaban en esa lista. El capítulo 7 también aborda la configuración de precedencia campo por campo cuando los sistemas no coinciden, el dimensionamiento para la carga de lectura del agente, y la contención de inyección de prompts y envenenamiento de herramientas; y concluye con una única prueba que puede ejecutarse contra su propio stack.

Descargue la Arquitectura de Referencia para el Comercio Autónomo para obtener la arquitectura completa, el ejemplo detallado de Ardmore y las plantillas del Apéndice A.