Cada equipo que despliega un sistema con agentes IA termina haciendo la misma pregunta, normalmente hacia el tercer mes: "¿necesitamos Temporal / Inngest / Restate, o basta con añadir retries?"
La respuesta es casi siempre "necesita el orquestador durable, pero por una razón que no es 'retries'."
Qué resuelven en realidad los retries
Los retries son la herramienta adecuada cuando un fallo transitorio lo observa el mismo proceso que emitió la llamada. Un fallo de red, una respuesta de rate-limit, un downstream inestable — el llamador tiene el resultado fallido en mano, sabe qué intentaba hacer y simplemente puede volver a intentarlo.
Para esto necesita: una política de retry con exponential backoff, un tope de intentos máximos e idempotencia en el receptor. Eso es una librería, no un sistema. p-retry, tenacity, tokio-retry — elija una y siga adelante.
Qué resuelve en realidad la ejecución durable
La ejecución durable es la herramienta adecuada cuando el proceso mismo puede morir entre pasos. Un crash, un deploy, k8s desalojando el pod, una llamada al LLM de 30 minutos que excede su timeout de request — la pregunta no es "¿podemos reintentar?" sino "¿en qué punto estábamos cuando se cortó la luz, y cómo retomamos sin rehacer las partes que ya tuvieron éxito?"
Este es un problema fundamentalmente distinto. Necesita:
- Estado de paso persistente — un log de qué pasos se completaron, con sus resultados.
- Historial reproducible — cuando el proceso retoma, recorre el log, omite los pasos terminados y continúa desde el primero inacabado.
- Límites de paso deterministas — código estructurado para que el orquestador pueda identificar pasos sin ambigüedad entre replays.
Puede escribir esto desde cero. La gente lo hace. Son seis meses depurando race conditions antes de darse cuenta de que ha construido una versión peor de Temporal.
La decisión real
Si su sistema con agentes IA tiene:
- Llamadas a tools que individualmente tardan más de unos pocos segundos,
- Workflows con más de ~3 pasos secuenciales,
- Un handoff o un human-in-the-loop en algún punto intermedio,
- SLAs que no toleran que un reinicio por deploy cause un fallo visible al usuario,
…necesita un orquestador durable. No "podría quererlo para tener algunos extras". Lo necesita, y añadirlo después saldrá mucho más caro que empezar con él.
Si su sistema es corto, sincrónico y sin estado (un prompt, una respuesta, terminado en 5 segundos), los retries son suficientes. No sobre-ingenierice.
Lo que entregamos
En la práctica, nuestro default es Temporal o Restate (según el stack de lenguaje), con código de workflow estructurado de modo que cada llamada al LLM, cada invocación de tool y cada aprobación sea un paso aparte. El coste es algo de curva de aprendizaje y un runtime que operar. El beneficio es que "qué pasa cuando este proceso crashea a mitad del workflow" deja de ser una pregunta que tenemos que responder por cada nueva feature — el orquestador la responde una vez.
Los retries resuelven "esta llamada falló". La ejecución durable resuelve "este workflow tiene que sobrevivir a fallos de lo que lo ejecuta". No son alternativas — la mayoría de los sistemas en producción necesitan ambas, y es la segunda la que la gente subestima.