Un chatbot puede olvidar una conversación y causar una molestia. Un agente que lleva seis horas modificando archivos, consultando sistemas y esperando una aprobación puede dejar un problema bastante más serio.
La diferencia no está en cuánto tiempo «piensa» el modelo. Está en la arquitectura que permite interrumpir el trabajo, entender qué ocurrió y continuar sin repetir acciones ni perder el objetivo.
Mantener una petición abierta no basta
Una inferencia compleja ejecutada en segundo plano resuelve un problema de latencia. No resuelve un proceso que debe llamar a veinte herramientas, esperar a una persona, reanudar al día siguiente y recuperarse si un trabajador se reinicia.
En ese caso, el modelo propone pasos e interpreta resultados. La continuidad pertenece al orquestador.
La documentación actual del OpenAI Agents SDK separa precisamente la ejecución del agente de las integraciones de ejecución durable. El estado de una ejecución puede serializarse y reanudarse, mientras que motores como Temporal, Dapr, Restate o DBOS se encargan de trabajos que atraviesan esperas, reintentos y reinicios. Otros runtimes adoptan el mismo principio: LangGraph persiste checkpoints en los límites del grafo para recuperar una ejecución interrumpida.
Esto cambia la pregunta de diseño. Ya no es «¿cómo mantenemos viva la sesión?», sino «¿qué debemos guardar para que cualquier trabajador autorizado pueda continuarla correctamente?».
La conversación no puede ser la única memoria
Guardar todos los mensajes funciona hasta que el contexto crece, se compacta o contiene una versión antigua del plan. Una transcripción mezcla hechos, intentos fallidos, instrucciones y resultados. No es una base de datos de estado.
Un agente durable suele necesitar cuatro clases de información separadas:
| Estado | Qué contiene | Por qué se conserva aparte |
|---|---|---|
| Contrato de trabajo | Objetivo, alcance, restricciones, criterio de éxito y versión de las instrucciones | Evita que el propósito cambie silenciosamente entre sesiones |
| Estado de ejecución | Fase actual, pasos completados, dependencias, intentos, bloqueos y próxima acción | Permite reanudar sin reconstruir el proceso a partir del chat |
| Artefactos | Documentos, código, consultas, resultados y evidencias producidas | Son la realidad del trabajo; no deberían vivir como texto copiado en el contexto |
| Registro de eventos | Llamadas a herramientas, decisiones, aprobaciones, errores, costes y tiempos | Explica qué ocurrió y permite auditar o reproducir un incidente |
La ventana de contexto pasa a ser una vista temporal: objetivo vigente, estado necesario, evidencias y un resumen de lo hecho. Al abrir una sesión limpia, los artefactos y el progreso permanecen fuera de ella.
Anthropic describe una solución parecida en sus pruebas con agentes que trabajan a través de varias ventanas de contexto: cada sesión avanza de forma incremental y deja archivos de progreso y un entorno verificable para la siguiente. En 2026 llevó esta separación más lejos al describir los agentes gestionados como tres componentes distintos: sesión —un registro inmutable—, harness —el bucle que dirige modelo y herramientas— y sandbox —el lugar donde se ejecuta el trabajo— (Anthropic, 2026).
La arquitectura mínima de una ejecución durable
No existe una única pila tecnológica, pero las responsabilidades cambian poco:
El registro de trabajos asigna una identidad estable a cada encargo y conserva propietario, estado, prioridad, versión y presupuesto. La URL de una conversación no sirve como identificador de un proceso repartido entre varios servicios.
El orquestador durable decide qué paso está listo, entrega el trabajo a un ejecutor y guarda un checkpoint al completar una transición segura. Si el proceso se cae mientras espera una aprobación, no consume un trabajador durante ocho horas. Queda suspendido y vuelve a la cola cuando llega el evento.
El runtime del agente prepara el contexto, llama al modelo, valida su salida y despacha herramientas. El plan es revisable: los resultados reales mandan.
El gateway de herramientas aplica contratos de entrada, permisos, tiempos máximos e identificadores de idempotencia. También separa al modelo de credenciales directas. El agente solicita «crear borrador de pedido»; la capa de herramientas comprueba si puede hacerlo, con qué datos y bajo qué identidad.
El almacén de estado y artefactos guarda datos estructurados y entregables. Los documentos pueden vivir en un repositorio de objetos; el estado, en una base transaccional; las búsquedas, en un índice. Una memoria vectorial no sustituye esas funciones.
Por último están los verificadores. Un agente no debería terminar solo porque el modelo afirma que ha terminado. Puede exigirse que pasen pruebas, que todas las fuentes estén citadas, que un esquema sea válido o que una persona apruebe el resultado.
Los fallos incómodos aparecen después de la demo
El primero es la repetición de efectos. Un agente llama a una API para crear una orden, pierde la conexión antes de recibir la respuesta y reintenta. Si la operación no es idempotente, acaba de crear dos órdenes. Conviene asumir que un paso puede ejecutarse más de una vez: utilizar claves de idempotencia, consultar el estado antes de repetir y separar «preparar» de «confirmar» en acciones sensibles.
Los puntos de pausa merecen el mismo cuidado. En LangGraph, por ejemplo, un nodo interrumpido vuelve a comenzar cuando se reanuda; su propia documentación advierte que los efectos anteriores a la interrupción deben ser idempotentes (LangGraph Interrupts). El detalle pertenece al framework, pero el problema es general.
También caducan credenciales y cambian datos. Un checkpoint no garantiza que el mundo siga igual. Al reanudar hay que validar precondiciones: versión del documento, permisos y resultados temporales.
Otro fallo frecuente es confundir actividad con progreso. Un bucle puede buscar, reformular y volver a buscar durante horas sin acercarse al objetivo. El sistema necesita presupuestos por tiempo, coste, turnos y errores consecutivos; también una señal medible de progreso. Si tres ciclos no añaden evidencia ni completan una dependencia, quizá corresponda cambiar de estrategia o escalar a una persona.
Un expediente que tarda dos días, no dos días de cómputo
Pensemos en un agente encargado de preparar la documentación técnica para una licitación. Debe localizar requisitos, cruzarlos con políticas internas, pedir certificados que faltan, redactar respuestas y reunir aprobaciones de Seguridad y Legal. El calendario puede ocupar dos días, aunque el modelo solo trabaje durante algunos minutos en cada tramo.
El contrato fija la licitación, la fecha límite, las fuentes y los entregables. Cada hallazgo queda ligado a su documento y versión, no enterrado en la conversación.
Si falta un certificado, el agente registra el bloqueo y la ejecución se suspende. Al recibirlo, comprueba proveedor y periodo. Ante una declaración contractual no estándar, prepara una propuesta y abre una aprobación con el texto, la fuente y la acción prevista.
Al final, un verificador revisa que cada requisito tenga respuesta, evidencia y estado. El agente entrega un dossier y un registro de asuntos pendientes. «He terminado» no es un mensaje del modelo; es el resultado de superar ese control.
Qué debe poder responder el sistema
Antes de llamar «de larga duración» a un agente, debería ser posible contestar con precisión:
- ¿Cuál es el objetivo vigente y quién puede modificarlo?
- ¿En qué paso está, qué ha completado y por qué está bloqueado?
- ¿Qué acciones externas ha ejecutado y con qué identidad?
- ¿Puede repetirse el último paso sin duplicar efectos?
- ¿Qué ocurrirá si el trabajador se reinicia ahora?
- ¿Qué datos y artefactos encontrará una nueva sesión?
- ¿Dónde necesita aprobación y cuánto tiempo puede esperar?
- ¿Qué límite de coste, tiempo o intentos detendrá el bucle?
- ¿Qué prueba demuestra que el resultado es aceptable?
Si las respuestas dependen de releer el historial del chat, todavía tenemos un chatbot persistente. No un sistema durable.
Preguntas frecuentes
¿Una ventana de contexto grande resuelve el problema?
No. Mantiene más información durante una sesión, pero no sustituye checkpoints, recuperación de fallos, control de efectos externos ni persistencia de artefactos. Cargar todo el historial también aumenta coste y ruido.
¿Cada cuánto debe guardarse un checkpoint?
En límites donde el estado sea coherente: tras una unidad de trabajo, antes de una espera larga o después de confirmar una acción externa. La frecuencia depende del coste de rehacer el paso y del riesgo de duplicarlo.
¿Es necesario un motor de workflows?
No para todos los agentes. Una tarea corta y sin efectos sensibles puede funcionar con una cola, una base de datos y un trabajador. Cuando aparecen esperas largas, reintentos, varios servicios, aprobaciones o requisitos de recuperación, un motor de ejecución durable evita implementar de nuevo buena parte de esa lógica.
¿Cómo se mantiene la trazabilidad durante varios días?
Con un identificador estable del trabajo y una traza que agrupe sesiones, llamadas al modelo, herramientas, aprobaciones y verificaciones. El tracing del OpenAI Agents SDK registra generaciones, llamadas a herramientas, handoffs, guardrails y eventos personalizados; otras plataformas ofrecen conceptos equivalentes. Conviene separar la telemetría técnica del registro de auditoría que el negocio deba conservar.
¿Dónde debe intervenir una persona?
En acciones irreversibles o sensibles, decisiones con ambigüedad material y excepciones que el sistema no pueda validar. La ejecución debe poder persistir el punto de interrupción y reanudarse con la decisión. El patrón de RunState y aprobación conserva llamadas pendientes y metadatos para continuar incluso tiempo después.
Diseñar para el reinicio
La prueba más reveladora no consiste en dejar al agente trabajando toda la noche. Consiste en apagar un ejecutor a mitad de una tarea, arrancar otro y comprobar que sabe qué ocurrió, qué no debe repetir y cuál es el siguiente paso seguro.
Cuando esa prueba funciona, la duración deja de ser una heroicidad del modelo. Se convierte en una propiedad del sistema. Y esa es la diferencia entre una conversación que se alarga y un agente al que se le puede confiar trabajo real.
En INSTINTIA diseñamos estos sistemas empezando por el proceso, los límites de autonomía y las condiciones de recuperación. La elección del modelo llega después, porque ningún modelo compensa un estado perdido o una acción duplicada.
Fuentes y lecturas recomendadas
- Running agents — OpenAI Agents SDK, documentación consultada el 18 de agosto de 2026.
- Human-in-the-loop — OpenAI Agents SDK, documentación consultada el 18 de agosto de 2026.
- Tracing — OpenAI Agents SDK, documentación consultada el 18 de agosto de 2026.
- Effective harnesses for long-running agents — Anthropic, 26 de noviembre de 2025.
- Scaling Managed Agents: Decoupling the brain from the hands — Anthropic, 8 de abril de 2026.
- Persistence — LangGraph, documentación consultada el 18 de agosto de 2026.
- Interrupts — LangGraph, documentación consultada el 18 de agosto de 2026.
Fuentes y vigencia técnica revisadas el 18 de agosto de 2026.