Durante años, el patrón Saga se ha explicado como una solución para microservicios, bases de datos distribuidas y llamadas a APIs. Algo “de backend”. Algo “de arquitectos”.
Pero si miras con calma cómo funciona un agente de IA moderno, te das cuenta de una cosa incómoda: un agente no razona, un agente actúa. Y en el momento en que actúa sobre sistemas reales, el problema que tienes delante es exactamente el mismo que resolvía Saga.
Solo que ahora el que toma decisiones no es un flujo de código determinista, sino un modelo probabilístico.
Ahí es donde todo encaja.
El problema real no es la inteligencia, es el daño
Un agente moderno puede crear tickets, modificar configuraciones, rotar secretos, desplegar código, tocar permisos, enviar emails, borrar recursos.
Eso ya no es “inferir texto”. Eso es mutar estado en sistemas distribuidos.
Y cuando mutas estado, siempre aparece la misma pregunta: ¿qué pasa si falla a mitad? O peor: ¿qué pasa si “cree” que algo ha fallado cuando no ha fallado? ¿O si interpreta mal una instrucción?
Aquí no vale decir “ups, error”. El daño ya está hecho.
Pensar un agente como una Saga
Si abstraes un poco, una ejecución de un agente es esto:
- Decide un plan.
- Ejecuta una secuencia de acciones.
- Cada acción tiene efectos secundarios.
- El proceso puede fallar en cualquier punto.
- El agente puede reiniciarse, reintentar o desviarse.
Eso es una Saga, aunque nadie la llame así.
La diferencia es que en agentes no hay transacciones, no hay atomicidad y no hay garantías implícitas. Todo tiene que ser explícito.
Acción + compensación + verificación
Si quieres agentes que no rompan cosas, cada acción relevante debería definirse con tres elementos:
- La acción en sí: qué se va a hacer.
- La verificación: cómo sabes que realmente ocurrió.
- La compensación: qué haces si necesitas deshacer o mitigar.
No siempre puedes deshacer. Pero siempre deberías saber qué harías si algo sale mal.
Ejemplo simple:
- Acción: crear un PR.
- Verificación: comprobar que el PR existe con commits y apunta a la rama correcta.
- Compensación: cerrar el PR o revertir el commit.
Ejemplo menos cómodo:
- Acción: enviar un email.
- Verificación: que el proveedor confirma entrega.
- Compensación: enviar un segundo email corrigiendo.
Eso también es una compensación, aunque no sea técnica.
En agentes, “rollback” casi nunca significa deshacer
Aquí está uno de los errores más comunes: pensar Saga en agentes como “rollback automático”.
En el mundo real no puedes:
- “Desenviar” un email.
- “Desborrar” algo sin backup.
- Hacer como si una acción humana no hubiera ocurrido.
En agentes, la compensación suele ser:
- Crear una acción correctiva.
- Restaurar desde backup.
- Revertir con otra acción.
- Notificar a un humano.
- Abrir un ticket explicando el estado.
Saga no promete volver atrás. Promete no dejar el sistema en un estado incoherente.
Dos fases para herramientas peligrosas
Una idea potente para agentes es diseñar herramientas con fases explícitas: plan/dry-run, prepare, commit, abort. No es two-phase commit distribuido. Es diseño defensivo.
Ejemplo: borrar un recurso crítico.
- En la fase prepare, devuelves qué se va a borrar, impacto y dependencias.
- En commit, solo se acepta un token de confirmación generado en prepare.
- En abort, se invalida el token.
Esto permite auditar, interrumpir, exigir aprobación humana y, sobre todo, que el agente no ejecute algo irreversible por una mala interpretación.
Eso hace que la acción sea “sagable”.
El log de Saga como memoria real del agente
Los LLM no recuerdan. Reinterpretan.
Una Saga necesita memoria externa y persistente:
- Identificador de ejecución.
- Pasos realizados.
- Entradas y salidas.
- Estado de cada paso.
- Evidencias (IDs, URLs, hashes).
- Claves de idempotencia.
Sin esto, el agente repite acciones, duplica efectos o inventa que algo no ocurrió.
Con esto, puedes reanudar, compensar, auditar y explicar qué pasó.
La diferencia entre un agente de juguete y uno serio está aquí.
Idempotencia: la ley no negociable
Un agente va a reintentar. Siempre.
Si una acción no es idempotente:
- Duplicas recursos.
- Duplicas notificaciones.
- Duplicas costes.
- Rompes confianza.
Cada acción con efectos debe tener una clave de idempotencia y una forma de comprobar si ya se ejecutó.
Saga sin idempotencia no funciona. En agentes, directamente es suicida.
Saga como defensa contra prompt injection
Este es un efecto secundario interesante.
Si el agente es inducido a ejecutar algo indebido (ya sea por un texto malicioso, una instrucción oculta o una interpretación errónea), el diseño tipo Saga:
- Obliga a verificar.
- Obliga a registrar.
- Obliga a pasar por fases.
- Permite compensar.
No evita todos los ataques, pero reduce el impacto y deja trazabilidad. En seguridad, eso importa más de lo que parece.
Tipos de compensación en agentes
No todo es técnico. La compensación puede ser:
- Técnica: rollback, restore, revert.
- Operativa: abrir ticket, crear tarea, avisar.
- Administrativa: pedir aprobación, bloquear flujo.
- Humana: escalar, explicar, pedir intervención.
Un agente que actúa en el mundo real necesita las cuatro.
La idea final
Si un agente puede cambiar el mundo, debe asumir que puede equivocarse.
El patrón Saga no es una moda arquitectónica. Es una filosofía de responsabilidad aplicada a sistemas sin transacciones.
Los agentes de IA que van a producción no necesitan más “inteligencia”. Necesitan límites, memoria, compensaciones y diseño defensivo.
Y curiosamente, eso ya lo sabíamos hace años. Solo que ahora, el que ejecuta los pasos no es un servicio. Es una IA.
Y eso lo cambia todo.