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

Viacheslav Dubrov

2026-05-26 · Actualizado 2026-09-06 · 51 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.

Actualización del artículo

Publicado originalmente el 26 de mayo de 2026. Revisado y actualizado el 6 de septiembre de 2026. La actualización cubre nuevas capacidades del runtime y opciones de despliegue, con comparativas de plataformas corregidas, controles presupuestarios y enlaces a las fuentes.

Una ejecución de un agent puede durar horas, pero su proceso worker puede reiniciarse en cualquier momento. El runtime conserva el estado de la ejecución, ejecuta sus herramientas y se recupera si un tool call se detiene a mitad. El modelo sigue eligiendo la siguiente acción. La parte 6 cubre el harness: el código que proporciona contexto, comprueba los tool calls y decide si el trabajo ha terminado.

¿Qué es un AI agent runtime?

Un AI agent runtime es la infraestructura que mantiene en ejecución un agent que usa herramientas después de que termina una llamada al modelo. Almacena el estado de la sesión, ejecuta herramientas, guarda checkpoints, gestiona secretos, escribe trazas, aplica límites de coste y define cómo se despliega el servicio. El modelo elige la siguiente acción. El runtime decide dónde se ejecuta esa acción, registra el resultado y restaura la ejecución tras un fallo. El harness decide si una acción está permitida. No es un store, pero la tabla lo incluye porque el runtime tiene que ejecutarlo en algún sitio.

Cuatro de las cinco primitivas almacenan estado o limitan lo que puede hacer el código: session, sandbox, checkpoint y trace. El harness toma las decisiones sobre memoria, contratos de herramientas y permisos. Este artículo explica los servicios y stores que necesita. La parte 6 explica sus comprobaciones, reintentos y pruebas de aceptación.

Las ejecuciones largas rompen las suposiciones de los procesos stateless

Un endpoint de chat stateless puede mantener el estado de la request en un proceso y descartarlo después de responder. Una ejecución larga de un agent atraviesa reinicios de workers, deploys, reseteos 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:

«Vemos habitualmente ejecuciones individuales de Codex trabajando en una sola tarea durante más de seis horas (a menudo mientras los humanos duermen)».

El equipo de ingeniería de Anthropic describe el problema de estado correspondiente en Harnesses eficaces para agents de larga duración:

«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 implican el mismo diseño de runtime: persistir el estado fuera del worker y hacer que los workers sean reemplazables.

La session debe vivir fuera del proceso worker. Un store durable registra las llamadas al modelo, las intenciones y resultados de las herramientas y las aprobaciones, para que otro worker pueda reanudar desde el último punto seguro tras un crash. Un efecto externo pendiente necesita reconciliación antes de que esa reanudación pueda considerarse segura. Los checkpoints también permiten que el runtime inicie una sesión nueva del modelo cuando se llena la context window, sin reproducir todo el historial. En palabras de Anthropic, las instancias del harness son desechables y reiniciables; el estado durable vive en otro lugar.

Cinco primitivas que debes ubicar antes de desplegar

El artículo de Anthropic Scaling Managed Agents proporciona un vocabulario útil para cinco responsabilidades del runtime. El harness hace avanzar al 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 depurar más adelante. Una implementación puede fusionar componentes, pero las responsabilidades y los límites de fallo siguen necesitando nombres.

Session. Un event log append-only escrito de forma independiente, con las llamadas al modelo, los tool calls solicitados y completados, los errores y las aprobaciones. Una base de datos de checkpoints ayuda a recuperarse, pero el historial del estado del grafo no sustituye a este log.

El término está sobrecargado, así que este artículo utiliza una nomenclatura a nivel de aplicación para tres spans. Un thread es la conversación de un usuario a lo largo de varios días. Es el span de mayor duración y puede contener muchas ejecuciones.

Una model session es la más corta: 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 inicio 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. Varias model sessions pueden escribir en un mismo log, y un conversation thread puede contener varios logs de ejecución. Para recuperarla, despierta la ejecución, carga su session, reconcilia cualquier efecto externo pendiente y reanuda después del último evento: wake(sessionId) → getSession(id) → reconcile pending effects → resume from last event.

En LangGraph, thread_id es la clave de almacenamiento y recuperación del checkpointer para el historial del estado del grafo de un thread (consulta LangGraph persistence); no define los límites de conversación, model session ni event log de este artículo. Dale al event log su propio ID durable de ejecución o session y decide explícitamente cómo se asignan esos ID a los threads de LangGraph. OpenAI Agents SDK incluye diez backends de session integrados, entre ellos SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession y EncryptedSession (consulta la documentación de Sessions). Mantienen un historial de conversación mutable, incluidas operaciones de eliminación, borrado y compactación; asigna un ID de session del SDK al ID del evento de ejecución si resulta útil, pero no trates el historial del SDK como log de recuperación o auditoría append-only sin una garantía equivalente de inmutabilidad.

Harness. El loop de orquestación y la única primitiva de aquí 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 de vuelta en la session, aplica las reglas de reintento y decide si la tarea ha terminado. Las ayudas de planificación y la gestión del contexto codifican suposiciones sobre la capacidad del modelo. La autorización y el aislamiento obligatorios también implementan requisitos que siguen vigentes aunque los modelos mejoren. Anthropic señala esto directamente —la cita aparece en la sección sobre modos de fallo más abajo, que trata principalmente de qué 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 propio código. 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 sandbox concepts de OpenAI Agents SDK asigna las aprobaciones, las trazas, los handoffs y el estado necesario para reanudar ejecuciones al runtime externo. Asigna los comandos, los cambios de archivos y el aislamiento del entorno a la sandbox session.

«Runtime externo» significa ahí el harness junto con sus state stores. En el vocabulario de esta serie, las aprobaciones y los handoffs son decisiones del harness (parte 4 y parte 6); la trazabilidad y el registro necesario para reanudar 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 sola 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 a partir de una imagen padre preparada, de modo que muchas tareas compartan dependencias instaladas y cachés calientes sin compartir su estado escribible.

Los workspaces per-worktree proporcionan checkouts separados para las tareas; Git worktrees comparten la infraestructura del repositorio y no son OS sandboxes. Restringe la ejecución por separado mediante una container, VM o política de procesos. Una aplicación por tarea también puede tener su propia pila 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 que aparece más adelante compara los contratos de aislamiento y persistencia.

Checkpoint. El estado necesario para reanudar: qué nodo del grafo se ejecutó, sus valores más recientes y qué debe ejecutarse a continuación. Un event log responde a qué ocurrió: las acciones solicitadas y sus resultados. Un checkpoint no puede reconstruir eventos que el harness nunca registró.

El PostgresSaver de LangGraph escribe un Checkpoint en cada límite de super-step. Un super-step es una ronda del grafo, ya sea un nodo individual o un batch ejecutado en paralelo. Las escrituras por tarea van a checkpoint_writes, por lo que los outputs correctos de un nodo no se recalculan 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 reconstruir correctamente. El formato está documentado en la página de PyPI 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. Un debug bundle puede exportar su .values como el último estado conocido del grafo; no puede reconstruir detalles de eventos que el harness nunca registró.

Trace. La superficie de depuración y auditoría. Cada llamada al modelo, tool call y paso de sub-agent debería emitir tiempos, estado, modelo y proveedor, IDs de correlación, recuentos de tokens y coste. Los prompts, completions, argumentos de herramientas y tool results son contenido opt-in: la guía de OpenTelemetry sobre GenAI utiliza por defecto metadatos porque esos campos pueden contener datos sensibles. Captúralos solo después de decidir qué redacción o filtrado, controles de acceso y retención se aplican. Cuando falla una ejecución de seis horas, la trace es lo que lees para averiguar qué salió mal. Puede apoyar una investigación, pero el event log y el estado del checkpoint, junto con la gestión de idempotencia, son los que permiten reanudar o reproducir de forma segura. Para entonces, el output de terminal de la ejecución 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). Para un destino compatible con OTLP que admita estas convenciones, la misma instrumentación puede exportar la traza a sistemas como Tempo, Jaeger, Honeycomb o LangSmith, aunque pueden seguir siendo necesarios adapters del backend o configuración específica del destino.

La política y los secretos atraviesan las cinco primitivas

Hay dos límites que 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 sitúa 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 dispara antes de cada tool call y decide si se permite. En producción son habituales dos patrones. El middleware de permisos del sistema de archivos de Deep Agents puede limitar las filesystem tools integradas a rutas declaradas. No gobierna los comandos shell del sandbox, las custom tools ni las llamadas MCP; aplícalo en la política del sandbox o detrás de su propio tool proxy. Anthropic Managed Agents dirige los MCP tool calls personalizados a través de un proxy que contiene las credenciales. La ejecución de comandos del sandbox y la autenticación de Git utilizan rutas separadas; el proxy MCP no es un interceptor universal para todas las acciones. Cuando una llamada sensible necesita aprobación humana, interrupt() de LangGraph y el approval hook de Deep Agents pausan el grafo hasta que una persona dice que sí.

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, usamos el access token de cada repositorio para clonar el repositorio durante la inicialización del sandbox y lo conectamos al remote local de Git. push y pull de Git funcionan desde dentro del sandbox sin que el agent gestione nunca el token. Para custom tools, admitimos MCP y almacenamos los OAuth tokens en un vault seguro. Claude llama a las MCP tools mediante un proxy dedicado; este proxy recibe un token asociado a la session. … El harness nunca llega a conocer ninguna credencial».

En el stack de referencia market-analyst-agent —un pequeño agent de LangGraph que obtiene datos de mercado y escribe un informe de analista, construido a lo largo de esta serie— el worker llama localmente a sus herramientas de datos de mercado. El servidor MCP opcional exporta una superficie de herramientas; no es un credential broker implementado entre ese worker y sus proveedores. Ambos contenedores pueden leer el .env de desarrollo compartido. Un broker de producción exigiría mover las credenciales de los proveedores a un store que el worker no pueda leer y enrutar cada llamada relevante a través del broker.

Comprueba la ubicación

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

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

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

El runtime gestiona reintentos, restaura el trabajo previo, aísla workspaces y aplica presupuestos. A medida que las ejecuciones se extienden entre workers y context windows, los fallos se desplazan hacia el estado, los efectos duplicados, el drift del sandbox y los excesos presupuestarios.

Los fallos se agrupan en cuatro categorías:

• Fallos de calidad del output: el agent declara la victoria antes de que el trabajo haya terminado realmente, olvida lo que hizo tras un reset de la context window o confía en su propia autoevaluación y publica un output defectuoso.
• Fallos de control de costes: el agent se atasca en un retry loop o consume el presupuesto de tokens o tool calls sin producir nada útil.
• Fallos de estado y crash: los workspaces divergen porque una ejecución toca archivos que pertenecen a otra, los tool calls se ejecutan más de una vez porque los reintentos los reproducen o se pierde trabajo cuando muere un worker entre eventos.
• Fallos de context window: el modelo resume y abandona pronto porque cree que se está quedando sin espacio, aunque la ventana aún 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 trata 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 la obsolescencia 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 quedar rápidamente obsoletas 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:

«Borramos 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 Vercel publicó mantenía dos herramientas, ExecuteCommand y ExecuteSQL, sustituyendo un ejemplo de código antiguo que nombraba diecisiete herramientas. La parte 3 cubre el antes y el después completo. Su resultado publicado 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; de media, en las cinco consultas, el ahorro de tokens fue del 37 %. La lección no es «borra tus herramientas». La asistencia opcional puede volverse redundante a medida que cambia el comportamiento del modelo. Vuelve a probar la suposición cuando cambie el modelo.

Cognition observó el mismo objetivo cambiante en la longitud de la session 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 el contexto se agota, 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. Era un beta flag cuando lo escribieron.

La documentación de context window de Anthropic, consultada el 6 de septiembre de 2026, indica que Sonnet 5 y Opus 5 tienen 1M tokens por defecto; Sonnet 4.5 sigue en 200k. Los modelos Sonnet actuales reciben automáticamente actualizaciones sobre el contexto restante, y la compactación en servidor está disponible en beta para Claude 4.6 y modelos posteriores. Antes de copiar el límite histórico de Cognition, prueba el modelo seleccionado con los controles de contexto que admite. Una ventana mayor o un contador de presupuesto no garantizan una recuperación fiable, y ninguno sustituye al progreso durable fuera del modelo.

El equipo de harness de OpenAI tiene la versión de 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 aplicable 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 completado escribe estado durable antes de que empiece el siguiente.

Escribir cada resultado antes de iniciar el paso siguiente limita el daño de un crash. Un efecto externo en curso es la excepción: un worker puede fallar después de que el proveedor lo confirme y antes de que el harness registre el resultado. El siguiente worker debe reconciliar ese efecto pendiente antes de reanudar desde el último paso completado.

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), carga el último checkpoint e inspecciona el event log en busca de intenciones de herramientas pendientes. Reconcilia cualquier efecto externo pendiente antes de realizar otra llamada al modelo o a una herramienta.
2. Planifica antes de ejecutar cualquier tool call. Especifica qué significa «terminado», cuánto puede gastar la ejecución, qué herramientas puede invocar el agent y qué debe 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. Serializa o coordina explícitamente los tool calls con efectos secundarios. La comprobación de permisos del harness decide si se permite cada uno. Antes del dispatch, añade una intención pending con su idempotency key; cuando vuelva el proveedor, añade el resultado. Las llamadas independientes de solo lectura o idempotentes pueden ejecutarse en paralelo cuando cada una tiene su propio registro durable de intención/resultado y sus resultados se agregan de forma determinista. Si el worker muere entre un efecto secundario y la escritura de su resultado, reanuda consultando o reintentando al proveedor con la misma key y añade el resultado recuperado o needs_human. Stripe, por ejemplo, devuelve el resultado guardado de la primera request cuando se repite una idempotency key; otro proveedor necesita un contrato equivalente de consulta o reintento.
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 generados. Este checkpoint es lo que lee el paso 1 en la siguiente reanudación. Si falta el checkpoint o está obsoleto, la recuperación puede necesitar reconstruir el estado desde el event log, lo que es mucho más lento.
5. Evalúa los artefactos cuando el agent crea que ha terminado: tests, un evaluador con contexto nuevo, validación del schema y comprobaciones del navegador. Si la comprobación pasa, la ejecución termina correctamente. Si falla, la ejecución reanuda desde el último checkpoint limpio con el mensaje de error añadido al contexto e intenta de nuevo.

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

Persiste un ID de operación propiedad de la aplicación antes del dispatch y vincúlalo a los argumentos aprobados. Reutilízalo para recuperar la misma intención de negocio, aunque la replanning genere un nuevo ID de tool call del modelo. Registra esos IDs del modelo por separado para la correlación. Las actualizaciones naturalmente idempotentes pueden necesitar en su lugar una precondición de versión. La guía de reintentos de AWS explica por qué la identidad de la request representa la intención. Define cuándo una acción es realmente nueva y cuánto dura la deduplicación: Stripe permite eliminar las keys después de al menos 24 horas. Reconcilia los payloads modificados y las keys caducadas antes de otro intento.

Elige un único writer activo o un lease por thread. Para las entradas que llegan durante una ejecución, rechaza, encola, interrumpe o revierte explícitamente; el relato sobre el runtime de Deep Agents describe estas opciones. La cancelación debe detener nuevos dispatches, registrar la solicitud y reconciliar los efectos en curso; matar el worker no deshace una llamada al proveedor.

La aplicación del presupuesto debe estar junto al dispatch. Las llamadas concurrentes no deben gastar la misma asignación restante. Prometheus es un sistema de monitorización, no un ledger autoritativo del gasto por request. Reserva de forma conservadora y reconcilia el uso real; la contabilidad retrasada del proveedor y la cancelación aún pueden causar excesos.

Los nuevos controles del modelo ayudan a regular la ejecución, pero no son los propietarios de su límite de gasto. Los task budgets beta de Anthropic proporcionan a los modelos admitidos de Messages API un presupuesto orientativo para un agentic loop. Se pueden superar; max_tokens limita una respuesta, no toda la ejecución. La compatibilidad depende del modelo: Opus 5 admite task budgets, mientras que Sonnet 5 no. Mantén el ledger de dispatch y la ruta de cancelación aunque el modelo reciba una indicación de presupuesto.

Las paradas de seguridad del proveedor necesitan su propia ruta terminal. Para misalignment_policy_violation de OpenAI, detén el dispatch, conserva los registros correlacionados y solicita la revisión de un operador en lugar de reintentar. Gestiona los errores de stream después de un output parcial y reconcilia los efectos previos; la parte 4 explica el límite de monitorización.

La evaluación debe incluir evidencias externas al contexto que produce el output. Un evaluador con contexto nuevo reduce el sesgo del contexto compartido, mientras que los tests, linters, comprobaciones del navegador y la validación del schema proporcionan 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 la validación determinista con un reviewer model cuando siga siendo necesario el juicio.

Once patrones de despliegue de AI agents y qué determina la elección

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 conexión, no una elección de proveedor. El gráfico siguiente muestra en qué punto del eje de duración de la ejecución resulta cómoda cada forma. El texto posterior explica qué determina la elección.

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 equipos, la forma utilizada por el repositorio de referencia y el esqueleto del 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 la 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 request)

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 alcanza como máximo 60 minutos y cualquier panic de la web tier mata la ejecución. El SDK es el harness. La ejecución de herramientas no confiables necesita un sandbox independiente y el estado normalmente vive en la memoria del proceso salvo que lo envíes explícitamente a otro sitio. No uses esta forma para trabajos de varias horas.

2. Queue + worker + checkpoint DB

Es la opción predeterminada que recomiendo a la mayoría de equipos y la implementación de demo con forma de producción en market-analyst-agent: un worker de Python con un checkpointer de PostgreSQL, Redis Streams (o RabbitMQ) para la queue 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 queue para el desarrollo síncrono, pero la queue forma parte de la arquitectura de producción cuando necesitas envío asíncrono y backpressure.

En el patrón de producción, la aplicación acepta una request, crea una fila de session, inserta un job en la queue y devuelve un run ID. El worker obtiene el job, ejecuta el harness, escribe eventos de session y checkpoints, transmite el estado y almacena artefactos durante la ejecución. Postgres persiste, los workers son reemplazables y la profundidad de la queue proporciona backpressure. El cómputo Spot/Preemptible funciona siempre que las escrituras durables de eventos y checkpoints terminen antes de que el worker informe de éxito. El repositorio enlazado demuestra la forma, no una recuperación durable verificada. Su consumer lee mensajes nuevos sin reclamar jobs pendientes, hace ACK de las excepciones y redeliverya el trabajo con un estado inicial nuevo en lugar de un contrato de reanudación definido. En producción hacen falta semánticas de claim/lease/reclaim/ACK y pruebas de fallos antes de poder llamar recuperable a esta topología.

En esta forma, el worker es el harness. Su contenedor 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. El event store posee el historial de session; PostgresSaver posee el estado de checkpoint. Pueden compartir una base de datos solo cuando el harness escribe explícitamente ambos schemas. Las trazas pasan por OpenTelemetry a la pila de observabilidad que ejecutes.

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 event-history log respaldado por Cassandra, MySQL o Postgres, de modo que puede reproducirse tras fallos. Los despliegues del código del workflow que se solapen con una ejecución necesitan Worker Versioning o patches seguros para la reproducción; sustituir el código sin esa disciplina puede romper el replay. La integración de Temporal con OpenAI Agents SDK, disponible con carácter general desde marzo de 2026, incluye un helper OpenAIAgentsPlugin y otro 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 a mitad de una conversación. Los workflows inactivos consumen cero cómputo. Las limitaciones son reales: los agents en tiempo real no son compatibles y el streaming sigue marcado como experimental; LocalShellTool y ComputerTool están desactivados porque no encajan en un modelo distribuido.

Usa esta forma cuando la ejecución tenga puntos de espera reales: aprobaciones humanas, callbacks externos, esperas largas, reintentos con reglas de negocio o ventanas de deploy, y el equipo pueda operar el versionado de workflows seguro para replay. Una aprobación humana se convierte en una espera durable que no consume cómputo, no en un polling loop.

El Workflow es el harness. El sandbox suele vivir fuera de Temporal y se invoca desde Activities. El estado de session y checkpoint se concentra en el event-history log de Temporal, mientras que la visibilidad de las trazas procede de la UI de Temporal y de los spans de OpenTelemetry en cada Activity.

4. Proveedor de 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 un lugar durable; el sandbox es el entorno de ejecución desechable.

Las cifras de arranque de los proveedores miden intervalos distintos y no constituyen una clasificación de velocidad. Mide por separado el tiempo desde la request a la API hasta el primer comando correcto y la latencia hasta que la aplicación está lista, incluyendo el estado de la imagen/caché, la región, la concurrencia y p95/p99. El arranque de contenedor de aproximadamente un segundo de Modal, por ejemplo, excluye la inicialización de la aplicación. Comprueba los límites de concurrencia de la cuenta antes de hacer load testing.

Daytona registra un vínculo padre-hijo para cada fork independiente, preservando el linaje de los sandboxes derivados. El harness de Codex de OpenAI utiliza la variante por worktree: «Codex trabaja sobre una versión totalmente aislada de esa aplicación, 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 mayor coste y dependencia del proveedor, ambos superiores a los de ejecutar workers compartidos.

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

5. Anthropic Managed Agents (harness alojado)

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

Anthropic factura Managed Agents a las tarifas estándar por tokens más $0.08 por hora de session. 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 retry loop descontrolado añade coste por hora de session al coste de tokens.

Lee las limitaciones. 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. Durante la beta, los túneles MCP y el «dreaming» del agent están detrás de una research preview adicional a la que hay que solicitar acceso; 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 la libertad sobre el harness a cambio de no ejecutar tú mismo el loop.

La configuración cloud predeterminada coloca las cinco primitivas en Anthropic. Con self-hosted sandboxes, tú operas la ejecución, los sistemas de archivos y el egress de red, mientras Anthropic ejecuta la orquestación y el modelo. Las entradas y resultados de las herramientas siguen llegando a su control plane; las skills y la memoria adjuntas se almacenan allí y se sincronizan. Ser propietario de la ejecución no convierte todo el sistema en self-hosted.

Claude Platform on AWS también admite Managed Agents y self-hosted sandboxes; es independiente de Bedrock. Allí, una session autónoma necesita un evento de user-role para volver a autenticarse después de seis horas, y las sesiones self-hosted no pueden adjuntar memory stores. Managed Agents first-party no tiene esas dos restricciones. Comprueba la plataforma además del modelo antes de copiar un diseño de session.

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 personalizado) se pueden cambiar mediante un único valor de configuración. Los archivos y la memoria del agent viven en un sistema de archivos virtual con backends intercambiables; la persistencia de checkpoints es independiente y la memoria puede estar limitada al usuario, al assistant o a ambos. El lock-in es menor que con Managed Agents: el harness tiene 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.

Las cinco primitivas se alojan por defecto, pero todas se pueden cambiar mediante configuración. El sandbox se sitúa detrás de un único valor de configuración. El sistema de archivos de memoria es independiente de la persistencia de threads y checkpoints. La trace se envía a LangSmith.

7. Servicio o job de Google Cloud Run

Cloud Run tiene dos modos de runtime diferentes, y cuál encaja depende de cómo se invoque el agent. Los services están ligados a HTTP y escalan a cero entre requests; 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 one-shot que sale cuando termina la tarea. Ambos pueden alojar el harness, pero ninguno conserva estado entre ejecuciones. Las sessions y los checkpoints deben vivir en Postgres, Spanner o un store externo similar.

Los límites estrictos son muy diferentes entre ambos. Timeout de requests de Cloud Run service: 300 s por defecto, máximo 3.600 s (60 min). Los WebSockets tienen el mismo timeout. Cloud Run jobs: 10 min por tarea por defecto, máximo 168 h (7 días); para tareas que usan GPUs, máximo 1 hora. La facturación basada en instancias (CPU siempre asignada) sigue permitiendo scale-to-zero; las instancias mínimas son un ajuste independiente; 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 de mayor duración. Cloud Run Jobs puede mantener una tarea activa durante días, pero no ofrece replay durable entre deploys, cambios de versión o sustituciones de workers. Un workflow más largo puede abarcar varias ejecuciones cuando un orquestador externo posee el progreso durable.

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

8. AWS Lambda: invocaciones limitadas y workflows durables

El timeout máximo de una función Lambda es de 900 s (15 minutos), sin excepciones. 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 regionales y privadas pueden configurar un timeout mayor. Las durable functions de Lambda, lanzadas en diciembre de 2025, añaden checkpoints, pasos y esperas gestionados entre ejecuciones de hasta un año. La invocación activa sigue estando limitada, mientras que el workflow durable puede sobrevivirla. Compara los runtimes, regiones, reglas de replay e idempotencia de Activities admitidos con tus requisitos.

Lambda puede alojar un harness limitado dentro de su máximo de 15 minutos. El estado de session y checkpoint sigue necesitando ubicaciones externas explícitas; añade un sandbox distinto para código no confiable y exporta las trazas a telemetría externa. Un workflow durable de Lambda puede orquestar trabajos de varias horas mediante invocaciones limitadas.

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

Fargate no documenta un límite estricto de duración de las tareas, a diferencia de una invocación normal de Lambda. Fargate no admite tareas con GPU; las cargas GPU de ECS necesitan instancias EC2 adecuadas o un servicio externo de GPU. Fargate proporciona aislamiento de tareas basado en virtualización, aunque las credenciales y el acceso de red permitido siguen necesitando un threat model. Las cuotas de throttling de Fargate permiten un burst de lanzamiento de 100 y una reposición de 20 por segundo, con presupuestos separados para on-demand y spot. Las cuotas de servicio de ECS limitan los servicios que utilizan descubrimiento de AWS Cloud Map a 1.000 tareas por servicio y los clusters respaldados por EC2 a 5.000 instancias de contenedor.

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 dentro 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 es 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.

Compara también Amazon Bedrock AgentCore Runtime antes de construir tú mismo la capa de session de AWS. Aloja tu código de agent con un ciclo de vida de session gestionado y varias opciones de cómputo. AWS documenta hasta 8 horas en microVMs serverless o 14 días en su tipo de cómputo Instances, que también admite cargas GPU. Instances utiliza recursos EC2 gestionados por AWS en tu cuenta, con un modelo de seguridad diferente al de la opción serverless. Selecciona y prueba explícitamente ese contrato de cómputo; una instancia de mayor duración sigue sin proporcionar ejecución exactamente una vez para un efecto externo.

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 contenedor 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 ante crashes la tienes que construir 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 Job y a veces con un namespace dedicado. Un aislamiento fuerte sigue dependiendo de runtime class, network policy, seguridad de pods y del límite subyacente de container o VM. El estado de session y checkpoint vive en una base de datos externa o en un PersistentVolumeClaim.

11. Docker Compose local (solo desarrollo)

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

Compose refleja la forma n.º 2 en un solo host. En el stack de referencia, Postgres contiene el estado de checkpoint y el contenedor del worker es el harness. Una session con forma de producción necesita su propio event store append-only; el historial de PostgresSaver por sí solo no lo proporciona. El montaje de workspace compartido es práctico para desarrollo, pero no aísla ejecuciones no confiables. La pila opcional de OpenTelemetry registra las trazas.

Stack de referencia: Docker Compose

La topología de referencia, utilizada 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 una pila opcional de observabilidad Prometheus / Grafana / Loki / Tempo / OTel. En el compose local, Redis es opcional únicamente porque el runner síncrono puede llamar directamente al worker. docker compose up levanta localmente la topología principal; el sidecar MCP y la pila de observabilidad son perfiles opt-in (--profile mcp, --profile observability).

El diagrama muestra el PostgresSaver de la demo local. Una session con forma de producción añade un schema de eventos escrito por separado para las intenciones y resultados de herramientas; PostgresSaver sigue siendo únicamente el estado de checkpoint.

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 hacen falta 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 construido 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 interesante ocurrió hace cinco horas, el output de 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.

Las pilas de producción suelen cubrir cuatro tipos de artefacto, en dos grupos. Dos se leen después de que termine la ejecución, para postmortems y replay: un event log consultable de cada paso y las trazas de OpenTelemetry sobre 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 produce en el workspace. El otro es una pila de observabilidad por worktree que el propio agent puede consultar mientras sigue trabajando.

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

Cada llamada al modelo, tool call, resultado, error y aprobación se escribe en almacenamiento durable, identificado por session ID y timestamp. Cuando termina la ejecución, se consulta como una tabla de base de datos normal. 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 shell script de larga duración que resulta llamar a un LLM, no un agent de larga duración».

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

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

En 2026 salieron del repositorio principal de convenciones semánticas de OpenTelemetry para pasar a su propio repositorio de convenciones semánticas 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 usar el estándar es la portabilidad: en destinos compatibles con OTLP que admitan estas convenciones, cambiar de backend puede no requerir reinstrumentar el código, aunque pueden seguir siendo necesarios adapters del backend o configuración específica del destino.

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

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

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

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

(El evaluador 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).

Una pila mínima de observabilidad self-hosted

Para algo como market-analyst-agent:

1. OpenTelemetry Collector con el GenAI Normalizer Processor (contrib, alpha) para los atributos GenAI admitidos. Utiliza los processors genéricos Attributes o Transform para filtrar o reescribir los 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 model server, así que solo las obtienes si alojas los weights (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 transporte de OpenTelemetry), y se combina con la instrumentación de OpenInference.
• Dashboard de tracing de OpenAI: automático cuando utilizas OpenAI Agents SDK o su integración con Temporal.
• Tracing de Claude de Anthropic: para sesiones que se ejecutan dentro de Managed Agents.

Instrumenta el nodo de LangGraph

Este es un extracto ilustrativo y el runner de ejemplos del repositorio lo omite. Supone que el nodo de LangGraph ya tiene un span activo de OpenTelemetry, el thread_id actual y un objeto usage de respuesta del proveedor con input_tokens y output_tokens; la configuración del tracer, la configuración de exportación y el mapeo del usage 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)

Nombres de atributos tomados literalmente del registro de convenciones semánticas GenAI de OpenTelemetry.

Tres consultas que merece la pena tener en un dashboard

# Loki: output tokens per agent in the last hour (one completion event per call)
sum by (gen_ai_agent_name) (
    sum_over_time({service_name="market-analyst-agent"} | json | event = "model_call_completed" | unwrap gen_ai_usage_output_tokens | __error__="" [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 }

La agregación de LogQL supone exactamente un evento de completion registrado por cada llamada al modelo. Deduplica esos eventos antes de la ingesta; rate informaría de tokens por segundo en lugar de este total de una hora. Valida el mapeo de campos frente al stream de Loki desplegado.

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 solicitarías en un postmortem:

• events.jsonl: exportación del event store append-only escrito por separado por el harness, incluidos tool intents, resultados, aprobaciones y errores.
• checkpoints.jsonl: historial del estado del grafo procedente de checkpointer.list({"configurable": {"thread_id": ...}}), etiquetado como checkpoints, no como event log.
• last_state.json: StateSnapshot.values del último super-step correcto.
• trace.json: spans exportados mediante OTLP para la ejecución; los metadatos son la base y cualquier contenido capturado sigue la política de trazas.
• 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 inicializador.
• screenshots/*.png: lo que vio el agent.
• PROGRESS.md, feature-list.json y cualquier otro archivo de progreso escrito por el agent.
• env.txt: tags de imagen, versión del modelo y SHA del commit del harness.

En conjunto, estos artefactos pueden proporcionar a una persona o a un reviewer agent evidencias suficientes para reconstruir el fallo, siempre que el harness escribiera el event store mientras la ejecución estaba viva. «El agent se atascó» es vago. 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

Usa la duración como primer filtro:

• Menos de 30 segundos, idempotente: SDK limitado al ciclo de vida de la request en 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. Utiliza un motor de workflow durable si también necesitas versionado y replay.
• Más de 24 h, debe sobrevivir a deploys: motor de workflow durable (estilo Temporal). Cloud Run Jobs puede mantener trabajos largos hasta su límite de tarea, pero no ofrece semánticas de replay.
• Loops de entrenamiento de reinforcement learning de varios días: K8s Job + volume + Temporal.

Después de ese 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.

Adecuación de la plataforma por caso de uso

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

Las celdas condicionales utilizan la misma regla para todas las plataformas. Las opciones AWS/VPC y GPU de Deep Agents dependen de un despliegue híbrido o de un proveedor de sandbox; Managed Agents puede utilizar ejecución operada por el cliente manteniendo la orquestación hosted. La fila de elección de sandbox incluye una integración con un proveedor externo que construyes en un runtime propio o configuras en un harness gestionado. No promete un snapshot del estado en ejecución. Un Kubernetes Job también necesita una capa de API o queue para una request interactiva; completarse rápidamente no lo convierte en un servicio HTTP. Compara el acceso de red, el hardware, la recuperación y la ruta de exportación del estado del despliegue elegido antes de seleccionarlo. La fila de código del harness se refiere al acceso a la implementación del loop, no a la portabilidad de un despliegue gestionado ni de su estado. La ejecución GPU en Kubernetes también requiere nodos GPU, drivers y un device plugin.

Managed Agents requiere Claude y una orquestación operada por Anthropic. Su sandbox self-hosted opcional puede encajar con la ejecución en una red privada, pero el requisito de alojar por tu cuenta la inferencia o el control plane sigue descartándolo. Revisa qué entradas y resultados de herramientas, skills y memoria pueden atravesar ese límite. El trabajo interno de coding puede encajar cuando esos flujos de datos sean aceptables y el equipo quiera delegar la operación del harness.

Conviene modelar el precio antes de comprometerte, no después. La línea de horas de session es $0.08/hora además de los costes estándar de tokens. Si una única session se ejecutara continuamente, serían aproximadamente $58/mes por session. Con 100 sesiones ejecutándose continuamente, serían aproximadamente $5.800/mes antes de los tokens. Multiplica $0.08 por las horas esperadas de sesiones concurrentes, súmalo a tu factura de tokens y compáralo con lo que costaría un stack queue + worker en tu propia infraestructura. Migrar más adelante desde Managed Agents 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. Propio 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 puede confundir. Ofrece LangGraph, una librería con licencia MIT que alojas tú mismo (propio), y Deep Agents Deploy, un producto gestionado que ejecuta un harness de Deep Agents sobre LangSmith Deployment en su modo cloud predeterminado (hosted). Misma empresa, dos modelos operativos distintos. Lo que eliges es quién ejecuta el loop, no qué logo aparece en la librería. (Deep Agents Deploy también tiene un modo self-hosted para equipos que quieren la ergonomía del harness sin el componente cloud; ese modo pertenece a la categoría propia).

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, el pause/resume o las semánticas de fork del proveedor encajen con el threat model y el presupuesto de arranque. Docker o Fargate pueden servir para cargas internas de confianza que necesiten acceso a la VPC o una residencia estricta de datos, 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.

State stores: Git, DB y object storage juntos

Los agents de larga duración suelen utilizar tres state stores a la vez porque cada uno posee un artefacto diferente.

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 session un historial compacto.

La base de datos de checkpoints almacena el estado del grafo: qué se decidió, qué nodos se ejecutaron, qué resultados volvieron y qué debe ejecutarse a continuación. El artifact store contiene outputs 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 la carga tenga forma de código (ediciones en varios archivos, refactors, generación de aplicaciones) o sea suficientemente documental como para que importe el historial de archivos. El patrón es sencillo: crea una rama de ejecución, haz un commit inicializador y después crea commits en límites significativos: después de la configuración, después de cada feature, después de que pasen los tests y después de la limpieza final. Guarda el SHA del commit más reciente del workspace junto a la fila del checkpoint. Al reanudar, el siguiente worker hace checkout de 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.

Esto convierte git en una superficie de recuperación para el artefacto que se está editando, no en 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é reintento ya utilizó su idempotency key. El harness de Anthropic utiliza commits inicializadores y commits por feature como fuente de verdad para la recuperación del workspace; el modelo lee git log --oneline -8 para recuperar el estado. Omite git cuando el producto de trabajo es una única respuesta conversacional. La sobrecarga no compensa.

Cuándo utilizar DB checkpointing

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 precisamente por ese motivo. No metas artefactos de workspace a escala de terabytes en el checkpoint; deben ir a object storage.

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

Utiliza object storage cuando:

• el output 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 diferentes.

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

Cuándo solicitar aprobación humana

Define los requisitos de aprobación a partir del riesgo de la acción, la autoridad ya concedida y la política de despliegue. Una escritura reversible en una base de datos de borradores es distinta de un cargo a un cliente o un cambio destructivo en producción. Cuando se requiera aprobación, muestra la acción real, los argumentos y el destino, persiste la decisión y vuelve a comprobarla si cambia la llamada propuesta; no ejecutes una llamada rechazada. interrupt() de LangGraph y el approval middleware de Deep Agents pueden pausar la ejecución para tomar esa decisión. La parte 4 explica por qué es una decisión de permisos, no una instrucción del prompt.

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é store es propietario de los eventos de session y 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 reintentar de forma segura?
7. ¿Dónde se aplica el límite de coste por ejecución?
8. ¿Qué evidencias deterministas deciden que la ejecución ha terminado y qué criterios restantes necesitan un reviewer?
9. ¿Dónde viven los outputs finales cuando el sandbox ha desaparecido?
10. ¿Podemos explicar mañana una ejecución fallida sin volver a ejecutarla?

Si la respuesta a cualquiera de estas preguntas es «el prompt le dice al agent que tenga cuidado», el sistema aún 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, , 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 reintento y parada, qué debe conservar un handoff y cómo una comprobación de aceptación externa decide que una ejecución ha terminado. También es 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.
• Documentación de LangChain, Deep Agents permissions.
• 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: Code with Claude 2026 take-home con sub-agent evaluador 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 on AWS Marketplace.
• Vercel Sandbox pricing and limits.

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 de Qdrant, sidecar MCP y la topología de Docker Compose descrita anteriormente) está disponible en GitHub.