Runtime de AI agents de larga duración: sesiones y checkpoints

Viacheslav Dubrov

2026-05-26 · Actualizado 2026-08-01 · 44 min · Agentes de IA

Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Una ejecución de un agent puede durar horas, mientras que su proceso worker puede reiniciarse en cualquier momento. El modelo sigue eligiendo la siguiente acción, pero el runtime debe conservar el estado, controlar la ejecución y recuperarse de un fallo en mitad de un tool call. Este artículo define el límite del runtime. La parte 6 abre después el componente que decide dentro de él: el harness, donde la memoria, los contratos de herramientas y las comprobaciones de permisos dejan de ser tres temas para convertirse en un único programa.

¿Qué es un runtime de AI agent?

Un runtime de AI agent es la capa de infraestructura que mantiene vivo, aislado, observable y reanudable tras finalizar la llamada al modelo a un agent que utiliza herramientas. Gestiona el estado de la sesión, la ejecución de herramientas, los checkpoints, los secretos, las trazas, los límites de coste y la forma de despliegue. El modelo elige la siguiente acción; el runtime determina dónde se ejecuta, cómo se registra y cómo se reanuda la ejecución tras un fallo. El harness decide si la acción está permitida. El harness no es una capa de almacenamiento: es el programa que se apoya en ellas, y aparece en la tabla siguiente porque también hay que ubicarlo.

Cuatro de esas cinco —session, sandbox, checkpoint y trace— almacenan estado o confinan la ejecución. El harness es el que decide, y es donde confluyen las decisiones sobre memoria, contratos de herramientas y permisos. Este artículo lo trata como una única caja y describe sobre qué se apoya. La parte 6 abre esa caja y reorganiza los mismos cinco elementos entre el componente que decide y los cuatro sobre los que se ejecuta.

Las ejecuciones largas rompen las suposiciones de los procesos sin estado

Un endpoint de chat sin estado puede mantener el estado de la petición en un único proceso y descartarlo después de responder. Una ejecución larga de un agent atraviesa reinicios de workers, despliegues, resets de contexto y pausas para aprobación. El proceso worker ya no puede ser la fuente de verdad.

El equipo de OpenAI Codex explica cuánto pueden durar estas ejecuciones en su artículo sobre harness engineering:

“Habitualmente vemos ejecuciones individuales de Codex trabajando en una sola tarea durante más de seis horas (a menudo mientras los humanos están durmiendo).”

El equipo de ingeniería de Anthropic describe el problema de estado correspondiente en Effective harnesses for long-running agents:

“El reto central de los agents de larga duración es que deben trabajar en sesiones discretas, y cada nueva sesión comienza sin memoria de lo ocurrido anteriormente.”

Ambas observaciones apuntan al mismo diseño de runtime: conservar el estado fuera del worker y hacer que los workers sean sustituibles.

La sesión debe vivir fuera del proceso worker. Un almacén durable registra las llamadas al modelo, los resultados de las herramientas y las aprobaciones, de modo que otro worker pueda reanudar desde el último punto seguro tras un crash. Los checkpoints también permiten al runtime iniciar una sesión nueva del modelo cuando se llena la ventana de contexto, sin repetir todo el historial. En palabras de Anthropic, las instancias del harness se vuelven desechables y reiniciables; el estado durable vive en otro lugar.

Cinco primitivas que debes ubicar antes de hacer el despliegue

El artículo de Anthropic Scaling Managed Agents proporciona un vocabulario útil para cinco responsabilidades del runtime. El harness impulsa el agent, mientras que la session registra lo que ha hecho y el sandbox ejecuta los comandos. El checkpoint proporciona al siguiente worker un punto de reanudación; la trace conserva evidencias para depuraciones posteriores. Una implementación puede fusionar componentes, pero las responsabilidades y los límites de fallo deben seguir teniendo nombre.

Session. Un log append-only de todo lo ocurrido: llamadas al modelo, tool calls, resultados, errores y aprobaciones.

El término es ambiguo, así que conviene distinguir tres ámbitos llamados session. Un thread es la conversación de un usuario a lo largo de varios días. Es el de mayor duración de los tres, y LangGraph lo sigue mediante un thread_id.

Una model session es la más breve: un tramo continuo de contexto del modelo. La compactación —el paso que resume la ventana para que el trabajo pueda continuar— prolonga una model session en lugar de finalizarla. Un reinicio o un comienzo nuevo deliberado la termina. La parte 6 utiliza «model session» en este sentido.

En este artículo, «session» significa el log durable de una ejecución. Se encuentra entre las otras dos: muchas model sessions escriben en un único log, y un thread acumula muchos logs. La recuperación es wake(sessionId) → getSession(id) → resume from last event.

En LangGraph, la recuperación utiliza un thread_id junto con un checkpointer de Postgres (consulta LangGraph persistence). El OpenAI Agents SDK incluye diez backends de session integrados, entre ellos SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession y EncryptedSession (consulta la documentación de Sessions).

Harness. El loop de orquestación y la única primitiva de esta lista que toma decisiones. Ensambla el prompt a partir de la memoria, llama al modelo, comprueba el tool call propuesto frente a sus reglas de permisos, ejecuta lo que permite, escribe los resultados en la session, aplica las reglas de retry y decide si la tarea ha terminado. Cada uno de esos pasos codifica una suposición sobre lo que el modelo no puede hacer por sí solo. Anthropic lo señala directamente —la cita aparece en la sección de modos de fallo que sigue, centrada sobre todo en lo que ocurre cuando esas suposiciones quedan obsoletas.

El equipo de Codex de OpenAI llama a esto harness engineering: escribir software sigue requiriendo esfuerzo de ingeniería, pero ahora una parte mayor se dedica al scaffolding que al código en sí. El CompiledStateGraph de LangGraph, Deep Agents de LangChain y su punto de entrada create_deep_agent, y Claude Code son todos harnesses en este sentido.

Sandbox. El entorno de ejecución aislado donde se ejecutan realmente los comandos. La página de OpenAI Agents SDK sobre conceptos de sandbox establece claramente la separación:

“El runtime externo sigue siendo responsable de las aprobaciones, las trazas, los handoffs y el registro de las reanudaciones. La sesión del sandbox se ocupa de los comandos, los cambios en archivos y el aislamiento del entorno.”

«Runtime externo» significa aquí el harness junto con sus almacenes de estado. En el vocabulario de esta serie, las aprobaciones y los handoffs son decisiones del harness (parte 4 y parte 6); las trazas y el registro de las reanudaciones corresponden a las primitivas session y checkpoint.

Los sandboxes difieren en cuánto tiempo viven y qué recuerdan entre ejecuciones. La forma más sencilla es fresh ephemeral: crear uno para una única tarea, destruirlo cuando termine y asumir el coste de cold start en cada ejecución.

Los sandboxes persistent paused conservan el sistema de archivos y una instantánea de memoria entre ejecuciones. La siguiente reanudación puede evitar un arranque completo. Snapshot or fork crea una rama copy-on-write desde una imagen padre preparada, de modo que muchas tareas compartan dependencias instaladas y cachés calientes sin compartir su estado modificable.

Los sandboxes per-worktree proporcionan a cada tarea su propio workspace y stack de observabilidad. Los logs, métricas y trazas separados permiten depurar una ejecución sin que su estado se filtre a otra. La tabla de proveedores posterior compara el comportamiento de cold start y persistencia.

Checkpoint. Estado reanudable.

El PostgresSaver de LangGraph escribe un Checkpoint en cada límite de super-step. Un super-step es una ronda del grafo: un único nodo o un lote ejecutado en paralelo. Las escrituras por tarea van a checkpoint_writes, por lo que los resultados correctos de un nodo no se vuelven a calcular cuando falla un nodo hermano.

Un checkpoint es un dict normal (v, id, ts, channel_values, channel_versions, versions_seen, updated_channels). LangGraph lo serializa con su JsonPlusSerializer basado en msgpack, no con JSON. datetime, set, Decimal y los dataclasses se pueden convertir ida y vuelta. El formato está documentado en la página de PyPI de langgraph-checkpoint-postgres y en la referencia de checkpoints de LangGraph.

StateSnapshot es la vista independiente y más rica que graph.get_state() construye sobre un checkpoint. Es el objeto cuyo .values vuelca posteriormente el paquete de depuración.

Trace. La superficie de replay y depuración. Cada llamada al modelo, tool call y paso de un sub-agent se convierte en un span con tiempos, entradas, salidas, recuentos de tokens y coste. Cuando falla una ejecución de seis horas, la trace es lo que lees para averiguar qué ha ocurrido. Para entonces, la salida del terminal ya ha desaparecido. Las convenciones semánticas de GenAI de OpenTelemetry estandarizan los nombres de atributos —qué modelo, qué proveedor, cuántos tokens, qué conversación y qué workflow—. En un destino compatible con OTLP que admita estas convenciones, la misma instrumentación puede exportar la trace a sistemas como Tempo, Jaeger, Honeycomb o LangSmith, aunque pueden seguir siendo necesarios adaptadores del backend o configuración específica del destino.

Las políticas y los secretos atraviesan las cinco primitivas

Dos límites atraviesan las cinco primitivas. Son la versión de runtime del argumento de seguridad de la parte 4. La decisión de permisos pertenece al harness; lo que sigue explica dónde se ubica físicamente la maquinaria que la aplica y la alimenta.

Aplicación de permisos

La escala de permisos de la parte 4 necesita un lugar donde ejecutarse. La comprobación se activa antes de cada tool call y decide si puede continuar. En producción son habituales dos patrones. Deep Agents permite que cada sub-agent declare qué rutas de archivo puede leer o escribir, y el middleware bloquea todo lo que quede fuera de esa declaración. Anthropic Managed Agents dirige cada tool call a través de un proxy de Model Context Protocol (MCP), de modo que es el proxy, y no el código del agent, quien aplica los permisos. Cuando una llamada sensible requiere aprobación humana, el interrupt() de LangGraph y el approval hook de Deep Agents pausan el grafo hasta que una persona acepta.

Secret broker

El modelo no debería ver secretos de larga duración, y normalmente el sandbox tampoco. El patrón de Managed Agents es el que conviene copiar:

“Para Git, utilizamos el access token de cada repositorio para clonar el repositorio durante la inicialización del sandbox y conectarlo al remote local de git. Git push y pull funcionan desde dentro del sandbox sin que el agent llegue a manejar el token. Para herramientas personalizadas, admitimos MCP y almacenamos los tokens OAuth en un vault seguro. Claude llama a las herramientas MCP mediante un proxy dedicado; este proxy recibe un token asociado a la sesión. … El harness nunca llega a conocer ninguna credencial.”

En el stack de referencia market-analyst-agent —un agent pequeño de LangGraph que obtiene datos de mercado y escribe un informe de analista, construido a lo largo de esta serie—, el sidecar MCP contiene las API keys del proveedor de datos y expone únicamente la superficie de herramientas al worker de LangGraph. En el archivo local de compose, ambos contenedores leen el mismo .env, un atajo de desarrollo, no el patrón recomendado. En producción, el entorno del sidecar procede de un almacén de secretos —Docker secrets o HashiCorp Vault— que el worker no puede leer. El worker llama entonces a la herramienta sin tener nunca la credencial que hay detrás.

Comprueba la ubicación

Una comprobación práctica consiste en anotar cada componente y qué primitivas de las cinco implementa. Postgres podría cubrir session y checkpoint. El container del worker es el harness. Un servicio como Daytona, Modal o E2B proporciona el sandbox, mientras que Tempo o LangSmith almacenan la trace.

Después, inspecciona los fallos acoplados. Si dos primitivas viven en el mismo proceso, un único crash hace caer ambas. Si comparten una credencial, una filtración atraviesa los dos límites. Ejemplos habituales son un worker que también posee la durabilidad de la trace o un token de sidecar que desbloquea igualmente la base de datos de checkpoints.

Modos de fallo de un runtime de AI agent en producción

El runtime gestiona retries, restaura trabajo anterior, aísla workspaces y aplica presupuestos. A medida que las ejecuciones se extienden entre workers y ventanas de contexto, los fallos se desplazan hacia el estado, los efectos secundarios duplicados, la deriva del sandbox y los excesos de presupuesto.

Los fallos se agrupan en cuatro categorías:

• Fallos de calidad de salida: el agent declara la victoria antes de terminar realmente el trabajo, olvida lo que hizo tras un reset de la ventana de contexto o confía en su propia autoevaluación y publica una salida rota.
• Fallos de control de costes: el agent queda atrapado en un loop de retry o consume el presupuesto de tokens o tool calls sin producir nada útil.
• Fallos de estado y crash: los workspaces derivan porque una ejecución toca archivos propiedad de otra, los tool calls se disparan más de una vez porque los retries los repiten o se pierde trabajo cuando un worker muere entre eventos.
• Fallos de ventana de contexto: el modelo resume y abandona pronto porque cree que se está quedando sin espacio, aunque la ventana todavía tenga margen.

La tabla relaciona cada fallo con una mitigación, la base de la recomendación y el hook del runtime que la aplica. El comportamiento específico del modelo puede cambiar, así que considera las observaciones de los proveedores como motivos para volver a probar la suposición, no como reglas permanentes.

Dos ideas sustentan la mayoría de esas filas. Anthropic, sobre el envejecimiento del harness, en Harness design for long-running application development:

“Cada componente de un harness codifica una suposición sobre lo que el modelo no puede hacer por sí solo, y merece la pena someter esas suposiciones a pruebas de estrés, tanto porque pueden ser incorrectas como porque pueden quedarse obsoletas rápidamente a medida que mejoran los modelos.”

Vercel, sobre el problema relacionado de que demasiadas herramientas codifican demasiadas suposiciones, en We removed 80% of our agent’s tools:

“Eliminamos la mayor parte y redujimos el agent a una sola herramienta: ejecutar comandos bash arbitrarios. Lo llamamos file system agent.”

La cita describe el núcleo bash; el agent que publicó Vercel mantuvo dos herramientas, ExecuteCommand y ExecuteSQL, frente a quince. La parte 3 cubre el antes y el después completo. Su resultado comunicado en cinco consultas representativas: el éxito pasó de 4/5 a 5/5, y el peor caso bajó de 724 s / 100 pasos / 145.463 tokens (fallido) a 141 s / 19 pasos / 67.483 tokens (correcto). Esa fila del peor caso es la más llamativa; como media de las cinco consultas, el ahorro de tokens fue del 37 %. La lección no es «elimina tus herramientas». Es que toda primitiva de tu runtime, incluida la superficie de herramientas, tiene una vida útil limitada. Vuelve a probar la suposición cuando cambie el modelo.

Cognition observó el mismo objetivo cambiante en la duración de sesión con Sonnet 4.5. En Rebuilding Devin for Claude Sonnet 4.5 describen un modelo que escribe de forma proactiva SUMMARY.md / CHANGELOG.md cuando percibe que se agota el contexto, pero subestima cuántos tokens le quedan. Su solución fue habilitar el contexto de 1M tokens y limitar el uso a 200k para que el modelo siguiera creyendo que tenía margen. Cuando escribieron el artículo, era un beta flag.

La documentación actual de la ventana de contexto de Anthropic, a fecha de agosto de 2026, sigue indicando 200k para Sonnet 4.5. La ventana de 1M se incluye de forma predeterminada, sin cabecera beta, en Opus 4.6 y posteriores, y en Sonnet 4.6 y posteriores. La parte que conviene vigilar es el límite. Solo existe porque Sonnet 4.5 calcula mal el contexto restante; el día que un modelo deje de hacerlo, el límite dejará de ser una solución y se convertirá en un techo artificial. Las generaciones de modelos han cambiado más de una vez desde que Cognition publicó ese artículo; vuelve a comprobar las cifras con la lista de modelos actual antes de reutilizar nada de esto.

El equipo del harness de OpenAI lo resume en una línea: «Los humanos dirigen. Los agents ejecutan». Cuando algo falla, la pregunta útil es qué capacidad falta y cómo hacer que esa capacidad sea legible y exigible para el agent.

El ciclo de vida saludable de una ejecución

Una ejecución bien comportada es aburrida. Es una cadena de pequeños pasos recuperables, y cada paso escribe su resultado en almacenamiento durable antes de que comience el siguiente.

Escribir cada resultado antes de iniciar el siguiente paso es lo que limita los daños de un crash. Un fallo solo pierde el paso en curso, y el siguiente worker reanuda desde el último paso completado en lugar de reiniciar toda la petición.

1. Arranca desde una session nueva o reanudada. Al reanudar, monta el workspace desde su último estado conocido, lee los archivos de progreso que dejó el intento anterior (PROGRESS.md, feature-list.json) y carga de la base de datos el último checkpoint. Aquí es donde el harness entrega al agent todo lo que el worker anterior tenía en memoria antes de morir.
2. Planifica antes de ejecutar cualquier tool call. Define qué significa «terminado», cuánto puede gastar la ejecución, qué herramientas puede invocar el agent y qué debería detenerla antes de tiempo. Estos valores del plan se convierten en comprobaciones del runtime; sin ellos, la ejecución no tiene nada que la frene.
3. Ejecuta un tool call cada vez. La comprobación de permisos del harness decide si lo permite, después lo despacha, captura el resultado y escribe un evento en el log de session. Un paso, un evento. Un crash entre eventos se puede recuperar porque el log, no la memoria del worker, es la fuente de verdad.
4. Crea un checkpoint en los límites de super-step o después de cada evento en un harness más sencillo. Persiste el estado del grafo, el diff del workspace y las referencias a los artefactos producidos. Este checkpoint es lo que lee el paso 1 en la siguiente reanudación. Si falta o está obsoleto, la recuperación se degrada a repetir desde cero todo el log de session, lo que es mucho más lento.
5. Evalúa los artefactos cuando el agent considera que ha terminado: tests, un evaluator con contexto nuevo, validación de schema y comprobaciones del navegador. Si la comprobación pasa, la ejecución termina correctamente. Si falla, se reanuda desde el último checkpoint limpio con el mensaje de error añadido al contexto y se vuelve a intentar.

Ningún paso de esa lista requiere que el agent recuerde nada entre ejecuciones. El estado vive en la session y el checkpoint, y el agent lo vuelve a leer en cada reanudación.

Cualquier herramienta con efectos secundarios necesita una idempotency key derivada del ID de la sesión y del ID del tool call, almacenada antes de ejecutar el efecto secundario. send_email(session_id, tool_call_id, message_hash). create_pr(session_id, tool_call_id, branch_name). charge_customer(session_id, tool_call_id, invoice_id). La ejecución at-least-once es el comportamiento predeterminado en queues y workflow engines, así que el duplicado ocurrirá. Si un tool call puede causar daños reales al repetirse y no puedes deduplicarlo mediante una clave, la herramienta no está preparada para agents.

La evaluación debe incluir evidencias externas al contexto que produce la salida. Un evaluator con contexto nuevo reduce el sesgo del contexto compartido, mientras que los tests, lints, comprobaciones del navegador y validaciones de schema aportan evidencias deterministas. La comprobación puede devolver pass, fail o needs_human. Para code agents, el reviewer puede ser otra model session con herramientas de solo lectura. Para agents de datos e informes, combina validación determinista con un reviewer model cuando siga siendo necesario el juicio.

Once patrones de despliegue de AI agents y cómo decidir entre ellos

Una vez nombradas las cinco primitivas, la pregunta es qué forma de despliegue las ejecuta. Por «forma» entiendo una disposición de esas primitivas: dónde vive el harness, dónde persiste el estado y qué tipo de sandbox ejecuta el trabajo. Una forma es una decisión de cableado, no una elección de proveedor. El gráfico siguiente muestra en qué longitudes de ejecución encaja mejor cada forma. El texto posterior explica qué factores deciden entre ellas.

Si solo lees una de las once, lee la forma 2: queue + worker + checkpoint DB. Es la opción predeterminada que recomiendo a la mayoría de los equipos, la forma utilizada por el repositorio de referencia y el esqueleto sobre el que varían la mayoría de las demás: queue → worker → estado durable, cambiando la fuente del sandbox, el propietario del harness o el motor de estado. Leer primero la forma 2 hace que el resto se pueda revisar más rápido.

El gráfico compara las formas por duración de ejecución. La matriz siguiente las compara por propiedad: cada celda delimitada nombra el componente que proporciona esa primitiva.

1. SDK dentro de un app server (síncrono, limitado a la petición)

La forma original. El SDK del agent se ejecuta dentro de un request handler. Es adecuada para tareas de menos de 30 segundos, demos y herramientas internas. Es mala para cualquier cosa de la que un cliente HTTP pueda desconectarse. El timeout HTTP de Cloud Run llega como máximo a 60 minutos, y cualquier panic de la capa web mata la ejecución. El SDK es el harness, el proceso web también actúa como sandbox y el estado suele vivir en la memoria del proceso salvo que lo envíes explícitamente a otro sitio. No la uses para trabajos de varias horas.

2. Queue + worker + checkpoint DB

Es la opción predeterminada que recomiendo a la mayoría de los equipos y la forma de producción utilizada en market-analyst-agent: un worker de Python con un checkpointer de PostgreSQL, Redis Streams —o RabbitMQ— para la cola de entrada y un sidecar MCP para las herramientas. Es adecuada para ejecuciones de 10 minutos a varias horas con pasos idempotentes. El runner local puede saltarse la cola para desarrollo síncrono, pero la cola forma parte de la arquitectura de producción cuando necesitas envío asíncrono y backpressure.

La app acepta una petición, crea una fila de session, introduce un job en la cola y devuelve un ID de ejecución. El worker extrae el job, ejecuta el harness, escribe checkpoints, transmite el estado y almacena artefactos sobre la marcha. Postgres sobrevive, los workers son reemplazables y la profundidad de la cola proporciona backpressure. El cómputo Spot/Preemptible funciona siempre que el checkpointer termine de escribir en disco antes de informar de éxito.

En esta forma, el worker es el harness. Su container y el workspace por thread proporcionan un límite de ejecución, pero el código no confiable sigue necesitando un sandbox reforzado o una VM. Postgres es responsable del estado de session y checkpoint. Las trazas pasan por OpenTelemetry a la plataforma de observabilidad que utilices.

3. Motor de workflow durable (estilo Temporal)

El código de orquestación del agent se ejecuta dentro de un Temporal Workflow; las llamadas al modelo y a las herramientas se ejecutan como Activities. El estado del Workflow vive en un log de historial de eventos respaldado por Cassandra, MySQL o Postgres, por lo que se reproduce correctamente entre despliegues. La integración de Temporal × OpenAI Agents SDK, disponible con carácter general desde marzo de 2026, incluye un OpenAIAgentsPlugin y un helper activity_as_tool, y el artículo sobre agentic sandboxes describe cómo hacer fork de un agent en ejecución hacia otro proveedor de sandbox en mitad de una conversación. Los workflows inactivos no consumen cómputo. Las salvedades son importantes: los agents en tiempo real no son compatibles y el streaming sigue marcado como experimental; además, LocalShellTool y ComputerTool están deshabilitados porque no encajan en un modelo distribuido.

Usa esta forma cuando la ejecución tenga puntos reales de espera: aprobaciones humanas, callbacks externos, esperas largas, retries con reglas de negocio o ventanas de despliegue. Una aprobación humana se convierte en una espera durable que no consume cómputo, no en un loop de polling.

El código del Workflow es el harness. El sandbox suele vivir fuera de Temporal y se invoca desde Activities. El estado de session y checkpoint se fusiona en el log de historial de eventos de Temporal, mientras que la visibilidad de la trace procede de la UI de Temporal y de los spans de OpenTelemetry de cada Activity.

4. Un sandbox por session

Una forma más reciente. Cada ejecución del agent obtiene su propia microVM o container de un proveedor de sandbox-as-a-service. El harness vive en algún lugar durable; el sandbox es el entorno de ejecución desechable.

Los cold starts de aquí son de aprovisionamiento end-to-end, no de arranque puro: los ~150 ms de E2B se suman a los ~125 ms de arranque de Firecracker que la parte 4 cita para el propio hypervisor. La tabla combina la comparativa E2B vs Daytona, la documentación de sandboxes de Daytona y su changelog de fork/snapshot, las guías de Modal sobre sandboxes y cold starts, el listado de Runloop en AWS Marketplace y los precios de Vercel Sandbox.

Daytona registra un vínculo padre-hijo para cada fork independiente, lo que conserva la genealogía de los sandboxes derivados. El harness de Codex de OpenAI utiliza la variante per-worktree: «Codex trabaja sobre una versión completamente aislada de esa app, incluidos sus logs y métricas, que se eliminan cuando termina la tarea».

Elige esta forma cuando el agent ejecute código no confiable, automatización de navegador, tests o instalaciones de paquetes. La contrapartida es un coste y una dependencia del proveedor mayores que al ejecutar workers compartidos.

El proveedor es responsable del sandbox y de nada más. El harness, la session, el checkpoint y la trace siguen de tu lado, normalmente conectados con la forma queue + worker del punto 2.

5. Anthropic Managed Agents (harness gestionado)

Anthropic lanzó Managed Agents en public beta el 8 de abril de 2026, tras la cabecera beta managed-agents-2026-04-01. El servicio proporciona una session, un harness, un sandbox y un proxy MCP respaldado por un vault gestionados. wake(sessionId) puede inicializar el harness en un worker nuevo sin perder el estado durable de la session.

Anthropic factura Managed Agents según las tarifas estándar de tokens más $0.08 por hora de sesión. La facturación tiene granularidad de milisegundos y solo se aplica mientras el estado de la session es «running»; el tiempo inactivo es gratuito. Por tanto, un loop de retry descontrolado añade un coste por horas de sesión al coste de tokens.

Lee las salvedades. El descuento de Batch API no se aplica («Las sessions tienen estado y son interactivas. No existe modo batch»). Managed Agents no está disponible a través de AWS Bedrock ni de Google Vertex AI. Dentro de la beta, los túneles MCP y el «dreaming» del agent están detrás de un research preview adicional cuyo acceso hay que solicitar; la coordinación multi-agent y la autoevaluación calificada mediante rúbricas forman parte documentada de la beta. El lock-in es alto: renuncias a controlar el harness a cambio de no ejecutar tú mismo el loop.

Anthropic aloja las cinco primitivas: session, harness, sandbox, checkpoint y trace. Tú entregas el runtime y recibes las salidas.

6. LangChain Deep Agents Deploy (harness abierto gestionado)

deepagents deploy empaqueta un deepagents.toml en un LangSmith Deployment con ejecución durable, memoria, multi-tenancy, human-in-the-loop, observabilidad, ejecución de código en sandbox y ejecuciones programadas. Admite modos de despliegue cloud, híbrido y self-hosted. Los proveedores de sandbox (LangSmith Sandboxes, Daytona, Modal, Runloop o uno propio) se pueden cambiar mediante un único valor de configuración. El estado vive en un sistema de archivos virtual con backends intercambiables; la memoria puede estar limitada al usuario, al assistant o a ambos. El lock-in es menor que en Managed Agents: el harness está bajo licencia MIT, las instrucciones utilizan el estándar abierto AGENTS.md y los agents se exponen mediante MCP, el protocolo A2A (Agent2Agent) y Agent Protocol. Consulta el artículo de LangChain runtime-behind-production-deep-agents.

Por defecto, las cinco primitivas están gestionadas, pero cada una puede cambiarse mediante configuración. El sandbox se sitúa detrás de un único valor de configuración. La session y el checkpoint viven en un sistema de archivos virtual con backends intercambiables. La trace va a LangSmith.

7. Servicio o job de Google Cloud Run

Cloud Run tiene dos modos de runtime distintos, y cuál encaja depende de cómo se invoque el agent. Los services están ligados a HTTP y escalan a cero entre peticiones; el harness se ejecuta como un request handler que devuelve la respuesta cuando termina la ejecución. Los jobs se ejecutan hasta completarse sin un entrypoint HTTP; el harness funciona como un worker de una sola ejecución que sale cuando termina la tarea. Ambos pueden alojar el harness, pero ninguno conserva el estado entre ejecuciones. Las sessions y los checkpoints deben vivir en Postgres, Spanner o un almacén externo similar.

Los límites estrictos son muy distintos. Timeout de peticiones de los servicios de Cloud Run: 300 s por defecto, máximo 3.600 s (60 min). Los WebSockets tienen el mismo timeout. Jobs de Cloud Run: 10 min por tarea por defecto, máximo 168 h (7 días); para tareas que usan GPUs, máximo 1 hora. Los services escalan a cero salvo que actives CPU always-on; los jobs no tienen HTTP ni autoscaling.

Usa un service para ejecuciones síncronas de hasta 60 minutos. Usa un job para trabajo one-shot o asíncrono más largo. Cloud Run Jobs puede mantener una tarea activa durante días, pero no proporciona replay durable entre despliegues, cambios de versión o sustituciones de workers. Por encima de 7 días, no uses Cloud Run.

Cloud Run aloja el harness. El estado de session y checkpoint vive en Postgres, Spanner u otro almacén externo, y las trazas pueden pasar por Cloud Logging y OpenTelemetry. El container del servicio es un entorno de ejecución; añade un sandbox independiente cuando el agent ejecute código no confiable.

8. AWS Lambda (por qué es la herramienta equivocada)

El timeout máximo de una función Lambda es de 900 s (15 minutos) y es estricto. Si API Gateway está delante de la función, el límite de integración depende del tipo de API. Las HTTP APIs permiten 30 segundos; las integraciones REST tienen 29 segundos por defecto, mientras que las REST APIs regionales y privadas pueden configurar un timeout mayor. Ninguno de esos caminos convierte Lambda en un worker de varias horas. Un harness de larga duración sigue necesitando estado externo y nuevas invocaciones, lo que reproduce la forma queue + worker. Usa Lambda para tool calls acotados, como descargar archivos o subirlos a S3, invocados por un orquestador de mayor duración. No pongas ahí el orquestador.

Como mucho, Lambda aloja un tool call dentro de su límite de 15 minutos. El harness, la session, el checkpoint, el sandbox y la trace deben vivir en otro sitio.

9. Una tarea de AWS ECS / Fargate por ejecución

Fargate no documenta un límite estricto de duración de una tarea, a diferencia de Lambda. Las cuotas de throttling de Fargate permiten una ráfaga de lanzamiento de 100 y se recuperan a razón de 20 por segundo, con presupuestos independientes para on-demand y spot. Las cuotas de servicio de ECS limitan a 1.000 tareas por servicio los servicios que utilizan AWS Cloud Map discovery y a 5.000 container instances los clusters respaldados por EC2.

Fargate requiere el modo awsvpc, por lo que cada tarea obtiene una interfaz de red y una IP privada. Esta forma encaja con el acceso a datos interno de una VPC. Fargate Spot añade riesgo de interrupción, y la durabilidad sigue siendo responsabilidad tuya porque la plataforma no proporciona replay al estilo de Temporal.

Fargate aloja el harness y proporciona a cada ejecución su propia tarea. Esto separa los workspaces y las credenciales de las tareas, pero por sí solo no constituye un sandbox completo para código hostil. Session, checkpoint y trace van a servicios externos como RDS o DynamoDB, además de CloudWatch/X-Ray.

10. Kubernetes Job o namespace por session

Es una buena opción si ya operas Kubernetes y quieres un sandbox por session con controles para todo el cluster. Es mala si necesitas un arranque inferior a un segundo, porque descargar la imagen del container e inicializar el pod tarda demasiado en un cold start. El patrón consiste en un Job por ejecución del agent, con activeDeadlineSeconds, un PersistentVolumeClaim para el workspace y un sidecar para el servidor MCP. La recuperación tras crash tienes que construirla tú. Adoptar Kubernetes solo para alojar agents es caro en configuración y carga operativa. Solo merece la pena si ya ejecutas K8s por otros motivos.

Kubernetes aloja el harness y el entorno de ejecución por ejecución, normalmente como un único Job y, a veces, con un namespace dedicado. El aislamiento fuerte sigue dependiendo de la runtime class, la network policy, la seguridad de los pods y el límite subyacente de container o VM. Session y checkpoint viven en una base de datos externa o en un PersistentVolumeClaim.

11. Docker Compose local (solo desarrollo)

Es la referencia para la sección siguiente. El objetivo de esta forma es reflejar uno a uno el topology de producción —las mismas primitivas y la misma forma de red— mientras se ejecuta en una única máquina. Lo que no refleja es el aislamiento: un único montaje de workspace compartido, un Postgres, ningún sandbox reforzado y ningún dominio de fallo separado entre el worker y su estado. No despliegues nada con esta forma.

Compose reproduce la forma n.º 2 en un único host. Postgres contiene el estado de session y checkpoint, y el container del worker es el harness. El montaje de workspace compartido es cómodo para desarrollo, pero no aísla las ejecuciones no confiables. El stack opcional de OpenTelemetry registra las trazas.

Stack de referencia: Docker Compose

El topology de referencia, utilizado en slavadubrov/market-analyst-agent, consta de un worker de LangGraph, un checkpointer de Postgres, Qdrant para retrieval, un sidecar MCP, una queue de Redis para ejecuciones asíncronas similares a producción y un stack opcional de observabilidad con Prometheus / Grafana / Loki / Tempo / OTel. En el compose local, Redis es opcional solo porque el runner síncrono puede llamar directamente al worker. docker compose up levanta localmente el topology principal; el sidecar MCP y el stack de observabilidad son profiles opcionales (--profile mcp, --profile observability).

La única pieza que merece la pena mostrar inline es el wiring canónico de LangGraph. Es un extracto ilustrativo, no un ejemplo ejecutable directamente desde el repositorio. Para ejecutarlo se necesitan langgraph, langgraph-checkpoint-postgres y psycopg[binary,pool], una base de datos PostgreSQL accesible con permisos para crear las tablas del checkpointer, POSTGRES_PASSWORD y un StateGraph creado previamente en builder; consulta la configuración del checkpointer de Postgres de LangGraph.

import os
from urllib.parse import quote

from langgraph.checkpoint.postgres import PostgresSaver

password = quote(os.environ["POSTGRES_PASSWORD"], safe="")
DB_URI = f"postgresql://agent:{password}@postgres:5432/agent"
# `builder` is your StateGraph, already built
session_id = "session-123"
with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates tables on first run
    graph = builder.compile(checkpointer=checkpointer)
    result = graph.invoke(
        {"messages": [{"role": "user", "content": "Continue the task"}]},
        {"configurable": {"thread_id": session_id}},
    )

Observabilidad que sobrevive a la ejecución

Los request handlers cortos son fáciles de depurar: cuando algo falla, lees la respuesta y el log en vivo. Los agents de larga duración no tienen ese lujo. Cuando una ejecución de seis horas falla, el evento relevante ocurrió hace cinco horas, la salida del terminal en vivo ha desaparecido y el worker que lo produjo ha sido sustituido. Nadie va a reconstruir la ejecución de memoria. Por tanto, depuras a partir de artefactos durables escritos mientras la ejecución seguía viva.

Los stacks de producción suelen cubrir cuatro tipos de artefactos, en dos grupos. Dos se leen después de terminar la ejecución, para postmortems y replay: un event log consultable de cada paso y trazas de OpenTelemetry que muestran dónde se fueron el tiempo y los tokens. Los otros dos se leen durante la ejecución. Uno es un tail en vivo de lo que el agent está produciendo en el workspace. El otro es un stack de observabilidad por worktree que el propio agent puede consultar mientras sigue trabajando.

Event log estructurado (se lee después de la ejecución)

Cada llamada al modelo, tool call, resultado, error y aprobación se escribe en almacenamiento durable, identificado por el ID de la session y la marca de tiempo. Cuando termina la ejecución, se consulta como cualquier tabla normal de base de datos. Addy Osmani fija el criterio claramente en Long-running Agents: «Si no puedes reconstruir lo que hizo el agent en las últimas 24 horas a partir de almacenamiento durable, lo que tienes es un script de shell de larga duración que resulta llamar a un LLM, no un agent de larga duración».

Trazas GenAI de OpenTelemetry (se leen después de la ejecución)

El mismo tipo de datos paso a paso se emite como spans utilizando los atributos estándar de las convenciones semánticas de gen_ai.*: nombre del modelo, proveedor, recuentos de tokens de entrada y salida, ID de conversación y nombre del workflow. Estas convenciones continúan en estado de estabilidad Development.

En 2026 salieron del repositorio principal de convenciones semánticas de OpenTelemetry y pasaron a su propio repositorio de convenciones semánticas de GenAI. Los nombres de atributos se pueden utilizar para instrumentar, pero fija la revisión que hayas validado en lugar de un número de versión del repositorio principal. Los campos específicos del proveedor viven en subnamespaces (anthropic.*, openai.*) identificados mediante gen_ai.provider.name. El motivo para utilizar el estándar es la portabilidad: en destinos compatibles con OTLP que admitan estas convenciones, cambiar de backend puede no requerir volver a instrumentar el código, aunque pueden seguir siendo necesarios adaptadores del backend o configuración específica del destino.

Timeline de tool calls más diffs del workspace (se lee durante la ejecución)

La forma más rápida de saber qué está haciendo ahora mismo un agent es seguir lo que produce en el workspace, no buscar con grep en un log de session. El quick-start Harness Primitives for Long-Running Claude Agents de Anthropic incluye un loop de observación de dos paneles: watch -n 5 'git log --oneline -8' muestra los últimos commits que ha realizado el agent y watch -n 5 'find screenshots -name "*.png" | tail -5' muestra las últimas capturas que ha tomado. Dos paneles de terminal que se actualizan cada cinco segundos bastan para saber si una ejecución progresa realmente o está girando en círculo.

Stack efímero por worktree (lo lee el propio agent durante la ejecución)

Según el artículo de OpenAI sobre harnesses: «Los logs, métricas y trazas se exponen a Codex mediante un stack de observabilidad local y efímero para cada worktree». Cada worktree del agent obtiene su propio Loki + Prometheus + Tempo de corta duración, limitado exclusivamente a esa ejecución. El agent lo consulta mientras trabaja. Esto permite que un prompt como «ningún span de estos cuatro recorridos de usuario supera los dos segundos» se convierta en algo que el agent puede verificar directamente, en lugar de tener que adivinarlo.

(El evaluator con contexto nuevo de la tabla de modos de fallo lee estos artefactos para decidir «done». Pertenece a la evaluación, no a la observabilidad; consulta § ciclo de vida saludable de una ejecución. Depende de todas las superficies anteriores.)

Un stack mínimo de observabilidad self-hosted

Para algo como market-analyst-agent:

1. OpenTelemetry Collector con el GenAI Normalizer Processor (contrib, alpha) para los atributos GenAI compatibles. Usa los processors genéricos Attributes o Transform para filtrar o reescribir campos gen_ai.*.
2. Tempo —o Jaeger— para las trazas, identificadas mediante gen_ai.conversation.id / thread_id.
3. Loki para las entradas del event log estructurado.
4. Prometheus para gen_ai.client.token.usage, gen_ai.client.operation.duration y gen_ai.client.operation.time_to_first_chunk. Las métricas gen_ai.server.* proceden del servidor del modelo, así que solo las obtendrás si alojas los pesos (consulta las convenciones de métricas GenAI).
5. Grafana, con dashboards identificados mediante gen_ai.agent.name y gen_ai.request.model.

Alternativas hosted (elige una, no tres):

• LangSmith: integración nativa con LangGraph; también es el destino de despliegue de Deep Agents Deploy.
• Braintrust: el mejor encaje si la prioridad son las suites de regresión eval-first.
• Arize Phoenix: OSS, nativo de OTLP —el protocolo de red de OpenTelemetry— y compatible con la instrumentación de OpenInference.
• Dashboard de tracing de OpenAI: automático cuando utilizas el OpenAI Agents SDK o su integración con Temporal.
• Claude tracing de Anthropic: para sessions que se ejecutan dentro de Managed Agents.

Instrumenta el nodo de LangGraph

Este es un extracto ilustrativo y el example runner del repositorio lo omite. Supone que el nodo de LangGraph ya tiene un span activo de OpenTelemetry, el thread_id actual y un objeto de respuesta del proveedor usage con input_tokens y output_tokens; la configuración del tracer, la exportación y el mapeo de uso específico del proveedor quedan fuera del fragmento.

# In the LangGraph node, around the model call:
span.set_attribute("gen_ai.operation.name", "chat")
span.set_attribute("gen_ai.provider.name", "anthropic")
span.set_attribute("gen_ai.request.model", "<your-model-id>")
span.set_attribute("gen_ai.response.model", "<your-model-id>")
span.set_attribute("gen_ai.conversation.id", thread_id)
span.set_attribute("gen_ai.agent.name", "market-analyst")
span.set_attribute("gen_ai.workflow.name", "research_then_write")
span.set_attribute("gen_ai.usage.input_tokens", usage.input_tokens)
span.set_attribute("gen_ai.usage.output_tokens", usage.output_tokens)

Los nombres de atributos se han tomado literalmente del registro de convenciones semánticas GenAI de OpenTelemetry.

Tres consultas que conviene tener en un dashboard

# Loki: token usage per agent over 1h
sum by (gen_ai_agent_name) (
    rate({service_name="market-analyst-agent"} | json | unwrap gen_ai_usage_output_tokens [1h])
)

# PromQL: p95 model latency per model
histogram_quantile(0.95,
    sum by (le, gen_ai_request_model) (
        rate(gen_ai_client_operation_duration_bucket[5m])
    )
)

# TraceQL: long-running tool calls
{ span.gen_ai.operation.name = "execute_tool" && duration > 30s }

El patrón del debug bundle

Cuando falla una ejecución, el worker debería dejar un /workspaces/${THREAD_ID}/_debug/ que contenga los artefactos que pedirías en un postmortem:

• session.jsonl: volcado completo del event log de PostgresSaver (checkpointer.list({"configurable": {"thread_id": ...}})).
• last_state.json: StateSnapshot.values del último super-step correcto.
• trace.json: spans exportados mediante OTLP para la ejecución.
• tool_calls.csv: (ts, tool, input_hash, latency_ms, status, error).
• workspace.tar.zst: el directorio del workspace más git diff frente al commit del initializer.
• screenshots/*.png: lo que vio el agent.
• PROGRESS.md, feature-list.json y cualquier otro archivo de progreso creado por el agent.
• env.txt: tags de imágenes, versión del modelo y SHA del commit del harness.

Este paquete proporciona a una persona o a un agent reviewer evidencias suficientes para reconstruir el fallo. «El agent se atascó» es impreciso. Un informe ilustrativo es concreto: la session s_123 gastó el 71 % de sus tokens repitiendo tres comandos después de que fallara npm install.

Cómo elegir la forma adecuada: guía de decisión

La mayor parte de la comparación anterior se reduce a unas pocas decisiones.

Empieza por la duración de la ejecución

Utiliza la duración de la ejecución como primer filtro:

• Menos de 30 segundos, idempotente: SDK ligado al ciclo de vida de la petición dentro de un app server.
• De 30 s a 60 min: queue + worker + checkpoint DB.
• De 60 min a 24 h: la misma queue + worker, o un Cloud Run Job para trabajo one-shot. Usa un motor de workflow durable si también necesitas versionado y replay.
• Más de 24 h y debe sobrevivir a despliegues: motor de workflow durable (estilo Temporal). Cloud Run Jobs puede mantener trabajos largos hasta su límite de tarea, pero no ofrece semántica de replay.
• Loops de entrenamiento de reinforcement learning de varios días: K8s Job + volumen + Temporal.

Después de este filtro general, comprueba los efectos secundarios, la recuperación, el replay, el aislamiento, la ubicación de los datos y el equipo que operará el sistema.

Encaje de la plataforma por caso de uso

La matriz es densa y ninguna celda verde decide por sí sola la arquitectura; normalmente son las celdas amarillas, en las que una plataforma admite algo con salvedades, las que toman la decisión. Una cobertura amplia de workloads es útil, pero no muestra la residencia de datos, la semántica de replay, la dependencia del proveedor, la madurez operativa ni el coste de mover el estado más adelante.

Deep Agents Deploy es la única columna de la matriz sin celdas rojas o amarillas: ejecuciones síncronas cortas, batch de varias horas, forking de sandboxes, trabajo con GPUs y el menor lock-in aparecen en verde. Esto lo convierte en candidato cuando una plataforma debe servir para todos tus workloads. Esa amplitud viene acompañada de un historial de producción más corto que el de un stack de queue + worker + Postgres. Trata las celdas verdes como afirmaciones de capacidades que debes validar y compara después las restricciones operativas que la matriz no puede expresar.

Anthropic Managed Agents encaja completamente con tu workload o no encaja en absoluto. El producto tiene dos restricciones estrictas: es hosted-only y Claude-only. Si tu workload cumple ambas —Claude ya es el modelo que quieres y prefieres no operar tú mismo un harness—, Managed Agents encaja muy bien. Un coding agent interno que se ejecute en ráfagas de dos a seis horas es el formato que mejor encaja y elimina una gran parte del trabajo de plataforma de tu equipo. Si alguna restricción falla porque necesitas un modelo que no sea Claude o cumplimiento self-hosted, Managed Agents no encaja. Ningún cambio de configuración puede solucionar eso.

Conviene modelar el precio antes de comprometerse, no después. La línea de coste por hora de session es $0.08/hour on top of standard token costs. If a single session ran continuously, that is about$58 al mes por session. Con 100 sessions ejecutándose continuamente, son aproximadamente $5,800/month _before tokens_. Multiply$0.08; multiplica por tus horas de sessions concurrentes esperadas, súmalo a la factura de tokens y compáralo con el coste de un stack queue + worker en tu propia infraestructura. Migrar desde Managed Agents más adelante es un ejercicio de replatforming, no un cambio de configuración.

Harness hosted frente a harness propio

La distinción se refiere a quién opera el harness, no a quién escribió su código. Hosted significa que el proveedor ejecuta el loop del harness en su infraestructura y tú llamas a una API. Owned significa que ejecutas el loop en tu propia infraestructura, aunque el código del harness proceda de un proveedor.

LangChain aparece a ambos lados de esta línea, lo que suele confundir. Ofrece LangGraph, una librería con licencia MIT que puedes alojar tú mismo (owned), y Deep Agents Deploy, un producto gestionado que ejecuta un harness de Deep Agents sobre LangSmith Deployment en su modo cloud predeterminado (hosted). La misma empresa, dos modelos operativos distintos. Lo que eliges es quién ejecuta el loop, no qué logotipo aparece en la librería. Deep Agents Deploy también dispone de un modo self-hosted para equipos que quieren la ergonomía del harness sin el componente cloud; ese modo pertenece a la categoría owned.

Elige un harness hosted cuando su soporte de modelos, límite de datos, comportamiento de recuperación y puntos de extensión ya encajen. Elige un harness propio cuando esas restricciones sean requisitos que esperas que cambien. Migrar entre ambos cambia el estado, la observabilidad y los límites de ejecución, así que prueba la ruta de salida antes de que los datos de producción dependan de ella.

Sandbox hosted frente a un entorno de ejecución propio

Elige un sandbox hosted cuando el aislamiento, la semántica de pause/resume o la semántica de fork del proveedor encajen con el modelo de amenazas y el presupuesto de arranque. Docker o Fargate pueden servir para workloads internos de confianza que necesiten acceso a una VPC o una residencia de datos estricta, pero un container estándar no es un límite suficiente para código hostil. La parte 4 repasa el menú de aislamiento para ese caso.

Almacenes de estado: Git, DB y object storage, lado a lado

Los agents de larga duración suelen utilizar tres almacenes de estado a la vez porque cada uno es responsable de un artefacto distinto.

Git almacena el estado del workspace: el código, los documentos y los archivos de progreso que modifica el agent. Cada commit proporciona al harness un punto de recuperación estable y a la siguiente sesión un historial compacto.

La base de datos de checkpoints almacena el estado del grafo: qué se decidió, qué nodos se ejecutaron, qué resultados devolvieron y qué debe ejecutarse a continuación. El artifact store contiene salidas finales grandes como PDFs, archivos Parquet y capturas de pantalla. Esos artefactos no pertenecen a Git ni a la base de datos de checkpoints.

Cuándo utilizar git como estado

Usa git cuando el workload tenga forma de código —ediciones en varios archivos, refactors o generación de apps— o tenga suficiente forma de documento como para que importe el historial de archivos. El patrón es sencillo: crea una rama de ejecución, realiza un commit de initializer y después haz commit en límites relevantes: tras la configuración inicial, después de cada funcionalidad, cuando pasen los tests y tras la limpieza final. Guarda el SHA del commit más reciente del workspace junto a la fila del checkpoint. Al reanudar, el siguiente worker comprueba la rama, lee git log --oneline -8, inspecciona git status y el último diff, y después lee PROGRESS.md o el archivo de handoff que haya escrito la session anterior.

Así, git es una superficie de recuperación para el artefacto que se está editando, no un sustituto de la checkpoint DB. Git puede responder a dos preguntas: qué ha cambiado y qué versión ha pasado los tests. No puede indicar al harness qué nodo del grafo debe ejecutarse a continuación, qué tool call está esperando aprobación ni qué retry ya ha utilizado su idempotency key. El harness de Anthropic utiliza commits de initializer y commits por funcionalidad como fuente de verdad para recuperar el workspace; el modelo lee git log --oneline -8 para recuperar el estado. Omite git cuando el producto de trabajo es una única respuesta conversacional. El coste adicional no compensa.

Cuándo utilizar checkpointing en una DB

Usa checkpointing de estilo PostgresSaver cuando el agent tenga una estructura de grafo con varios nodos cuyo estado intermedio importe (planner → researcher → writer → verifier). El repositorio de referencia lo utiliza exactamente por ese motivo. No metas artefactos del workspace de escala terabyte en el checkpoint; esos deben ir a object storage.

Cuándo utilizar un artifact store (S3 / GCS)

Usa object storage cuando:

• la salida sea mayor de lo que debería transportar la base de datos de checkpoints;
• los consumidores posteriores necesiten un artefacto direccionable mediante URL sin pasar por el agent; o
• el entregable y el estado de la ejecución tengan ventanas de retención distintas.

Por ejemplo, puedes eliminar el log de session después de 30 días, pero conservar el informe final durante años. Organiza el layout por (thread_id, checkpoint_id, artifact_name) para que la ejecución productora siga siendo reconstruible.

Cuándo añadir gates de aprobación humana

Añade gates cuando el tool call sea destructivo e irreversible —escrituras en bases de datos, movimientos de dinero o envío de comunicaciones externas—, cuando salga del radio de impacto del agent —despliegues en producción o publicaciones dirigidas a clientes— o cuando los reguladores exijan revisión. El interrupt() de LangGraph y el approval middleware de Deep Agents admiten estos gates de forma nativa. La parte 4 explicó por qué estos gates son una cuestión de permisos, no de prompts.

Checklist práctico de producción

Antes de desplegar un agent de larga duración, responde a estas preguntas en términos concretos de infraestructura.

1. ¿Qué almacén es responsable de los eventos de session y de los checkpoints?
2. ¿Qué ocurre si el worker muere a mitad de un tool call?
3. ¿Puede una ejecución corromper el workspace de otra?
4. ¿Qué acciones requieren aprobación?
5. ¿Puede el modelo o el sandbox leer credenciales sin procesar?
6. ¿Qué tool calls se pueden repetir de forma segura?
7. ¿Dónde se aplica el límite de coste por ejecución?
8. ¿Qué evaluator con contexto nuevo decide «done»?
9. ¿Dónde viven las salidas finales después de que desaparezca el sandbox?
10. ¿Podemos explicar mañana una ejecución fallida sin volver a ejecutarla?

Si la respuesta a alguna de estas preguntas es «el prompt dice al agent que tenga cuidado», el sistema todavía no está desplegado. Sigue siendo una demo.

La siguiente capa es el loop del harness

Este runtime puede mantener una ejecución viva y recuperable, pero la durabilidad no demuestra que el trabajo sea correcto. La parte 6, Harness Engineering para AI Agents, abre la primitiva harness de la tabla anterior: cómo una trace te indica cuál de varios fallos tienes realmente, dónde viven las reglas de retry y parada, qué debe conservar un handoff y cómo una comprobación de aceptación externa decide que una ejecución ha terminado. Es también el último artículo de la serie.

Referencias

Artículos de ingeniería

• OpenAI, Harness engineering: leveraging Codex in an agent-first world.
• Anthropic Engineering, Effective harnesses for long-running agents.
• Anthropic Engineering, Harness design for long-running application development.
• Anthropic Engineering, Scaling Managed Agents: Decoupling the brain from the hands, 8 de abril de 2026.
• Cognition AI, Rebuilding Devin for Claude Sonnet 4.5: Lessons and Challenges.
• Vercel, We removed 80% of our agent’s tools.
• Addy Osmani, Long-running Agents.

LangGraph y Deep Agents

• Documentación de LangGraph, Persistence.
• Referencia de LangGraph, Checkpoints.
• langgraph-checkpoint-postgres en PyPI.
• Documentación de LangChain, Deep Agents overview.
• Blog de LangChain, The runtime behind production Deep Agents.

OpenAI Agents SDK

• OpenAI Agents SDK, Sessions.
• OpenAI Agents SDK, Sandbox concepts.

Temporal

• Blog de Temporal, Introducing Temporal and agentic sandboxes: the OpenAI Agents SDK.
• Blog de Temporal, Production-ready agents with the OpenAI Agents SDK + Temporal.
• README de Temporal × OpenAI Agents SDK contrib (temporalio/sdk-python).

Plataforma de Anthropic

• Anthropic, Claude platform pricing: tarifas por hora de session de Managed Agents.
• anthropics/cwc-long-running-agents: take-home Code with Claude 2026 con evaluator subagent y patrones de archivos de progreso.

Proveedores de sandbox

• ZenML, E2B vs Daytona: sandbox comparison for platform engineers.
• Documentación de Daytona, Sandboxes.
• Changelog de Daytona, Sandbox fork and snapshot endpoints.
• Documentación de Modal, Sandboxes.
• Documentación de Modal, Cold start guide.
• Runloop en AWS Marketplace.
• Precios y límites de Vercel Sandbox.

Timeouts y cuotas de plataformas cloud

• Google Cloud, Configure request timeout for services.
• Google Cloud, Using WebSockets.
• Google Cloud, Set task timeout for jobs.
• AWS, Configure Lambda function timeout.
• AWS, Lambda quotas.
• AWS, Fargate throttling quotas.
• AWS, ECS service quotas and API throttling limits.

Observabilidad

• OpenTelemetry, Semantic conventions for generative AI systems.
• OpenTelemetry, Gen AI attributes registry.
• OpenTelemetry, Semantic conventions for GenAI agent and framework spans.
• OpenTelemetry, Semantic conventions for generative AI metrics.

El código de Market Analyst Agent —worker de LangGraph, checkpointer de Postgres, memoria en Qdrant, sidecar MCP y el topology de Docker Compose descrito anteriormente— está en GitHub.