Phase 15 - Lesson 12

Agentes en Segundo Plano de Larga Ejecución: Ejecución Durable

Los agentes de horizonte largo en producción no se ejecutan en while True. Cada llamada de LLM se convierte en una actividad con checkpoint, reintento (retry) y reproducción (replay). La integración del SDK de Agentes de OpenAI de Temporal pasó a GA en marzo de 2026. Claude Code Routines (Anthropic) ejecuta invocaciones programadas de Claude Code sin un proceso local persistente. Las sesiones se pausan ante la entrada de un humano, sobreviven a los despliegues (deploys) y se reanudan desde el último checkpoint identificado por thread_id. Detrás de esta nueva ergonomía se encuentra un patrón antiguo —orquestación de flujos de trabajo (workflows)— con una nueva entrada: llamadas de LLM como actividades no deterministas que deben reproducirse de manera determinista al recuperarse.

Type: Aprender Languages: Python (stdlib, máquina de estado mínima de ejecución durable) Prerequisites: Phase 15 · 10 (Permission modes), Phase 15 · 01 (Long-horizon agents) Time: ~60 minutos

El Problema

Considere un agente que se ejecuta durante cuatro horas. Llama a tres herramientas, solicita información al usuario dos veces y realiza cuarenta llamadas de LLM. A mitad del camino, el host en el que se está ejecutando se reinicia. ¿Qué pasa?

• En un bucle while True ingenuo: todo se pierde. La ejecución se reinicia desde cero. Las tres llamadas a herramientas (con efectos secundarios reales) se ejecutan de nuevo. Se le solicita al usuario nuevamente información para cosas que ya aprobó. Se vuelven a facturar las cuarenta llamadas de LLM.
• Con ejecución durable: la ejecución se reanuda desde el checkpoint más reciente. Las actividades ya completadas no se vuelven a ejecutar; sus resultados se reproducen desde el registro (log) durable. El usuario no tiene que volver a aprobar las cosas que ya aprobó. Las llamadas de LLM ya realizadas no se vuelven a facturar.

Este es el mismo patrón que los motores de flujos de trabajo han ofrecido durante una década (Temporal, Cadence, Cherami de Uber). Lo nuevo es que las llamadas de LLM ahora son un tipo de actividad —no deterministas, costosas, con efectos secundarios— y encajan perfectamente en este patrón.

El tema recurrente de la lección: la confiabilidad de los horizontes largos decae (METR observa una "degradación de 35 minutos" — la tasa de éxito cae de forma aproximadamente cuadrática con el horizonte). La ejecución durable permite ejecuciones que son más largas de lo que admite el perfil de confiabilidad, lo cual es una nueva forma de fallar de manera segura si el diseño es correcto y de manera insegura si el diseño es incorrecto.

El Concepto

Actividades, flujos de trabajo (workflows) y reproducción (replay)

• Workflow: código de orquestación determinista. Define la secuencia de actividades, las bifurcaciones, las esperas. Debe ser determinista para que pueda reproducirse desde el registro de eventos sin divergencias inesperadas.
• Activity: una unidad de trabajo no determinista que potencialmente puede fallar. Llamada de LLM, llamada a herramienta, escritura de archivos, solicitud HTTP. Cada actividad se registra con sus entradas y (once complete) sus salidas.
• Log de eventos: el almacenamiento durable de respaldo. Se registra cada inicio, finalización, falla y reintento de actividad, así como cada decisión del flujo de trabajo.
• Replay: al recuperarse, el código del flujo de trabajo se vuelve a ejecutar desde el principio; cada actividad que ya se completó devuelve su resultado registrado sin volver a ejecutarse. Solo se ejecutan realmente las actividades que no se habían completado.

Esta es la misma estructura que React volviendo a renderizar contra un DOM virtual, o Git reconstruyendo un árbol de trabajo a partir de commits. El determinismo en el orquestador es lo que hace que la durabilidad sea económica.

Por que las llamadas de LLM encajan en el patrón

Las llamadas de LLM son:

• No deterministas (temperatura > 0; incluso la temperatura 0 experimenta desvíos entre versiones de modelos).
• Costosas (dinero y latencia).
• Potencialmente propensas a fallas (límites de tasa, tiempos de espera/timeouts).
• Generadoras de efectos secundarios (si invocan herramientas).

Este es exactamente el perfil de una actividad. Envolver cada llamada de LLM como una actividad le brinda reintentos con respaldo exponencial (exponential backoff), creación de checkpoints ante reinicios y un rastreo reproducible para la depuración.

Checkpoints identificados por thread_id

LangGraph, Microsoft Agent Framework, Cloudflare Durable Objects y Claude Code Routines convergieron en el mismo formato de API: un thread_id (o equivalente) identifica la sesión; cada transición de estado persiste en un backend (PostgreSQL por defecto, SQLite para desarrollo, Redis para caché); la reanudación lee el último checkpoint.

La elección del backend importa:

• PostgreSQL: durable, consultable, sobrevive a los despliegues. Por defecto en LangGraph.
• SQLite: solo para desarrollo local; pierde datos entre hosts.
• Redis: rápido pero efímero a menos que se configure AOF/snapshot.
• Cloudflare Durable Objects: distribuido de manera transparente; delimitado por una clave única; sobrevive de horas a semanas.

La entrada humana como un estado de primera clase

El patrón proponer-y-luego-confirmar (propose-then-commit) (Lección 15) requiere un estado durable de "espera al humano". El flujo de trabajo se pausa, la cola externa retiene la solicitud pendiente y una aprobación reanuda el flujo exactamente desde ese punto. Sin durabilidad, esto se hace con base en el mejor esfuerzo; con ella, llega una aprobación al día siguiente y el flujo de trabajo continúa por la mañana de donde se quedó.

La degradación de 35 minutos

METR observó que cada clase de agente evaluada muestra un deterioro en la confiabilidad después de aproximadamente 35 minutos de operación continua. Duplicar la duración de la tarea casi cuadruplica la tasa de fallas. La ejecución durable no soluciona esto; le permite ejecutarse por más tiempo de lo que admite el perfil de confiabilidad. El patrón seguro es combinar la durabilidad con checkpoints que requieran una nueva validación humana (HITL) al reingresar, y con interruptores de apagado por presupuesto (Lección 13) que limiten el cómputo total sin importar el tiempo transcurrido en el reloj.

Cuándo la ejecución durable es la respuesta incorrecta

• Ejecuciones de menos de unos pocos minutos sin entrada humana. El costo operativo (overhead) es mayor que el beneficio.
• Recuperación de información que es estrictamente de lectura.
• Tareas donde la corrección requiere un procesamiento de extremo a extremo dentro de una sola ventana de contexto (algunas tareas de razonamiento; algunas generaciones en un solo paso).

Úselo

code/main.py implementa un motor mínimo de ejecución durable en la biblioteca estándar de Python. Admite:

• Decorador @activity que registra entradas y salidas en un log de eventos JSON.
• Una función de flujo de trabajo (workflow) que secuencia actividades.
• Una función run_or_replay(workflow, event_log) que reproduce las actividades completadas sin volver a ejecutarlas.

El script principal simula un flujo de trabajo de tres actividades, falla a mitad de camino y muestra (a) un reintento ingenuo que vuelve a ejecutar todo frente a (b) una reproducción que ejecuta solo la actividad faltante.

Colóquelo en Producción

outputs/skill-durable-execution-review.md revisa una propuesta de despliegue de agente de larga ejecución para verificar que tenga la estructura correcta de ejecución durable: actividades, determinismo, backend de checkpoints, estado de entrada humana y política de validación humana (HITL) al reanudar.

Ejercicios

1. Ejecute code/main.py. Observe la diferencia en el conteo de ejecuciones de actividades entre el reintento ingenuo y la reproducción. Cambie el punto de falla y demuestre que el conteo de reproducción cambia en consecuencia.

2. Convierta el motor de juguete para usar thread_id explícitamente. Simule dos sesiones simultáneas que comparten el motor y confirme que sus logs de eventos no colisionan.

3. Tome una actividad en el motor de juguete. Introduzca un comportamiento no determinista (una marca de tiempo del reloj en una decisión del flujo de trabajo). Demuestre la divergencia en la reproducción. Explique cómo manejan esto los motores reales (registro de efectos secundarios, APIs Workflow.now()).

4. Lea la publicación de LangChain "Runtime behind production deep agents". Enumere cada estado que el runtime persiste y mencione qué modo de falla cubre cada uno.

5. Diseñe una política de checkpoints para una tarea de codificación autónoma de 6 horas. ¿Dónde define los checkpoints? ¿Cómo se ve la reanudación tras una falla? ¿Qué requiere una nueva validación humana (HITL)?

Términos Clave

Lecturas Adicionales

• Anthropic — Claude Code Agent SDK: agent loop — presupuesto, turnos y semántica de reanudación.
• Microsoft — Agent Framework: human-in-the-loop and checkpointing — formato de RequestInfoEvent.
• LangChain — The Runtime Behind Production Deep Agents — requisitos concretos de tiempo de ejecución.
• OpenAI Agents SDK + Temporal integration (Trigger.dev announcement) — formato de actividad para llamadas de LLM.
• Anthropic — Measuring agent autonomy in practice — referencia sobre el deterioro de 35 minutos.