Tus agentes son sin estado. Por eso mueren.

En tu laptop, un agente corre de principio a fin de un solo tirón, y nunca ves el problema. Piensa, llama algunas herramientas, termina, listo. Se ve sólido.

Producción es otra bestia. Ahí el agente es un proceso largo, de múltiples pasos, corriendo sobre infraestructura que reinicia despliegues, mata containers que usan demasiada memoria y expira conexiones — de forma rutinaria, como un hecho de la vida. Y el agente típico mantiene todo su progreso en un solo lugar: memoria. Así que en el momento en que el proceso parpadea, cincuenta pasos de trabajo costoso desaparecen, y el agente empieza de nuevo desde cero. Haz eso en un workflow que toma horas y puede que nunca termine.

El ajuste de cuentas: es el runtime, no el modelo

Ahora hay un nombre para esta realización. VentureBeat lo llamó el "ajuste de cuentas agéntico", y la tesis es exacta: las empresas están descubriendo que el punto de falla no es el razonamiento del modelo, es el runtime. Los agentes pegados con "Python scripts, cadenas de LangChain, orquestación improvisada" no pueden sobrevivir a producción, no porque no sean inteligentes, sino porque son sin estado (stateless) — no tienen memoria durable de lo que ya hicieron. Un análisis de la realidad operativa es directo: los reinicios de container borran el contexto, y para agentes de larga duración (más de cuatro horas), los sistemas sin persistencia de estado cargan un 90% más de riesgo de falla total de la tarea por un timeout o un tropiezo de la infra.

Esta es la parte que se pierde en cada debate de "¿es el modelo lo bastante inteligente?". Tu agente no muere porque no pueda razonar. Muere porque es un script que finge ser un sistema, sobre infraestructura a la que no le importa qué tan listo es.

Y ahora también es un incendio de dinero

Ser sin estado solía costarte solo tiempo. En 2026 te cuesta la factura de tokens encima. Cuando un agente de 100 pasos se cae en el paso 47 y reinicia desde el paso 1, no solo pierdes el tiempo — vuelves a pagar por todos los tokens que los pasos 1 al 47 ya quemaron, y los quemas de nuevo. Un agente de larga duración sin estado es un problema de confiabilidad y un problema de control de costos vistiendo el mismo abrigo. La parte costosa del trabajo es exactamente la parte que sigues tirando y rehaciendo.

El arreglo tiene cuarenta años (otra vez)

La cura no es un modelo más inteligente ni un prompt más ingenioso. Es durable execution (ejecución durable), y es la misma idea que ha corrido los batch jobs de la banca y los pipelines de pedidos durante décadas: persiste cada paso a medida que lo completas, y cuando el proceso muere, reanuda desde donde te detuviste en lugar de desde el inicio.

Temporal, el motor más conocido para esto, describe el modelo con claridad: registra cada paso de un workflow como un historial de eventos inmutable, de modo que si el proceso muere en el paso 47 de 100, reproduce el log y reanuda en el paso 48 — no en el paso 1. El agente obtiene una memoria de su propio progreso que sobrevive a caídas, reinicios y redespliegues. Esto no es novedoso; es checkpointing, sagas e idempotencia — la plomería de cualquier job de larga duración serio. Como lo puso un ingeniero, los workflows de agentes simplemente están redescubriendo durable execution. El mercado coincide en que es estructural: Temporal levantó una ronda de $300M con una valuación de $5B a principios de 2026, y LangGraph y Vercel Workflows han estado corriendo para agregar las mismas garantías.

La trampa honesta

Durable execution es necesario, no mágico, y hay una sutileza que tienes que respetar o te muerde. El replay funciona volviendo a correr tu workflow y reutilizando el resultado registrado en el journal (registro) de cada paso que ya hizo. Pero una llamada a un LLM es no determinista — córrela dos veces y obtienes dos respuestas distintas. Así que no puedes simplemente dejar que el replay la vuelva a correr. Tienes que envolver cada llamada al modelo (y cada llamada a herramienta con efecto secundario) como una "activity" registrada cuyo resultado se anota en el journal en la primera corrida y nunca se vuelve a ejecutar en el replay. Equivócate en esa frontera y tu "recuperación" silenciosamente hace el trabajo — y te cobra — dos veces. Esto es ingeniería real, no una librería que espolvoreas encima.

El punto

Un agente en producción es un proceso distribuido de larga duración. Ya he argumentado antes que un sistema multiagente es un sistema distribuido y falla como tal; esta es la misma verdad un nivel más abajo. Trata al agente como el proceso durable y reanudable que necesita ser — estado con checkpoint, pasos idempotentes, recuperación que realmente probaste — o acepta que cada reinicio de container lo manda de vuelta a cero.

Tu agente no está fallando porque no sea lo bastante inteligente. Está fallando porque no tiene memoria de lo que ya hizo, y la infraestructura sobre la que vive le va a seguir quitando el piso. Dale estado durable, o míralo morir en el paso 47 — una y otra vez, pagando el precio completo cada vez.