Las tasas de fallo compuestas en agentes multi-paso son brutales — eso ya lo establecimos. Un workflow de siete pasos con 95% de confiabilidad por paso aterriza en ~70% de extremo a extremo. Tres de cada diez ejecuciones explotan. Pero acá está la parte que nadie arregla: cuando el paso cuatro lanza un HTTP 500, ¿qué pasa con los tres pasos que ya corrieron? El mensaje de Slack ya enviado, la fila en la base de datos ya escrita, el ticket de Jira ya creado. Tu agente no sabe qué pasos se completaron. No tiene checkpoint — ninguna posición guardada desde donde retomar. Y no tiene lógica de compensación — ningún "deshacer" automático para trabajo a medio terminar.

Ver la tasa de fallo es el paso uno. Sobrevivir al fallo es el paso dos. Nadie implementa el paso dos.

Teatro de Recuperación

Los tres runtimes principales de agentes lanzaron funciones de recuperación este abril. Ninguno resuelve la recuperación de verdad.

Los Managed Agents de Anthropic (8 de abril) usan un event log de solo escritura — un diario write-once de todo lo que hizo el agente. ¿Se cae? Reinicia, relee el diario, continúa. Su equipo de ingeniería: "Nada en el harness necesita sobrevivir a un crash." Suena resiliente. Pero no hay dead-letter queue para tareas fallidas, no hay garantía de exactly-once de que cada acción se ejecute una sola vez, y no hay forma de revertir efectos secundarios ya completados.

La actualización del Agents SDK de OpenAI (15 de abril) agregó snapshotting y rehydration — guardar y restaurar el estado del agente entre reinicios de contenedor. Pero persiste el historial de mensajes, no el estado de ejecución. El modelo recuerda lo que dijo; no rastrea lo que hizo.

Google ADK (anunciado en Cloud Next, 22 de abril) incluye SequentialAgent, ParallelAgent, LoopAgent más un ResumabilityConfig. La letra chica: el caller debe detectar la interrupción y re-invocar manualmente. Nada de recuperación automática.

Tres enfoques diferentes para la durabilidad. Los tres modelan la ejecución como loops de inferencia — "pensar → llamar herramienta → observar → repetir." Ninguno la modela como una máquina de estados durable — un sistema que rastrea exactamente en qué estado se encuentra y qué transiciones son válidas, como una máquina expendedora que recuerda que ya metiste tu billete incluso después de un apagón.

Las Soluciones Que Ya Existen (Fuera de la IA)

Los motores de workflow resolvieron la ejecución durable hace una década. La industria de IA simplemente no los ha adoptado todavía.

Temporal envuelve cada paso en una actividad reintentable y reproducible. ¿Se cae a mitad del workflow? Temporal reproduce desde la última actividad completada — no desde cero. Así se ve un paso de agente envuelto en Temporal:

@activity.defn
async def file_jira_ticket(ctx: AgentContext) -> TicketResult:
    """Temporal reintenta esto automáticamente en caso de fallo.
    Si el agente se cae a mitad del workflow, reproduce
    desde la última actividad completada — no desde cero."""
    return await ctx.tools.jira.create_issue(
        summary=ctx.draft.title,
        idempotency_key=ctx.run_id  # previene tickets duplicados
    )

Ese idempotency_key — un ID único que asegura que la misma solicitud no se ejecute dos veces — es toda la diferencia entre "listo para producción" y "demo impresionante."

El Project Think de Cloudflare (15 de abril) tomó una ruta completamente diferente: bases de datos SQLite por agente, checkpoints con step.do(), e hibernación sin costo. Cada agente es una entidad durable aislada con su propio estado persistente, no un job en un orquestador centralizado. Para equipos que ya están en Cloudflare Workers, esto es probablemente el camino más limpio — sin motor de workflow externo, sin message broker, solo durable objects con checkpointing integrado.

Restate se ubica entre los dos: más liviano que Temporal, más estructurado que durable objects crudos. Provee garantías de exactly-once con un mecanismo de replay basado en journal, y ha publicado patrones de integración directa con Google ADK.

El Incómodo Punto Medio

Acá está el problema que nadie quiere reconocer: la brecha va en ambas direcciones.

Los motores de workflow no hablan LLM. No entienden token budgets — cuánto texto puede procesar una IA por llamada. No pueden manejar el fallback routing de modelos — cambiar a un modelo más barato cuando el caro alcanza sus límites de rate. No tienen concepto de versionado de prompts, gestión de ventana de contexto, ni evolución del schema de tool-calls. Acoplar agentes a Temporal implica escribir una capa de traducción entre "paso de workflow" y "llamada de inferencia" — y mantenerla cada vez que tu proveedor de modelo cambia su API.

Las plataformas de agentes no entienden durabilidad. Tratan las tool calls como efectos secundarios efímeros de la inferencia, no como transiciones de estado que necesitan garantías transaccionales. Un LLM llamando una herramienta es filosóficamente distinto a un paso de workflow llamando una función: el LLM podría decidir llamar la herramienta de nuevo, llamar una herramienta diferente, o alucinar una herramienta que no existe. Los motores de workflow asumen definiciones de pasos determinísticas. Los LLMs son, por definición, no determinísticos.

Ningún lado está equivocado. Están resolviendo mitades diferentes del mismo problema.

Qué Significa Esto Para Ti

Si tu agente modifica estado externo en más de tres pasos — envía correos, escribe en bases de datos, llama APIs de terceros — ya necesitas garantías de motor de workflow. Tu plataforma de agentes no las provee. Tienes tres opciones:

  1. Integrar Temporal/Restate por tu cuenta. Complejidad de integración real, pero durabilidad probada en batalla. Vale la pena si corres agentes en producción con SLAs reales.
  2. Ir full Cloudflare. Si ya estás en Workers, Project Think te da agentes durables sin el overhead de orquestación. El trade-off: vendor lock-in.
  3. Aceptar la tasa de fallo y construir herramientas de reconciliación manual. Honestamente, para herramientas internas con usuarios tolerantes, puede ser racional. Solo no lo llames "production-ready."

La convergencia es inevitable. El primer vendor que incluya ejecución de máquina de estados durable como primitiva por defecto en sus agentes — no como parche, no como integración de terceros — se adueña de la capa de confiabilidad en producción por encima de los tres runtimes. Temporal lo sabe; su integración con el Agents SDK de OpenAI es un land grab. Cloudflare lo sabe; Project Think está diseñado para hacer de los agentes una feature de plataforma.

Tu demo de siete pasos sigue funcionando perfecto. Mandarlo a producción sigue significando elegir con qué modo de fallo puedes vivir.