Cómo ejecutar agentes de IA de larga duración sin empezar de cero

El agente de IA de larga duración no falla en el primer paso. Falla en el paso 40, cuando ya abrió el ticket en el sistema de soporte, avisó al cliente por correo electrónico y lanzó el aprovisionamiento en el ERP. El proceso entero ya ocurrió. Entonces el proveedor de modelos se cae, el run muere, y alguien del equipo de operaciones teclea la frase más cara de la automatización corporativa: córralo otra vez desde el principio.

El contrato de operación que elimina esa frase tiene cinco puntos: checkpoint por etapa, clasificación de errores entre reanudable y fatal, idempotencia de los efectos externos, parada por aprobación humana y versionado de ejecuciones en curso. Se escribe en el diseño del agente, se verifica en el piloto y entrega un resultado medible: el fallo que se reanuda en lugar de empezar de cero.

La industria acaba de admitir que la durabilidad es una decisión de arquitectura. El 27 de agosto de 2026, Vercel publicó The best workflow engine is a programming language, de Pranay Prakash, el argumento de que la ejecución duradera pertenece al propio código. La decisión ganó su manifiesto. Lo que falta es la capa siguiente: el contrato que hace que la ejecución duradera sobreviva al tercer mes, cuando el run está estacionado en una aprobación de cuatro días y el código ya subió tres versiones.

¿Qué es un agente de IA de larga duración?

Un agente de IA de larga duración es el que ejecuta un proceso que atraviesa horas, días o semanas: onboarding de clientes, aprobación de procurement, facturación recurrente, disputas de pago. No es una conversación larga. Es un proceso con estado, que toca sistemas externos y necesita sobrevivir a fallos parciales sin perder lo que ya hizo.

Un chatbot se equivoca y repite la respuesta. Un agente de larga duración se equivoca y el proceso queda a la mitad: el cliente avisado, el ticket abierto, el aprovisionamiento lanzado, el pago aún pendiente. La arquitectura de pregunta y respuesta vive de solicitudes de segundos; el run de un agente de IA en producción vive más que la conexión y, cuando el deploy llega antes del final, más que la versión del código que lo inició.

El contrato de operación tiene cinco puntos, uno por paso de esta guía:

1. Checkpoint por etapa. El estado que cada etapa compromete antes de la siguiente: entradas, salidas y decisión. La reanudación parte del último checkpoint, nunca de cero.
2. Clasificación de errores. Cada fallo recibe un destino escrito antes de que ocurra: el reanudable vuelve con backoff dentro de un presupuesto; el fatal termina con estado consistente.
3. Idempotencia de los efectos externos. El pago, el correo y el ticket ya pueden haber salido cuando llega el fallo; ninguno se repite en el camino de vuelta.
4. Parada por aprobación humana. El run se estaciona por minutos o semanas y sigue vivo, reanudándose por el mismo checkpoint cuando llega la decisión, sin perder lo comprometido.
5. Versionado de ejecuciones en curso. El código cambia; el run en vuelo termina en la versión que lo inició.

Sin los cinco, cada fallo cobra el proceso entero.

Con ellos, el fallo cuesta un desvío.

El mapa de adopción está en la guía de agentes B2B. La franja que casi ningún piloto prueba es esta: qué pasa cuando el run se rompe a la mitad.

¿Qué debe estar decidido antes del paso 1?

Antes del primer checkpoint, cuatro decisiones deben existir: el inventario de efectos externos del proceso, el estado mínimo que cada etapa lleva, quién aprueba qué y dónde vive el estado. Sin ese mapa, el checkpoint registra lo que no importa e ignora exactamente lo que la reanudación necesitaría.

Primera decisión, el inventario de efectos externos: todo lo que el proceso hace fuera de la propia máquina, llamada de API, pago, correo, ticket, aprovisionamiento. Cada línea se convierte en candidato a idempotencia en el Paso 3 y muestra dónde duele el fallo.

Segunda decisión, el estado mínimo por etapa: lo que el paso siguiente necesita saber para empezar. Guardar más crea un log enorme y un problema de versionado; guardar menos rompe la reanudación.

Tercera decisión, quién aprueba qué: la matriz de permisos del proceso, definida antes del diseño, nunca durante el incidente. Cuarta, dónde vive el estado.

La decisión de dónde vive la ejecución duradera, motor dedicado o ejecución escrita en el propio código, ya tiene dueño en este blog: el post Ejecución duradera para agentes de IA: el motor vive en el código cubre todo el debate. Esta guía no reargumenta. Asume la decisión tomada y construye la capa que ella sola no entrega: la operación que convierte durabilidad prometida en durabilidad observada.

Paso 1: define el checkpoint de cada etapa

El checkpoint es el estado que cada etapa compromete antes de llamar al paso siguiente: entradas recibidas, salidas producidas, decisión tomada. Definido por etapa, convierte el fallo en reanudación. El run vuelve del último checkpoint, no de cero, y lo que ya se hizo sigue hecho.

La regla de commit es simple y no negociable: el checkpoint graba antes del efecto externo, y el resultado del efecto graba apenas vuelve. Entre los dos, el run está en vuelo, y ese es el intervalo que los dos pasos siguientes protegen.

El estado comprometido lleva, por etapa, las entradas recibidas, las salidas producidas y la decisión tomada, incluido el dato que el equipo de negocio audita seis meses después. Estado mínimo no es estado pobre: es lo que la reanudación consume, no lo que el log colecciona.

Piensa en el checkpoint como el autoguardado de un editor de texto. Nadie escribe 40 páginas sin autoguardado. La diferencia: aquí el autoguardado no guarda un borrador, guarda un compromiso, el registro de lo que el agente ya le prometió al resto de la empresa.

Ese mismo registro por etapa es la materia prima para medir las etapas intermedias cuando el agente entra en producción: el dato que sirve a la reanudación sirve a la evaluación.

Paso 2: clasifica cada error entre reanudable y fatal

Cada fallo de un run necesita un destino escrito antes de que ocurra: el error reanudable vuelve con backoff dentro de un presupuesto de reintentos, el error fatal termina con estado consistente y señalización. Un transitorio que agota el presupuesto se reclasifica como fatal. Ningún run queda en bucle sin techo: todo run termina en reanudación, conclusión o cierre señalizado.

Taxonomía antes de código. El error transitorio es lo que la repetición resuelve: timeout de red, límite de tasa del proveedor, indisponibilidad momentánea. El error fatal es lo que la repetición agrava: entrada inválida del sistema de origen, regla de negocio violada, dato inconsistente que ningún intento arregla.

El presupuesto de reintentos es la pieza que el diseño apurado salta. Backoff exponencial sin límite no es una política de errores, es esperanza con cronómetro. El presupuesto declara cuántos intentos y cuánto costo gana el transitorio; agotado el presupuesto, el error pasa a fatal y el run termina con estado consistente y señalización. El error no sale del sistema por silencio.

El contrato queda auditable cuando cada clase tiene una fila:

La clasificación vive en el código del agente, una decisión por tipo de excepción. Un error nuevo en producción entra en la tabla antes de entrar en el tratamiento. Una clase no declarada es una clase decidida por el azar.

Paso 3: haz idempotente cada efecto externo

Un efecto externo idempotente produce el mismo resultado ejecutado una o dos veces: el pago único, el correo único, el ticket único. La clave de idempotencia se deriva de forma determinística del par run más etapa y nunca se regenera por intento, y el agente consulta el efecto anterior en el sistema externo antes de grabar de nuevo.

El hueco queda entre dos operaciones: la llamada externa sale, la red se cae, el checkpoint no llegó a grabarse. Del otro lado, el pago ocurrió. De este lado, el estado dice que no pasó nada. La reanudación reejecuta la etapa, y el cliente recibe el segundo cobro de la misma compra.

La clave de idempotencia cierra el hueco, y aquí la idempotencia en agentes de IA deja de ser jerga de pagos. Se deriva del par run más etapa, de forma determinística: mismo run, misma etapa, misma clave, en cada intento. Una clave regenerada por intento derrota el mecanismo, porque cada intento parece un efecto nuevo para el sistema externo. Con la clave estable, la repetición se convierte en pregunta: ¿ya existe el efecto con esta clave? Si existe, el agente consume el resultado grabado y sigue. Si no existe, lo ejecuta una vez y lo registra.

La verificación del efecto externo antes de grabar de nuevo complementa la clave, no la sustituye. La clave decide la identidad del efecto; la verificación cubre el sistema externo sin deduplicación nativa. Un cobro duplicado y revertido es una pérdida operacional. Un cobro duplicado y no detectado es una pérdida contable, de las que aparecen en el cierre de mes sin apellido de nadie.

Paso 4: diseña la parada por aprobación humana

La parada por aprobación humana es un estado del run, no una excepción: el agente de IA de larga duración se estaciona por minutos o semanas, el proceso sigue vivo y se reanuda por el mismo checkpoint cuando llega la decisión. El diseño define quién aprueba qué, plazo de expiración y ruta de escalamiento, con traza de auditoría de cada decisión.

El run se estaciona. Eso es el proyecto funcionando, no un cuelgue: los procesos B2B reales esperan aprobación de crédito, validación jurídica, confirmación del cliente. La diferencia entre una parada diseñada y un run perdido está en tres decisiones: cómo entran y salen los datos de un run en ejecución, cómo ocurre la reanudación y qué pasa cuando la decisión no llega.

Los datos pasan por el mecanismo de reanudación que la plataforma expone, webhook o hook. El contrato del callback no cambia: la decisión llega firmada, con la identidad de quién aprobó, timestamp y el payload que consume la etapa siguiente. Esa traza es la auditoría del proceso, diseñada junto con el permiso, no después. La capa de aprobaciones y rastreo de las acciones del agente detalla quién autoriza qué y cómo queda registrada cada acción.

El plazo existe porque una aprobación sin expiración es un proceso en el limbo. El diseño declara cuánto tiempo espera la parada y hacia dónde escala cuando el plazo vence: otro aprobador, otro canal, un run de recordatorio. Es la corrección del fallo clásico de la aprobación humana en agentes de IA, la aprobación estacionada sin camino de vuelta.

Paso 5: versiona sin romper ejecuciones en curso

Cambiar el código de un agente con ejecuciones en curso rompe la reanudación cuando el código nuevo reinterpreta el estado grabado por el viejo. El run en vuelo necesita terminar en la versión que lo inició. Cada run queda fijado a la versión que lo creó, y la versión nueva vale para los runs que empiezan después.

El mecanismo detrás es el replay determinístico: la reanudación reconstruye el camino recorrido a partir del estado comprometido, y la reconstrucción solo tiene sentido con el código que lo grabó. La versión A graba un checkpoint con tres campos. La versión B espera cinco. El replay no se rompe con estruendo; deriva, y decide con un campo que no existía. Estado corrupto en silencio es el peor estado que un sistema produce.

La industria convergió en la misma respuesta, con nombres distintos. El concepto es genérico. Fijar cada ejecución a la versión que la inició: el run lleva la marca de la versión, la versión vieja sigue ejecutable mientras haya runs en ella, y la migración de runs estacionados es una decisión explícita, con prueba de replay entre versiones. El deploy solo afecta a los runs que aún van a nacer.

¿Cómo probar que el agente realmente se reanuda?

La prueba que demuestra la reanudación es la inyección de fallos: matar el run a la mitad de una etapa, confirmar que vuelve del último checkpoint, verificar que ningún efecto externo se duplicó y que la salida final es la esperada. La prueba incluye verificar que la clave de idempotencia es la misma antes y después del fallo inyectado.

La confiabilidad de los agentes de IA no se declara, se demuestra. La suite de abajo corre en el ambiente de pruebas antes del piloto y vuelve a correr después de cada cambio de versión. El run muere a propósito:

1. Mata el run a la mitad de una etapa que ya llamó a un sistema externo, con el checkpoint aún sin grabar.
2. Confirma la reanudación desde el último checkpoint comprometido, sin reejecutar etapas anteriores.
3. Verifica cero efectos duplicados: un pago, un correo, un ticket, cada efecto existiendo exactamente una vez.
4. Comprueba la estabilidad de la clave de idempotencia: la clave generada antes del fallo inyectado es la misma después de él.
5. Inyecta un error fatal y confirma el cierre con estado consistente y señalización correcta.
6. Inyecta una parada por aprobación, reanuda por el callback y valida la salida final esperada.

Un agente que pasa las seis pruebas realmente se reanuda. Un agente que falla en el punto 3 no tiene contrato de operación; tiene una función larga con esperanza incrustada. La recuperación de fallos en agentes de IA es esta suite corriendo en cada versión, no un párrafo en la documentación.

¿Qué fallos siguen rompiendo agentes de larga duración?

Cuatro modos de fallo sobreviven cuando el contrato está mal aplicado: un efecto ejecutado dos veces después de la reanudación, una aprobación estacionada sin camino de vuelta, una actualización de código que rompe el run en vuelo y una deriva silenciosa de estado cuando el sistema externo cambia entre el fallo y la reanudación. Cada modo tiene una corrección conocida.

Efecto duplicado después de la reanudación. La causa clásica es la clave regenerada por intento, el antipatrón del Paso 3, o un checkpoint grabado después del efecto sin clave alguna. Corrección: clave determinística del par run más etapa, más la verificación del efecto externo antes de grabar de nuevo.

Aprobación estacionada sin camino de vuelta. El run se detuvo, el aprobador cambió de equipo, y nadie sabe que la espera se volvió abandono. El plazo de expiración y la ruta de escalamiento, definidos en el Paso 4, convierten la espera indefinida en una fila con dueño.

Actualización de código que rompe el run en vuelo. El deploy sube, el checkpoint de la versión anterior llega a la versión nueva, y el replay decide con un campo que no existía. Corrección del Paso 5: fijar el run a la versión que lo inició, con prueba de replay entre versiones.

Deriva silenciosa de estado. El sistema externo cambió entre el fallo y la reanudación. El stock se acabó. La política de crédito cambió. El cliente canceló el pedido. El checkpoint describe un mundo que ya no existe, así que la corrección es revalidar las precondiciones de la etapa en la reanudación y tratar la divergencia como un error clasificable, no como una excepción suelta.

¿Qué exigir a una plataforma de agentes B2B?

El contrato de operación se convierte en checklist de compra: pregunta cómo la plataforma guarda el estado por etapa, cómo clasifica y reclasifica errores, cómo sostiene efectos idempotentes, cómo mantiene vivo un run durante una aprobación de días y cómo protege los runs en vuelo durante una actualización. La respuesta que cuenta se verifica en el piloto, no en el folleto.

En la práctica, el comprador B2B tiene dos ambientes de implementación dentro de Nexforce Agents. Nexforce Work es el workspace de escritorio para el equipo de negocio: orquestación multi-workspace, capa de aprobaciones y permisos, ejecución en sandbox, runs programados, plantillas de workflow reutilizables y conectores MCP. Nexforce Code es el runtime para el equipo de ingeniería: agentes en la terminal y en el IDE, runs headless para automatización y CI, agentes y subagentes por proyecto, skills y soporte de MCP, en macOS, Windows y Linux.

Por debajo de los dos, el Nexforce Router opera la capa de modelos: enrutamiento, failover y gobernanza de costo de cada llamada. La plataforma se encarga del acceso al modelo; el contrato de operación sigue siendo diseño del proceso, porque la aprobación con plazo, la clave de idempotencia y la fijación de versión pertenecen al diseño del agente y se verifican con inyección de fallos.

El resto es folclore de ventas.

FAQ: agentes de IA de larga duración

Las preguntas que aparecen a la hora de diseñar el contrato, respondidas sin rodeos. Cada una corresponde a un paso de esta guía: definición y estado, prueba de reanudación, paradas por aprobación, idempotencia de los efectos externos y versionado de ejecuciones en curso. Los fallos reciben destinos, los efectos no se repiten y los runs en vuelo terminan en la versión que los inició.

¿Qué es un agente de IA de larga duración?

Es el agente que ejecuta un proceso con estado que atraviesa horas, días o semanas, tocando sistemas externos en cada etapa: onboarding, aprobaciones, facturación, disputas. A diferencia de una conversación, el run necesita sobrevivir a fallos parciales y a paradas de aprobación sin reiniciar el proceso entero.

¿Cómo demostrar que el agente se reanuda en lugar de empezar de cero tras un fallo?

Con prueba de inyección de fallos: mata el run a la mitad de una etapa, confirma la reanudación desde el último checkpoint, verifica que la clave de idempotencia es la misma antes y después del fallo y comprueba que ningún efecto externo se duplicó. La prueba es un resultado observado, no una promesa.

¿Los agentes de IA pueden esperar una aprobación humana por días?

Pueden. La espera es un estado diseñado del run, no un cuelgue: el proceso sigue vivo, con checkpoint, traza de auditoría y reanudación por el callback cuando llega la decisión. Un plazo de expiración y una ruta de escalamiento evitan que la espera se vuelva abandono silencioso.

¿Qué es la idempotencia y por qué los agentes de IA la necesitan?

La idempotencia es la propiedad del efecto que produce el mismo resultado ejecutado una o dos veces. Los agentes de IA la necesitan porque la reanudación tras un fallo nunca sabe si el pago, el correo o el ticket ya salieron; la clave determinística del par run más etapa impide el efecto duplicado.

¿Cómo actualizar el código de un agente con ejecuciones en curso?

Fijando cada ejecución a la versión que la inició: el run en vuelo termina en la versión vieja, con replay probado entre versiones, y la versión nueva vale solo para los runs que empiezan después. Sin esto, el código nuevo reinterpreta el estado grabado por el viejo y corrompe la decisión.

Referencias y lecturas complementarias

• Pranay Prakash, "The best workflow engine is a programming language", Vercel Blog, 27 de agosto de 2026. Post original.
• Ejecución duradera para agentes de IA: el motor vive en el código
• Permisos y acceso de agentes de IA: define y rastrea
• Evaluación de agentes: qué medir más allá de la respuesta final
• ROI de agentes de IA: cómo medir antes de escalar el piloto
• Agentes de IA en B2B: la guía completa para 2026
• Nexforce Agents

El contrato viene antes del piloto

La posición cabe en una línea: en agentes de IA de larga duración, el fallo no es el problema, el reinicio es. El reinicio es una decisión de diseño, no mala suerte: cinco puntos de contrato, una suite de inyección de fallos y un piloto que prueba la mitad del proceso.

La asimetría de costo decide el resto. Reanudar cuesta escribir un checkpoint y la disciplina de probar con fallo inyectado. Empezar de cero cuesta el proceso entero, los tres sistemas ya tocados y la paciencia del cliente que recibió el segundo cobro. Cuando el piloto no inyecta fallos, mide el camino feliz y esconde el costo del reinicio en el ROI del piloto, la cuenta que aparece después de la decisión de escalar.

Por eso el contrato viene antes del piloto: para cuando el run se cae, ya no existe tiempo de coser el paracaídas.