El patrón Saga como columna vertebral de los agentes de IA que actúan en el mundo real

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, ves que un agente no razona: 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. Que es justo lo que hace que el patrón encaje.

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 todavía, ¿qué pasa si el agente “cree” que algo ha fallado cuando en realidad ha funcionado? ¿Y 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 tienes transacciones ni atomicidad, y tampoco hay garantías implícitas de las que tirar. 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:

1. La acción en sí, o sea qué se va a hacer.
2. La verificación, que es cómo sabes que realmente ocurrió.
3. 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.

Un ejemplo fácil:

• 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.

Y uno que escuece más:

• 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

Uno de los errores más comunes es pensar la 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. Lo que promete es no dejar el sistema en un estado incoherente.

Dos fases para herramientas peligrosas

Una idea que funciona bien es diseñar las herramientas con fases explícitas: plan/dry-run, prepare, commit, abort. No es two-phase commit distribuido, es diseño defensivo.

Pongamos que hay que borrar un recurso crítico.

• En la fase prepare devuelves qué se va a borrar, con su impacto y sus dependencias.
• En commit solo se acepta un token de confirmación generado en prepare.
• En abort se invalida el token.

Con esto puedes auditar, interrumpir el proceso o exigir aprobación humana. Y sobre todo evitas que el agente ejecute algo irreversible por haber entendido mal una frase.

Eso es lo que 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 se inventa que algo no ocurrió.

Con esto puedes reanudar, compensar, auditar y explicar qué pasó.

Es más o menos lo que separa un agente de juguete de uno que puedes poner en producción.

Idempotencia: la ley no negociable

Un agente va a reintentar. Siempre.

Si una acción no es idempotente:

• Duplicas recursos.
• Acabas mandando la misma notificación dos veces.
• Pagas dos veces por lo mismo.
• Y de paso rompes la confianza de quien te lo compró.

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

Esto salió como efecto secundario, pero es de lo más útil que tiene el patrón.

Si alguien induce al agente a ejecutar algo indebido (por un texto malicioso, una instrucción oculta o una interpretación errónea), el diseño tipo Saga:

• Obliga a verificar.
• Deja registro de todo.
• Mete la acción por fases antes de tocar nada.
• Y te permite compensar después.

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, tiene que asumir que puede equivocarse.

El patrón Saga no es una moda arquitectónica. Es responsabilidad aplicada a sistemas que no tienen transacciones.

Los agentes de IA que van a producción no necesitan más “inteligencia”. Necesitan límites, memoria, compensaciones y diseño defensivo.

Lo curioso es que esto ya lo sabíamos hace años. Lo único que ha cambiado es quién ejecuta los pasos: antes era un servicio, ahora es una IA que a veces se lo inventa.