Ejecución durable para agentes de IA: el motor vive en el código

Un agente en producción no suele morir al final. Muere a mitad de camino. La décima etapa de un flujo de veinte, una aprobación humana pendiente desde hace dos horas, un sistema externo caído, una sesión de API que expiró en el intervalo. La cuenta del desastre no está en la falla en sí. Está en la pregunta siguiente: rehacer todo desde el principio, o retomar desde el último punto válido.

La diferencia entre rehacer y retomar es lo que la ingeniería llama ejecución durable, y volvió al centro del debate con el anuncio del Workflow Development Kit de Vercel: durabilidad como concepto del lenguaje, código asíncrono común que persiste su propio progreso y lo retoma después de un crash o de un deploy, sin colas y sin máquinas de estados en YAML. La posición de este texto va más allá del anuncio: para agentes de IA de larga duración, el motor de ejecución pertenece al código, como propiedad del flujo, con checkpoint donde el equipo decide, y no como un producto distribuido alquilado a su lado.

El argumento no depende del SDK ni del fabricante. Descansa en fuentes que ningún pitch reemplaza: el paper que describió las transacciones de larga duración en 1987, el que formalizó la ejecución durable en serverless en la ASPLOS 2022 y un postmortem público de 2018 en el que 43 segundos de partición de red se convirtieron en 24 horas y 11 minutos de servicio degradado. Al final de cuentas, la ejecución durable es una decisión de contabilidad: quien paga las etapas repetidas paga la arquitectura que las repite.

Los agentes de larga duración no fallan como preguntas de chat

Una pregunta de chat que falla cuesta volver a escribirla. Un flujo de agente que falla cuesta las etapas ya ejecutadas: tokens facturados, llamadas realizadas, horas de espera por una aprobación. Los agentes de IA de larga duración cargan ese costo acumulado, y la ejecución durable es la propiedad que transforma rehacer en retomar. Sin ella, cada falla vuelve a facturar la cuenta completa.

El patrón de falla de un flujo de horas es de otra naturaleza. El agente atraviesa etapas secuenciales, algunas con efecto externo difícil de revertir, y cae exactamente donde el mundo externo participa: la aprobación del gerente, la respuesta del ERP, el webhook del socio. Mientras espera, paga. Cada token de contexto reenviado se factura, y la espera por un humano no es tiempo ocioso, es tiempo de exposición.

La falla nunca es cuestión de si, es cuestión de dónde.

Entre dos etapas cualesquiera existe una capa que decide quién llama a qué, con qué permiso y qué rastro, y esa capa ya tiene tratamiento dedicado en la capa de control del tráfico de herramientas de los agentes. La capa de ejecución es otra y es la menos discutida de las tres: decide qué sucede con la etapa que murió a mitad de camino. La confusión es vieja: la misma palabra cubre las dos capas, y el comprador sale de la sala creyendo que compró recuperación de fallas en agentes de IA cuando compró una cola.

Qué es la ejecución durable en un agente de IA

La ejecución durable es la propiedad de un flujo que graba un checkpoint en cada etapa y retoma desde el último punto válido después de una falla o de un reinicio. El estado persiste fuera de la memoria del proceso, y la reanudación ejecuta solo lo que quedó pendiente. Rehacer se vuelve excepción; retomar, el comportamiento por defecto.

Tres piezas definen el mecanismo. El checkpoint graba, antes del paso siguiente, el resultado de la etapa concluida, las variables del flujo y la posición exacta dentro de la secuencia. El runtime reconstruye el estado a partir de ese registro, no de la memoria de un proceso vivo. La reanudación ejecuta entonces la etapa pendiente, y solo ella.

La formalización académica es reciente, y el concepto es viejo. Los sistemas batch de mainframe de los años sesenta ya grababan checkpoint y reiniciaban el job desde el último punto válido. El paper Durable Functions: Semantics for Stateful Serverless, publicado en la ASPLOS 2022, le dio al concepto semántica formal en el mundo serverless: el flujo escribe un log de eventos, el runtime reejecuta ese log de forma determinista para reconstruir el estado, y la reanudación sobrevive a un deploy, a un crash y a un cambio de escala.

El detalle que separa la definición de la práctica es el orden entre grabar y actuar. Un checkpoint grabado antes del efecto externo abre espacio a un retry que aplica el efecto dos veces. Un checkpoint grabado después pierde la etapa completa cuando el proceso muere entre el efecto y la grabación. Ventana de pérdida y duplicación de efecto: aquí la ejecución durable deja de ser una función lista para usar y se vuelve diseño.

Dónde vive el estado del agente entre las etapas

El estado vive en el log de ejecución del flujo, no en la memoria de un proceso: el resultado de cada etapa, las decisiones tomadas y la posición actual se graban como checkpoint antes del paso siguiente. Retomar desde el último punto válido significa ejecutar solo la etapa pendiente, sin volver a facturar las llamadas de modelo ya pagas.

La pregunta de quién paga la factura es más estrecha que la de quién diseña la arquitectura: qué sucede con las llamadas ya pagas cuando el flujo muere. Con checkpoint, la respuesta es nada. Su resultado está en el log, y la reanudación no repite la llamada. Sin checkpoint, la respuesta es todo: el flujo no sabe qué ya corrió y corre de nuevo. La diferencia entre las dos respuestas es la factura de tokens del mes.

El estado trae un segundo problema, el efecto externo. El paper Sagas, de Hector Garcia-Molina y Kenneth Salem, publicado en la SIGMOD de 1987, describió el problema antes de que existiera el agente: una transacción de larga duración se divide en etapas, y cuando una falla, las concluidas no se deshacen solas, exigen acciones compensatorias. Cuarenta años después, la traducción es directa: la etapa que emitió un pago necesita un mecanismo idempotente, porque un retry aplica el efecto dos veces, y la acción compensatoria es el plan B caro.

El tercer problema es el estado que diverge. El postmortem de GitHub del 30 de octubre de 2018 es el caso de estudio: 43 segundos de pérdida de conectividad entre dos data centers se convirtieron en 24 horas y 11 minutos de servicio degradado, no porque la partición fuera grave, sino porque dos clusters pasaron a contener escrituras que el otro no tenía. La reconciliación manual de unos pocos segundos de escrituras siguió en curso días después, y uno de los clusters con más movimiento tenía 954 escrituras en la ventana afectada. Al reanudar la cola, cerca de 200 mil payloads de webhook habían expirado y fueron descartados. El estado mal administrado cobra intereses: la falla original duró 43 segundos, sus consecuencias duraron días.

Motor de orquestación dedicado o ejecución en el código: dónde está el costo real

Un motor de orquestación dedicado entrega cola, programación y visibilidad centralizada, y por eso cobra un sistema distribuido entero para operar. La ejecución durable en el código entrega checkpoint y reanudación como propiedad del flujo, con la granularidad que el equipo elija, y cobra disciplina de escritura. La diferencia aparece en la primera falla, en la factura y en la adaptación del flujo.

La palabra heredada confunde: la orquestación de agentes de IA cubre, en el mismo aliento, la cola que distribuye trabajo y la lógica que recupera fallas, y son problemas distintos. Las tres diferencias de costo viven en lugares distintos. La primera es la granularidad de la reanudación. Cuando un flujo orquestado por un motor dedicado falla a mitad de una etapa, la reanudación ocurre en la granularidad que el motor define: en los casos en que no carga el estado de la etapa en el punto de la falla, el trecho vuelve a correr completo, llamadas ya pagas incluidas. La ejecución en el código coloca el checkpoint donde el desarrollador decide, y la reanudación rehace solo lo pendiente.

La segunda es el costo de las etapas ociosas. Un flujo de agente pasa la mayor parte de su vida esperando: aprobación humana, respuesta de un sistema externo, ventana de procesamiento. El motor dedicado es infraestructura que corre, y cuesta, incluso con todo el flujo bajo su guardia en espera. Los runtimes de ejecución durable diseñados para suspender el flujo entre etapas no gastan recursos en la espera, y la infraestructura que sobra es la que la empresa ya operaba. A escala, se convierte en una línea del presupuesto.

La tercera es la curva de adopción. Un flujo escrito como código común entra en el repositorio, en el code review, en los tests y en el CI que la empresa ya opera. Un flujo escrito en la semántica de un motor dedicado carga un segundo sistema distribuido para operar, con versión propia, topología propia e incidentes propios. El postmortem de 2018 muestra el modo de falla característico de esa transferencia: el mecanismo de failover actuó exactamente según lo configurado, y fue la aplicación la que no soportó la topología resultante. La herramienta dedicada atrae la semántica hacia su interior; el código deja la semántica en manos de quien la escribe.

Queda la línea de la observabilidad, la peor leída de la tabla. El panel de un motor dedicado muestra la cola: cuántas ejecuciones, en qué estado, hace cuánto que esperan. Muestra que el flujo se detuvo. No muestra si la decisión de la etapa actual fue buena, y eso es lo que cubre la evaluación de agentes: qué medir más allá de la respuesta final. Cola visible no es comportamiento auditado.

Cuándo un motor dedicado todavía gana

En cargas de miles de flujos paralelos con garantías contractuales de nivel de servicio, un motor de orquestación dedicado entrega lo que el código puro no da por sí solo: visibilidad centralizada de flota, programación probada en producción y un producto con rastro de auditoría listo para el compliance. En esa configuración, el costo de operar el motor se paga.

El lado contrario tiene una versión fuerte. Un equipo de plataforma que opera cientos o miles de flujos en producción necesita ver la flota entera en un solo lugar, responder al incidente con un procedimiento conocido y mostrarle a un auditor una superficie de control reconocible. Un motor dedicado maduro vende exactamente eso, y la empresa que tiene ese equipo y esa carga compra un producto en vez de construir una plataforma interna. Es la compra correcta para quien tiene un problema de flota.

El argumento cae para la mayoría de las cargas de agentes B2B, y cae por aritmética. El flujo de agente en una empresa típica es contado, no flota: una conciliación, una clasificación de contratos, una aprobación de compras. Cambia todas las semanas, porque cambian la regla de negocio, el prompt y el conector. El equipo detrás rara vez es una plataforma dedicada. Para ese perfil, la flota es demasiado pequeña para justificar el producto y cambia demasiado rápido para la rigidez de una semántica ajena. El criterio práctico: flota de miles con equipo de plataforma compra motor; flota de pocos con equipo reducido escribe el checkpoint en el código.

Qué cambia esta decisión para quien compra agentes B2B

La ejecución durable deja de ser un detalle de ingeniería y entra en el contrato: dónde vive el checkpoint, qué sucede con la etapa de en medio, quién paga las llamadas repetidas y cómo auditar la reanudación. Un agente sin respuesta para estas cuatro preguntas no está listo para producción, por mejor que sea el modelo de abajo.

Las cuatro preguntas, con lo que cada respuesta compromete:

1. ¿Dónde vive el checkpoint? Quién es el dueño del estado: el flujo, en el almacenamiento que la empresa opera, o la estructura interna del producto. La respuesta decide quién toca la granularidad de la reanudación.
2. ¿Qué sucede con la etapa de en medio? Cuál es la unidad de reanudación: la etapa, el trecho o el flujo completo. La respuesta aparece en la factura de la primera falla.
3. ¿Quién paga las llamadas repetidas? Si la reanudación rehace llamadas de modelo ya pagas, el costo de la falla se duplica, y nadie presupuestó esa línea.
4. ¿Cómo se audita la reanudación? El rastro posterior a la falla necesita mostrar qué corrió de nuevo, qué fue compensado y qué llegó dos veces al cliente.

En la pila de Nexforce Agents, la decisión tiene dirección en las dos puntas. Nexforce Code es el runtime del desarrollador: agentes y subagentes definidos por proyecto, con skills, reglas de proyecto y soporte de MCP para herramientas y datos externos, corriendo en la terminal y en la IDE y también en ejecuciones headless para automatización y CI, en macOS, Windows y Linux. Nexforce Work es el espacio de trabajo del equipo de negocio: un entorno de escritorio donde equipos no técnicos corren agentes sobre sus propios archivos, herramientas y conectores, con orquestación multi-workspace, capa de aprobaciones y permisos, plantillas de workflow reutilizables, ejecución en sandbox y ejecuciones programadas para rutinas recurrentes.

Las aprobaciones de Work son el punto exacto donde un flujo de larga duración se pausa. Las ejecuciones programadas son el lado recurrente. Los conectores MCP son los sistemas externos que fallan a mitad de camino. Y dónde vive el checkpoint sigue siendo diseño de flujo: quien escribe el agente decide la granularidad de la reanudación.

Debajo, la capa de modelo es Nexforce Router: cientos de modelos detrás de una única API, con failover automático entre proveedores cuando uno se cae, porque la reanudación de un flujo necesita un modelo disponible para volver.

La decisión de arquitectura también entra en el caso de negocio: el ROI de los agentes de IA se mide antes de escalar el piloto, y el costo de rehacer es una de las líneas que casi nadie incluye en la planilla.

Preguntas frecuentes

¿Cómo se recupera un agente de IA de una falla a mitad de un flujo largo?

El agente lee el último checkpoint válido y ejecuta solo la etapa pendiente. El checkpoint lleva el resultado de las etapas concluidas y la posición en el flujo, así que la reanudación no repite llamadas ya pagas. Para efectos externos sensibles, como un pago emitido, la etapa necesita ser idempotente, porque un retry aplica el efecto dos veces.

¿Cómo validar que la ejecución durable de mi agente funciona antes de escalar?

La validación es fallar a propósito: la falla se inyecta entre dos etapas, la reanudación se verifica en el checkpoint correcto, ninguna llamada repetida aparece en la factura y el rastro muestra qué corrió de nuevo. El postmortem de GitHub de 2018 terminó en una iniciativa formal de fault injection. La ejecución durable no demostrada es la ejecución durable supuesta.

¿Un agente que corre en minutos también necesita ejecución durable?

Depende del costo de rehacer. Un flujo de una sola llamada se rehace barato, y el checkpoint allí es burocracia sin retorno. Un flujo con aprobación humana, un sistema externo en medio o una factura por token paga la reanudación desde la primera falla. El criterio es el costo del retrabajo, no la duración cronológica del flujo.

¿La ejecución durable reemplaza a la capa de control y a la de evaluación?

No. La recuperación de fallas en agentes de IA es una de las tres capas de la operación: el control decide quién llama a qué y con qué permiso, la evaluación decide si el comportamiento es bueno, y la ejecución durable decide qué sucede cuando el flujo muere a mitad de camino. Un agente que retoma perfectamente y decide mal sigue decidiendo mal.

¿La ejecución durable exige un motor dedicado?

No es requisito. El checkpoint puede grabarlo la propia rutina del flujo, en el almacenamiento que la empresa ya opera, con la granularidad que el equipo elija. Un motor dedicado agrega cola, programación y visibilidad centralizada, y cobra un sistema distribuido entero por la conveniencia. La elección es de costo de operación, no de posibilidad técnica.

Referencias y Lectura Complementaria

Cuatro fuentes primarias sostienen el argumento.

• Built-in durability: Introducing Workflow Development Kit, el anuncio del WDK: la ocasión del debate sobre dónde vive la ejecución durable.
• Durable Functions: Semantics for Stateful Serverless, ASPLOS 2022: la formalización de la semántica de la ejecución durable en serverless.
• Sagas, Hector Garcia-Molina y Kenneth Salem, SIGMOD 1987: transacciones de larga duración, etapas y acciones compensatorias.
• October 21 post-incident analysis, GitHub, 30 de octubre de 2018: el postmortem público en el que 43 segundos de partición se convirtieron en 24 horas y 11 minutos de servicio degradado y en reconciliación manual de estado.

La decisión que queda

La próxima conversación sobre agentes, en la mesa de arquitectura o en la de compra, cambia de pregunta. En vez de «qué motor usan ustedes», la pregunta que decide es «muestren el checkpoint»: dónde vive, cuándo se graba y qué sucede con la etapa siguiente a la falla. Rehacer es la respuesta cara. Disfrazada de simplicidad, llega con la primera caída de un sistema externo a mitad de un flujo de veinte etapas. La ejecución durable escrita en el propio flujo es la versión en la que el agente retoma el turno de la madrugada sin nadie de guardia. Y la reanudación tiene dirección: el código es el único lugar donde la granularidad de la reanudación pertenece a quien paga la cuenta.