Noticias, guías y análisis
Cómo usar prepare/commit para que un agente prepare una acción sensible antes de obtener autoridad para ejecutarla
El patrón prepare/commit construye y valida primero un paquete inmutable y ejecuta después una mutación estrecha e idempotente, reduciendo riesgo en acciones sensibles.
El patrón prepare/commit separa el momento en que un agente decide qué hacer del momento en que la acción irreversible se ejecuta. En la fase prepare, el sistema reúne evidencia, resuelve destinatario, calcula valores, valida permisos y construye una representación exacta de la mutación. Nada externo cambia todavía. La fase commit recibe ese paquete ya validado y realiza únicamente la acción acordada. La separación reduce la cantidad de razonamiento que ocurre mientras existe autoridad de escritura y crea un punto claro donde políticas o humanos pueden revisar una consecuencia antes de materializarla.
El paquete preparado debe ser inmutable o estar versionado para que la aprobación corresponda exactamente a lo que se ejecutará. Si un usuario aprueba pagar 500 y luego el agente recalcula 550 antes del commit, la confirmación perdió significado. Guarda un hash del payload, entidad, monto, tool objetivo y expiración. El commit acepta únicamente ese identificador y rechaza modificaciones silenciosas. Si cambia un dato importante, se genera un nuevo prepare y se solicita la validación correspondiente. Esa disciplina convierte la aprobación en un contrato y no en una señal vaga de intención.
La fase prepare también puede ejecutar todas las comprobaciones que no requieren mutación. Verifica saldos, permisos, existencia del destinatario, límites, duplicados e idempotency keys. Si algo falla, el workflow termina antes de obtener autoridad para escribir. Esto reduce incidentes y hace más legibles los errores. Un “preparefailed” significa que la acción nunca cruzó la frontera externa; un “commitfailed” significa que el paquete era válido pero la ejecución no se completó. Esa distinción orienta reintentos y evita reconstruir decisiones cada vez que un conector transaccional presenta un problema temporal.
El commit debería ser pequeño, determinista e idempotente. Idealmente no vuelve a investigar ni interpreta instrucciones nuevas: toma el paquete validado, comprueba que sigue vigente y ejecuta una sola mutación. Si recibe de nuevo el mismo idempotency key, devuelve el resultado anterior o demuestra que el efecto ya existe. Cuanto menos razonamiento ocurre dentro de esta fase, más fácil es auditarla y protegerla. El agente puede ser flexible durante preparación, pero el executor final se comporta como una función estrecha con reglas claras.
Para acciones que admiten compensación, el paquete puede incluir también la estrategia de reversión antes del commit. Si se modifica una campaña, guarda la configuración previa; si se reemplaza un archivo, conserva versión o backup; si se reserva inventario, define expiración. No todas las acciones pueden deshacerse, pero pensar en compensación antes de ejecutar mejora la capacidad de recuperación. También permite que la política exija condiciones más fuertes cuando no existe rollback. La ausencia de reversión deja de descubrirse después del incidente y entra en la decisión de si el commit está permitido.
Prepare/commit convierte una acción agentic en dos decisiones con responsabilidades diferentes. La primera pregunta “¿qué deberíamos hacer y con qué evidencia?”; la segunda pregunta “¿ejecutamos exactamente este paquete ahora?”. Esa separación reduce race conditions, aprobaciones ambiguas y mutaciones que cambian mientras el usuario las revisa. En sistemas con dinero, permisos, publicación o comunicaciones sensibles, el patrón ofrece una forma simple de conservar inteligencia en la preparación y disciplina determinista en la ejecución final. En otras palabras, prepare/commit crea una forma de disciplina que reduce sorpresas, hace más barato investigar errores y mejora la confianza en la automatización.
Cierre operativo. La inteligencia puede ser flexible mientras prepara; la mutación final debería ser estrecha, versionada y exactamente igual a lo que fue validado. En la práctica, conviene haz inmutable o versionado el payload preparado y concentra validaciones antes de la fase de escritura antes de ampliar el workflow.