La recuperación de un agente no empieza en el modelo. Empieza en el lugar donde el sistema registra el progreso, confirma lo que ya ocurrió y decide si un paso puede repetirse. Sin esa capa, un reinicio convierte el trabajo terminado en contexto perdido y una llamada externa aplicada parcialmente en un riesgo de duplicación.
La ejecución durable es el contrato que permite a un agente pausar, fallar, esperar una aprobación y continuar desde un estado confirmado. Un checkpoint, una cola y un workflow pueden ayudar a cumplirlo, pero no son lo mismo. La elección depende de la unidad de trabajo, del tipo de efecto externo y de la recuperación que el equipo necesita operar.
Decisión rápida
- Usa un loop dentro del proceso solo para trabajo corto, reversible y capaz de reiniciarse sin consecuencias.
- Añade un checkpoint y una cola cuando cada unidad de trabajo tenga un identificador, estado persistido y un paso reanudable.
- Usa una máquina de estados o un workflow cuando existan esperas, señales, compensación, fan-out, replay o un historial que deba auditarse.
- Trata cada escritura externa como potencialmente aplicada hasta que el sistema confirme lo contrario.
¿Qué debe garantizar la ejecución durable?
La ejecución durable significa que el progreso de una tarea sobrevive al proceso que la inició. La documentación de Temporal Workflow describe este principio mediante historial de eventos y replay: el workflow reconstruye su estado a partir de los eventos registrados, mientras las llamadas externas se ejecutan como Activities y no vuelven a ejecutarse durante el replay.
Para un agente, el contrato debe responder algunas preguntas prácticas. ¿Qué estado está confirmado? ¿Qué paso está en curso? ¿Qué puede repetirse sin duplicar un efecto? ¿Qué evidencia permite continuar o pedir ayuda humana? La conversación del modelo puede formar parte del estado, pero no debería ser el único lugar donde existan esas respuestas.
Una ejecución recuperable es más que una sesión que conserva mensajes. También registra decisiones, resultados de herramientas, transiciones, intentos y efectos externos. Si el proceso muere después de enviar una solicitud, el sistema debe saber si tiene que consultar el estado, esperar una confirmación o ejecutar una acción compensatoria.
Este diseño cambia el papel del agente. El modelo propone la siguiente acción y puede explicar un resultado. El runtime confirma la transición, aplica límites de retry y decide si la tarea está done, failed o needs-human.
Checkpoint, cola o workflow: ¿qué capa resuelve el problema?
Las tres capas abordan el fallo en niveles diferentes. Un checkpoint persiste el progreso. Una cola entrega trabajo a un consumidor y permite sustituir el proceso. Un workflow organiza transiciones, esperas, señales, retries e historial para una ejecución que puede durar más que un proceso.
| Capa | Qué persiste | Cuándo suele bastar | Qué sigue siendo tu responsabilidad |
|---|---|---|---|
| Checkpoint | Estado de un paso o grafo | El agente debe continuar después de una interrupción | Lectura del estado, leases, retries e idempotencia |
| Cola con worker | Tarea e intento de procesamiento | El trabajo puede dividirse en unidades independientes | Orden, deduplicación, timeouts y coordinación |
| Máquina de estados | Estados y transiciones permitidas | El flujo tiene reglas claras y pocos caminos válidos | Persistencia, ejecución de efectos y observabilidad |
| Workflow durable | Historial de eventos y señales | El flujo espera, se ramifica, llama sistemas externos o necesita replay | Modelar Activities, versionar definiciones y controlar costes |
El error es elegir por el nombre de la herramienta. Empieza por lo que necesitas demostrar. Si una tarea solo debe recordar que terminó el paso de lectura, un checkpoint puede bastar. Si llegan tareas independientes, una cola crea un límite operativo claro. Si el agente debe esperar una aprobación y continuar desde el punto correcto sin perder efectos anteriores, el estado del flujo debe ser explícito.
¿Cuándo basta una cola con checkpoint?
Una cola con checkpoint funciona bien para un agente que procesa tareas independientes con pasos cortos y un estado que cabe en un registro. El worker recibe un taskId, carga el último paso confirmado, ejecuta una acción, registra el resultado y libera la tarea. Otro worker puede continuar después de una caída.
El contrato mínimo puede ser pequeño y estar tipado:
type RunState = "queued" | "running" | "waiting" | "done" | "failed" | "needs-human";
type AgentRun = {
id: string;
state: RunState;
step: string;
checkpoint: string | null;
lastEvidence: string | null;
idempotencyKey: string;
};
type RunStore = {
load(id: string): Promise<AgentRun>;
save(run: AgentRun): Promise<void>;
};Lo importante no es el tipo en sí. La transición debe ser persistente, observable y condicionada al estado anterior. Un worker no debería cambiar running por done solo porque el modelo respondió. Debe guardar la evidencia que confirma el resultado esperado.
El lease de la cola también necesita una política. Si el worker desaparece, otro puede tomar la tarea después de un timeout. Si el primero sigue vivo, ambos pueden intentar el mismo paso. Por eso, el almacén debe aceptar la actualización solo mientras el lease y el checkpoint esperados sigan siendo válidos.
Este patrón encaja con consumidores de colas, jobs de evaluación, procesamiento de archivos y tareas de coding agents que producen un artefacto aislado. Se vuelve más difícil de mantener cuando cada paso envía señales, espera respuestas externas, crea subagentes o necesita compensación en varios sistemas.
¿Cuándo una máquina de estados hace más seguro al agente?
Una máquina de estados hace explícitas las acciones disponibles en cada fase. El modelo puede clasificar un evento o proponer una acción, pero el código decide si la transición está permitida. Así se evita que una respuesta plausible salte la autorización, marque una tarea como terminada antes de verificarla o repita una escritura ya confirmada.
Un flujo sencillo puede separar propuesta, autorización, ejecución, confirmación y verificación:
const transitions: Record<RunState, RunState[]> = {
queued: ["running"],
running: ["waiting", "done", "failed", "needs-human"],
waiting: ["running", "failed", "needs-human"],
done: [],
failed: ["queued", "needs-human"],
"needs-human": ["queued", "failed"],
};
function canMove(from: RunState, to: RunState) {
return transitions[from].includes(to);
}El ejemplo no ejecuta al agente. Limita el espacio de decisiones del runtime. La implementación aún debe persistir el cambio, comprobar la concurrencia y registrar por qué ocurrió la transición. Una state machine sin almacenamiento durable sigue perdiendo su posición cuando el proceso muere.
Esta capa es útil para agentes que acceden a APIs con permisos, cambian datos, esperan aprobación humana o coordinan subagentes. El artículo sobre orquestación multiagente con TypeScript explora supervisores, dependencias y recuperación. Aquí la pregunta es qué contrato mantiene recuperable todo el flujo.
¿Qué cambia en un coding agent?
Imagina un coding agent que recibe una issue, inspecciona el repositorio, modifica archivos y ejecuta la verificación del patch. Si el worker cae después de escribir el diff, la reanudación no debe empezar leyendo toda la codebase. Debe cargar el estado de la tarea, el commit de referencia, los archivos modificados y el último comando confirmado.
Si la verificación todavía no terminó, el runtime puede iniciar ese paso de nuevo. Si el commit ya existe, el paso de escritura no debe repetirse sin comprobar el estado del repositorio. Si la prueba falló, el agente puede recibir el log y una hipótesis de corrección, pero el sistema debe mantener la ejecución incompleta hasta que pase una nueva prueba.
Este diseño conecta la ejecución durable con el loop que devuelve los fallos de CI al agente. El agente corrige una hipótesis cada vez; el runtime conserva el historial y limita el camino de recuperación. Así, una sesión interrumpida no borra el trabajo confirmado ni convierte la conversación en la única fuente de verdad.
¿Cuándo compensa un workflow dedicado?
Un workflow dedicado compensa cuando el sistema necesita tratar una ejecución como una entidad de larga duración. La tarea puede esperar una señal, reanudarse después de un despliegue, ejecutar ramas en paralelo, aplicar compensación o conservar un historial que otra persona pueda inspeccionar.
AWS Step Functions modela workflows como máquinas de estados con transiciones, estados de espera, elecciones, mapas y ramas paralelas. Su documentación de manejo de errores separa Retry de Catch, lo que convierte la recuperación en una propiedad declarada del flujo.
Temporal usa historial de eventos y replay para reconstruir el estado del workflow. Su documentación de Retry Policy recomienda colocar los fallos de operaciones externas en Activities, donde la política de retry puede distinguir fallos temporales de errores que no deben repetirse.
LangGraph documenta checkpoints como snapshots del estado del grafo y conserva pending writes cuando un nodo falla mientras otros terminan. Su documentación de persistencia también advierte que el almacenamiento solo en memoria pierde checkpoints después de un restart y que un historial sin límite puede seguir creciendo.
Estas herramientas no eliminan las decisiones del dominio. Un workflow puede repetir una Activity, pero no sabe por sí solo si un cobro se aplicó antes de un timeout. Un checkpoint puede restaurar el estado del grafo, pero no autoriza una herramienta. La capa durable guarda lo que el sistema sabe; el código de negocio decide qué puede ocurrir después.
Retry no es reanudar
Retry significa volver a intentar una operación después de un fallo. Reanudar significa continuar una ejecución desde el último estado confirmado. A veces coinciden. Muchas veces no.
Una lectura idempotente normalmente puede repetirse con poco riesgo. Una escritura externa necesita una clave de idempotencia, una consulta de confirmación o una operación compensatoria. Imagina que el timeout ocurre después de que el proveedor recibe la solicitud. El error local no demuestra que no se haya aplicado.
El flujo debe registrar la frontera entre intención y efecto. Antes de ejecutar, registra la intención y la clave. Después, registra la respuesta o el estado observado. Al reanudar, consulta esa evidencia antes de llamar otra vez a la herramienta. El agente puede ayudar a interpretar la respuesta, pero no debe inventar la confirmación.
El mismo principio se aplica a una llamada al modelo. Si un paso genera un plan y falla al guardar el resultado, repetir la llamada puede producir otra salida. Decide si el plan es un artefacto que necesita deduplicación, puede regenerarse o debe pasar a revisión humana.
¿Cómo comprobar que la arquitectura realmente reanuda?
La prueba más útil interrumpe el sistema en los puntos donde una demostración suele ocultar el riesgo. No basta con iniciar el worker y observar una respuesta final. La prueba debe inspeccionar el historial de ejecución.
- Inicia una tarea con identificador y registra su primer checkpoint.
- Detén el proceso después de que una herramienta responda, pero antes de guardar la siguiente transición.
- Inicia otro worker y comprueba qué estado carga.
- Verifica que el paso confirmado no se haya ejecutado de nuevo sin una razón de idempotencia.
- Fuerza una respuesta lenta, un fallo permanente y un timeout para confirmar que las políticas son distintas.
- Pausa la tarea mientras espera aprobación y reanúdala después sin mantener vivo el proceso original.
- Inspecciona la evidencia final, el estado terminal y el camino que llevó hasta él.
Para coding agents, añade el commit, el diff, las pruebas y el artefacto producido al registro de la ejecución. Un agente puede decir que terminó un cambio. El sistema debe mostrar qué archivo cambió, qué verificación pasó y qué riesgo sigue abierto. La observabilidad de agentes de código en CI trata esta evidencia en el pipeline.
¿El contexto también forma parte de la recuperación?
Reanudar no significa cargar toda la conversación anterior en el prompt. El sistema debe persistir un estado compacto, resultados de herramientas y referencias a artefactos. Al reanudar, recupera solo el contexto necesario para la siguiente transición.
En ejecuciones largas, RemoteCode ayuda a que Claude Code y Codex continúen flujos agentic con menos contexto repetido. La herramienta pertenece al autor y aparece aquí como una opción para reducir el contexto enviado entre sesiones. No sustituye checkpoints, autorización, idempotencia ni verificación del resultado.
Esta separación evita dos desperdicios. El sistema no paga otra vez para que el modelo relea todo lo ya confirmado y el agente no recibe un historial tan grande que oculte el estado actual. El checkpoint guarda el progreso; el mecanismo de recuperación construye la proyección que necesita el siguiente paso.
Errores comunes y límites de la decisión
Llamar ejecución durable a cualquier persistencia es un mal comienzo. Guardar mensajes en una base de datos no define transiciones, no detecta un worker abandonado ni evita que una herramienta vuelva a ejecutarse. El almacenamiento debe llevar el estado suficiente para decidir el siguiente paso.
También es fácil poner los retries dentro del loop del agente y dejar al runtime sin visibilidad. Un retry sin límite puede consumir contexto, repetir llamadas caras y ocultar un error permanente. La política debe estar fuera de la decisión libre del modelo.
Elegir un workflow porque su diagrama parece más completo crea otro problema. Una lectura corta puede ser más sencilla de operar con una cola simple o una llamada síncrona. El workflow debe justificar su coste cuando espera, se ramifica, compensa o necesita un historial confiable.
Por último, un checkpoint no es memoria de largo plazo. Un checkpoint mantiene el estado de una ejecución. La memoria persistente guarda hechos que cruzan ejecuciones. Son capas relacionadas, pero tienen retención, autorización y pruebas diferentes.
Preguntas frecuentes sobre ejecución durable para agentes de IA
¿Todo agente de IA necesita un workflow durable?
No. Un agente corto, sin efectos irreversibles y ejecutado dentro de una sola solicitud puede empezar con un loop simple. La necesidad aparece cuando el trabajo debe sobrevivir a un reinicio, esperar a una persona, consumir una cola, repetir un paso con seguridad o demostrar lo ocurrido. En ese punto, persiste el estado antes de elegir un producto.
¿Un checkpoint es lo mismo que un retry?
No. Un checkpoint registra dónde está la ejecución y qué resultados están confirmados. Un retry vuelve a intentar una operación después de un fallo. Para reanudar con seguridad, el runtime debe cargar el checkpoint y decidir si el paso falla, continúa o primero comprueba un efecto externo que quizá ya ocurrió.
¿Cómo evitar que un retry duplique una llamada externa?
Usa una clave de idempotencia cuando el proveedor la admita. Registra también la intención, consulta el estado de la operación antes de repetirla y trata un timeout como un estado desconocido hasta confirmarlo. El agente no debe marcar la acción como completa solo porque la llamada se envió.
¿Una cola puede sustituir a Temporal, Step Functions o LangGraph?
A veces. Una cola con estado persistido puede bastar para tareas independientes y pasos cortos. No proporciona automáticamente señales, replay, esperas humanas, transiciones válidas, compensación ni historial de workflow. Compara el contrato que necesitas operar, no la cantidad de componentes de la arquitectura.
¿Dónde debe vivir el estado del agente?
Fuera de la memoria del proceso. Usa un almacenamiento que registre el identificador de la tarea, estado, paso, checkpoint, evidencia y clave de idempotencia. La conversación y los resultados del modelo pueden ser referencias en ese registro, pero la aplicación debe poder decidir el siguiente paso después de que desaparezca el worker original.
