Saltar a contenido

Traducción automática

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

Runtime de agentes de IA de larga duración en 2026: sesiones, sandboxes, checkpoints y harnesses

Parte 5 de la serie Engineering the Agentic Stack

Las cuatro entradas anteriores trataron el interior del agente: bucles de razonamiento, arquitectura de memoria, uso de herramientas, seguridad. Esta trata del exterior: el runtime de producción alrededor de los agentes de IA de larga duración.

Los agentes de IA en producción en 2026 dejaron de ser manejadores de peticiones y pasaron a ser workers en segundo plano. Una ejecución puede durar varias horas. El worker que la aloja puede no durar tanto. La ingeniería interesante salió del agente y se movió al runtime que lo rodea. El modelo elige el siguiente movimiento. El runtime decide qué ocurre con ese movimiento cuando el worker muere a mitad de llamada.

Resumen: Los agentes de IA de larga duración necesitan un runtime fuera del modelo: registros de sesión, lógica de harness, aislamiento por sandbox, checkpoints, trazas, comprobaciones de políticas, secretos y límites de coste. Queue + worker + checkpoint DB es la opción por defecto cuando controlas el stack; los harnesses alojados encajan cuando las restricciones del proveedor son aceptables. Elige primero por la duración de la ejecución y después por la semántica de recuperación, las necesidades de replay, el aislamiento del sandbox y la responsabilidad operativa.

Es una entrada larga. Esto es lo que vas a encontrar:

La primera mitad recorre las cinco primitivas del runtime y los modos de fallo que cada una está ahí para manejar. La segunda mitad compara once formas de despliegue — SDK dentro de un app server, queue + worker, Temporal, Anthropic Managed Agents, Deep Agents Deploy, Cloud Run, Lambda, ECS, Kubernetes Job por sesión, más otras dos — y termina con una guía de decisión para elegir una.

Qué cambia cuando las sesiones de agentes de larga duración sobreviven más que los procesos

Hace un año, «desplegar un agente» significaba envolver un endpoint de chat en un contenedor y ponerle delante un balanceador de carga. El trabajo era indistinguible del de cualquier otro servicio web en Python. Eso dejó de ser cierto en el momento en que los agentes empezaron a ejecutarse durante horas en vez de segundos.

El equipo de OpenAI Codex puso una cifra a la nueva línea base en su análisis sobre harness engineering:

"We regularly see single Codex runs work on a single task for upwards of six hours (often while the humans are sleeping)."

El equipo de ingeniería de Anthropic formuló el problema estructural con la misma claridad en Effective harnesses for long-running agents:

"The core challenge of long-running agents is that they must work in discrete sessions, and each new session begins with no memory of what came before."

Si te tomas en serio esa frase, todo el stack de runtime cambia de forma. De «sesiones discretas sin memoria compartida» se derivan tres consecuencias, y cada una obliga a introducir una pieza concreta de infraestructura en el diseño.

Si las sesiones son discretas, la sesión tiene que vivir fuera del proceso. El estado en memoria desaparece en cuanto el worker sale, así que la sesión tiene que escribirse en un almacén duradero que el siguiente worker pueda leer. Si una sesión puede reanudarse tras un fallo, el registro duradero tiene que contener todo lo ocurrido hasta ese momento, no solo la respuesta final. Eso permite que el siguiente worker retome en el punto correcto en vez de reproducir la ejecución desde cero. Si el modelo llena su ventana de contexto antes de terminar el trabajo, algo tiene que hacer checkpoint del progreso, desmontar la sesión actual y arrancar una nueva que cargue el checkpoint en vez de reproducir todo el historial. En palabras de Anthropic, el harness se convierte en "cattle": instancias desechables, reiniciables e idénticas. El estado vive en otra parte.

El modelo decide qué hacer después. El runtime decide si ese movimiento está permitido, dónde se ejecuta, cómo se registra y cómo se reanuda la ejecución tras un fallo. El resto de esta entrada trata de ese runtime.

Las cinco primitivas de runtime que necesita cualquier agente de IA de larga duración

El texto de Anthropic Scaling Managed Agents dio a la industria un vocabulario útil, y la mayor parte del sector ha convergido hacia él. Cinco componentes hacen la mayor parte del trabajo del runtime. El harness hace avanzar al agente paso a paso; la sesión registra lo que hizo; el sandbox es donde se ejecutan los comandos; el checkpoint es lo que lee el siguiente worker al reanudar; la traza es lo que lees días después cuando necesitas entender qué salió mal. Cada componente es intercambiable siempre que la responsabilidad siga intacta.

Las cinco primitivas del runtime

Session. Un log append-only de todo lo que ha ocurrido: llamadas al modelo, llamadas a herramientas, resultados, errores, aprobaciones. La recuperación es wake(sessionId) → getSession(id) → resume from last event. En LangGraph esto es un thread_id más un checkpointer de Postgres (véase LangGraph persistence). OpenAI Agents SDK incluye diez backends de sesión integrados, entre ellos SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession y EncryptedSession (véanse los docs de Sessions).

Harness. El bucle de orquestación. Llama al modelo, parsea tool calls, las ejecuta, vuelve a escribir los resultados en la sesión y aplica reglas de reintento. Anthropic lo dice sin rodeos:

"every component in a harness encodes an assumption about what the model can't do on its own."

El equipo de Codex de OpenAI llama a esta disciplina harness engineering: desarrollar software sigue exigiendo disciplina, pero ahora una parte mayor se invierte en el andamiaje que en el propio código. El CompiledStateGraph de LangGraph, create_deep_agent de Deep Agents y el propio Claude Code son todos harnesses en este sentido.

Sandbox. El entorno de ejecución aislado donde realmente se ejecutan los comandos. La página de conceptos de sandbox de OpenAI Agents SDK traza la frontera con claridad:

"The outer runtime still owns approvals, tracing, handoffs, and resume bookkeeping. The sandbox session owns commands, file changes, and environment isolation."

Los sandboxes difieren en cuánto duran y qué recuerdan entre ejecuciones. La forma más simple es ephemeral fresh: se arranca uno para una sola tarea, se destruye al terminar y se paga el coste de cold start en cada ejecución. Los sandboxes persistent paused siguen vivos entre ejecuciones en estado pausado; el sistema de ficheros y un snapshot de memoria se mantienen, así que la siguiente reanudación tarda menos de un segundo en vez de un arranque completo. Snapshot o fork va un paso más allá: cada tarea deriva una imagen copy-on-write de una imagen padre que ya tiene dependencias instaladas y cachés calientes, así que el trabajo caro de setup ocurre una vez y N tareas comparten la imagen base. Los sandboxes per-worktree dan a cada tarea su propio workspace y su propio stack de observabilidad: logs, métricas y trazas separados. Eso te permite depurar la ejecución de un agente sin que se mezcle con la de otro. Más abajo, en esta sección, hay una tabla con cifras concretas de cold start y persistencia por proveedor.

Checkpoint. Estado reanudable. El PostgresSaver de LangGraph escribe un StateSnapshot en cada frontera de super-step, con escrituras por tarea en checkpoint_writes para que las salidas correctas de nodos no se recalculen cuando falla un nodo hermano. El snapshot es un dict serializable a JSON (v, ts, id, channel_values, channel_versions, versions_seen, pending_sends) documentado en la página de PyPI langgraph-checkpoint-postgres y en la referencia de checkpoints de LangGraph.

Trace. La superficie de replay y depuración. Cada model call, tool call y paso de subagente se convierte en un span con tiempos, entradas, salidas, recuentos de tokens y coste. Cuando una ejecución de seis horas falla, la traza es lo que lees para averiguar qué ha salido mal. La salida de terminal de esa ejecución ya no existe para entonces. Las convenciones semánticas GenAI de OpenTelemetry estandarizan los nombres de atributos (qué modelo, qué proveedor, cuántos tokens, qué conversación, qué workflow), de modo que la misma traza se renderiza limpiamente en Tempo, Jaeger, Honeycomb o LangSmith sin tener que reinstrumentar.

La política y los secretos son fronteras separadas del runtime

Hay dos fronteras que atraviesan las cinco primitivas y es más fácil entenderlas como preocupaciones separadas. Son la versión de runtime del argumento de seguridad de la Parte 4.

Motor de políticas

Antes de cada tool call se ejecuta una comprobación de permisos y decide si se permite. En producción son comunes dos patrones. Deep Agents deja que cada subagente declare qué rutas de fichero puede leer o escribir, y el middleware bloquea cualquier cosa fuera de esa declaración. Anthropic Managed Agents enruta cada tool call a través de un proxy MCP, de modo que el proxy impone los permisos en lugar del código del agente. Cuando una llamada sensible necesita aprobación humana, el interrupt() de LangGraph y el hook de aprobación de Deep Agents pausarán el grafo hasta que una persona diga que sí.

Broker de secretos

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

"For Git, we use each repository's access token to clone the repo during sandbox initialization and wire it into the local git remote. Git push and pull work from inside the sandbox without the agent ever handling the token itself. For custom tools, we support MCP and store OAuth tokens in a secure vault. Claude calls MCP tools via a dedicated proxy; this proxy takes in a token associated with the session. … The harness is never made aware of any credentials."

En el stack de referencia market-analyst-agent, el sidecar MCP lee tokens OAuth desde un secreto de Docker (en producción, HashiCorp Vault) y expone solo la superficie de herramientas al worker de LangGraph. El worker nunca ve el token. git push funciona. cat ~/.ssh/id_rsa no.

Una comprobación práctica de cordura en tu propio stack: apunta cada componente que ejecutas y qué primitiva de las cinco implementa. Postgres puede cubrir sesión y checkpoint. El contenedor del worker es el harness. Un servicio de sandbox alojado como Daytona, Modal o E2B es el sandbox. Tempo o LangSmith es la traza. Si ves que dos primitivas viven en el mismo proceso, un solo crash tira ambas. Si dos comparten una única credencial, una sola filtración compromete ambas. Ambas cosas se introducen con facilidad por accidente cuando vas rápido: un worker que también escribe trazas, un token de sidecar que también desbloquea la checkpoint DB.

Modos de fallo del runtime de agentes de IA en producción

El runtime existe para las cosas que el modelo no puede hacer por sí solo: gestionar reintentos, recordar qué hizo hace tres horas, aislar el sistema de ficheros de una ejecución del de otra, detenerse antes de gastar el presupuesto. A estas alturas ya hemos nombrado siete piezas: harness, session log, sandbox, checkpointer, tracer, motor de políticas y broker de secretos. En cuanto una sola ejecución de agente supera unos 30 minutos de tiempo de pared, empieza a aparecer un conjunto reconocible de fallos. La mayoría no tienen nada que ver con la calidad del razonamiento; son problemas de estado, reintentos, sandboxes y presupuestos.

Los fallos caen en cuatro grupos generales:

  • Fallos de calidad de salida: el agente declara victoria antes de que el trabajo haya terminado realmente, olvida lo que hizo tras un reset de ventana de contexto, o confía en su propia autoevaluación y entrega una salida rota.
  • Fallos de control de costes: el agente se queda atrapado en un bucle de reintento o consume un presupuesto de tokens o tool calls sin producir nada útil.
  • Fallos de estado y crash: los workspaces derivan porque una ejecución toca ficheros que son de otra, las tool calls se disparan más de una vez porque los reintentos las reproducen, o se pierde trabajo cuando un worker muere entre eventos.
  • Fallos de ventana de contexto: el modelo resume y termina antes de tiempo porque cree que se está quedando sin espacio, incluso cuando la ventana todavía tiene margen.

La tabla siguiente relaciona cada fallo con el patrón de mitigación, el hook del runtime donde vive esa mitigación y si sigue haciendo falta con la generación actual de modelos. Algunas ya no hacen falta. Cuanto más antiguo sea tu harness, más mitigaciones obsoletas contendrá probablemente.

Modos de fallo y sus mitigaciones

Modo de fallo Mitigación ¿Sigue siendo necesaria? Hook del runtime
Finalización prematura: el agente declara victoria antes de tiempo División generador/evaluador: un evaluador con contexto limpio lee ficheros (no el chat) y vota "done" o "not done". FAIL por defecto en cada comprobación de aceptación. Sí; el quick-start de cwc-long-running-agents de Anthropic sigue incluyendo un subagente evaluador. Subagente sin herramientas Write/Edit y con su propia ventana de contexto
Amnesia de funcionalidades entre ventanas de contexto El agente inicializador escribe claude-progress.txt, feature-list.json, init.sh. El agente de código los lee en cada cold boot. Sí; la compactación por sí sola no cierra esa brecha. Hook de arranque antes de la primera model call de cada sesión
Trabajo duplicado tras un reset de sesión Log de eventos append-only más un archivo de handoff estructurado. Cada nueva sesión empieza con pwd → read PROGRESS.md → review tests. Sí Checkpoint PostgresSaver de LangGraph más artefacto progress.md
Ansiedad por el contexto: el modelo resume y termina antes de tiempo (a) Activar la beta de 1M de tokens pero limitar el uso efectivo a 200k (fix de Sonnet 4.5 de Cognition). (b) Desmontar la sesión y reconstruirla desde un handoff. No en Opus 4.5; Anthropic informa de que "the behavior was gone" y que los resets "had become dead weight." Sí en Sonnet 4.5 y GPT-5/Codex. El driver externo limita la longitud de sesión, arranca la siguiente y reanuda desde el checkpoint
Optimismo en la autoevaluación: el modelo marca su trabajo como correcto Evaluador separado más grounding con Playwright/MCP sobre el DOM real, no sobre capturas. La harness design de Anthropic para frontend penaliza los valores por defecto «AI-style». Sí El evaluador se ejecuta en una sesión de sandbox separada sin herramientas de escritura
Bucles atascados y tormentas de reintentos Límite de iteraciones por turno, exponential backoff, circuit breaker sobre la tasa de error de herramientas. Presupuesto duro de tool calls. Sí Decorator en el nodo de ejecución de herramientas; RetryPolicy en Temporal Activities (véase Temporal OpenAI Agents SDK contrib)
Deriva del workspace: el agente edita ficheros no relacionados Commits de Git como checkpoints, middleware de permisos de fichero, montaje de workspace por sesión. El middleware de Deep Agents permite declarar lectura/escritura por ruta. Sí Middleware de permisos de fichero de LangGraph o fork por tarea en Daytona/Runloop
Coste desbocado de tokens o herramientas Presupuesto de tokens por ejecución, presupuesto por herramienta, kill switch ligado a un contador de Prometheus. Sí; una sesión de Opus de 24 horas con mala presupuestación puede quemar en una tarde el presupuesto semanal de API (Addy Osmani sobre agentes de larga duración). Atributos de spans para atribución de costes más regla de Alertmanager
Tool calls no idempotentes Clave de idempotencia por tool call. En workflows duraderos, los reintentos pueden disparar la misma tool call más de una vez, así que una clave de deduplicación bloquea el duplicado. Sí Temporal Activity con start_to_close_timeout y clave de idempotencia
Trabajo perdido tras un crash del proceso o del sandbox Session log duradero fuera del proceso; checkpoint tras cada super-step. wake(sessionId) → getSession(id) → resume. Sí PostgresSaver en cada super-step, o envolver como Temporal Workflow

Hay dos ideas que aparecen en todas las filas. Anthropic, sobre la obsolescencia de los harnesses en Harness design for long-running application development:

"Every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing, both because they may be incorrect, and because they can quickly go stale as models improve."

Vercel, sobre el problema relacionado de tener demasiadas herramientas codificando demasiadas suposiciones, en We removed 80% of our agent's tools:

"We deleted most of it and stripped the agent down to a single tool: execute arbitrary bash commands. We call this a file system agent."

El resultado que reporta Vercel para una consulta representativa: la tasa de éxito pasó del 80% al 100%, y el peor caso bajó de 724 s / 100 pasos / 145.463 tokens (fallido) a 141 s / 19 pasos / 67.483 tokens (con éxito). La lección no es «borra tus herramientas». Es que cada primitiva de tu runtime, incluida la superficie de herramientas, tiene fecha de caducidad. Vuelve a probar la suposición cuando cambie el modelo.

Cognition vio el mismo objetivo móvil en la longitud de sesión con Sonnet 4.5. En Rebuilding Devin for Claude Sonnet 4.5 describen un modelo que escribe proactivamente SUMMARY.md / CHANGELOG.md cuando detecta agotamiento de contexto, pero subestima cuántos tokens le quedan. Su solución es activar la beta de 1M de tokens y limitar el uso a 200k para que el modelo siga creyendo que tiene margen. Esa mitigación también acabará convirtiéndose en lastre.

El equipo de harness de OpenAI resume la disciplina en una línea: "Humans steer. Agents execute." Cuando algo falla, la pregunta no es «inténtalo más fuerte». Es «qué capacidad falta, y cómo hacemos que sea legible y aplicable para el agente».

El ciclo de vida de una ejecución saludable

Una ejecución bien comportada es aburrida. Es una cadena de pasos pequeños y recuperables, cada uno escribiendo su resultado en almacenamiento duradero antes de que empiece el siguiente, en lugar de una única petición gigante que tiene que salir bien de extremo a extremo. Dividir una ejecución en pasos de esa forma es lo que le permite sobrevivir a los fallos: cuando algo falla, solo se pierde el paso que estaba en vuelo, y el siguiente worker reanuda desde el último paso completado en lugar de empezar de nuevo.

El ciclo de vida de una ejecución de agente desplegado

  1. Arranca desde una sesión nueva o una reanudada. Al reanudar, monta el workspace desde su último estado conocido, lee cualquier archivo de progreso que dejara el intento anterior (PROGRESS.md, feature-list.json) y carga el último checkpoint desde la base de datos. Aquí es donde el harness entrega al agente todo lo que el worker anterior tenía en memoria antes de morir.
  2. Planifica antes de que se dispare ninguna tool call. Deja por escrito qué significa "done", cuánto se le permite gastar a la ejecución, qué herramientas puede invocar el agente 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 frente a lo que contrastarse.
  3. Ejecuta una tool call cada vez. La capa de políticas decide si permitir la llamada. El harness la ejecuta, captura el resultado y escribe un evento en el session log. Un paso, un evento. Un crash entre eventos es recuperable porque la fuente de verdad es el log, no la memoria del worker.
  4. Haz checkpoint en las fronteras de super-step, o después de cada evento en un harness más simple. Persiste el estado del grafo, el diff del workspace y las referencias a cualquier artefacto producido. Ese checkpoint es lo que lee el paso 1 en la siguiente reanudación. Si el checkpoint falta o está obsoleto, la recuperación se degrada a reproducir todo el session log desde cero, lo cual es bastante más lento.
  5. Evalúa frente a los artefactos cuando el agente cree que ha terminado: tests, un revisor con contexto limpio, validación de esquema, comprobaciones en navegador. Si la comprobación pasa, la ejecución sale con éxito. Si falla, la ejecución reanuda desde el último checkpoint limpio con el mensaje de fallo añadido al contexto y vuelve a intentarlo.

No hay ningún paso en esa lista que exija que el agente recuerde nada entre ejecuciones. El estado vive en la sesión y en el checkpoint, y el agente lo vuelve a leer en cada reanudación.

Las herramientas con efectos laterales necesitan idempotencia. Cualquier herramienta con efectos laterales necesita una clave de idempotencia derivada del ID de sesión y del ID de tool call, almacenada antes de disparar el efecto lateral. 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 por defecto en queues y motores de workflow. Si repetir una tool call puede causar daño real, la herramienta no está lista para agentes.

La evaluación tiene que ejecutarse fuera del contexto productor. El mismo contexto que produjo la respuesta no puede juzgar con fiabilidad si la respuesta es correcta. Un evaluador nuevo lee ficheros y artefactos, ejecuta tests, lint, comprobaciones de navegador o validación de esquema, y devuelve pass, fail o needs_human. Para agentes de código, esto es otra sesión de modelo con herramientas de solo lectura. Para agentes de datos e informes, es un validador determinista más un modelo revisor.

Once patrones de despliegue de agentes de IA y qué decide entre ellos

Una vez nombradas las cinco primitivas, la cuestión es qué forma de despliegue las ejecuta. Por «forma» me refiero a una disposición de esas primitivas: dónde vive el harness, dónde persiste el estado y qué tipo de sandbox ejecuta el trabajo. No es solo elegir un proveedor. El gráfico de abajo muestra dónde se siente cómoda cada forma en el eje de duración de la ejecución. El texto que sigue explica qué decide entre ellas.

Si solo lees una de las once, lee la forma 2: queue + worker + checkpoint DB. Es la opción por defecto que recomiendo a la mayoría de equipos, la forma usada por el repo de referencia y el esqueleto sobre el que varían la mayoría de las demás: queue → worker → estado duradero, sustituyendo el origen del sandbox, el propietario del harness o el motor de estado. Leer primero la forma 2 hace que el resto sea más rápido de escanear.

Formas de despliegue y sus rangos ideales de duración

El gráfico compara las formas por duración de ejecución. La matriz de abajo las compara por propiedad: dónde vive físicamente cada una de las cinco primitivas. Las celdas verdes son donde la forma proporciona la primitiva; las grises, donde la conectas tú mismo.

Dónde vive cada primitiva en cada forma de despliegue

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

La forma original. El SDK del agente se ejecuta dentro de un request handler. Buena para tareas de menos de 30 segundos, demos y herramientas internas. 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 pánico en 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 empujes explícitamente a otro sitio. No la uses para trabajo de varias horas.

2. Queue + worker + checkpoint DB

La opción por defecto que recomiendo a la mayoría de equipos, y la forma de producción usada en market-analyst-agent: un worker Python con checkpointer en PostgreSQL, Redis Streams (o RabbitMQ) para la queue de entrada, y un sidecar MCP para herramientas. Buena para ejecuciones de 10 minutos a varias horas con pasos idempotentes. El runner local puede saltarse la queue para desarrollo síncrono, pero la queue forma parte de la forma de producción en cuanto necesitas envío asíncrono y backpressure.

La app acepta una petición, crea una fila de sesión, empuja un job y devuelve un ID de ejecución. El worker recoge el job, ejecuta el harness, escribe checkpoints, emite estado en streaming y almacena artefactos sobre la marcha. Postgres sobrevive, los workers son cattle y la profundidad de la queue te da 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. El contenedor del worker más un montaje de workspace por hilo es el sandbox. Postgres es dueño del estado de sesión y checkpoint. Las trazas salen por OpenTelemetry hacia el stack de observabilidad que ejecutes.

3. Motor de workflow duradero (estilo Temporal)

El código de orquestación del agente se ejecuta dentro de un Temporal Workflow; las model calls y tool calls se ejecutan como Activities. El estado del workflow vive en un log de historial de eventos respaldado por Cassandra, MySQL o Postgres, así que el estado se reproduce limpiamente entre despliegues. La integración Temporal × OpenAI Agents SDK, en preview pública, incluye un helper OpenAIAgentsPlugin y otro activity_as_tool, y el análisis sobre agentic sandboxes describe cómo bifurcar un agente en ejecución hacia otro proveedor de sandbox a mitad de conversación. Los workflows inactivos consumen cero cómputo. Las advertencias son reales: los agentes de streaming y voz no están soportados en la integración actual, y 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, sleeps largos, reintentos con reglas de negocio, ventanas de despliegue. Una aprobación humana se convierte en un sleep duradero que no consume cómputo, no en un bucle 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 sesión y checkpoint se colapsa en el log de historial de eventos de Temporal, mientras que la visibilidad de traza viene de Temporal UI más spans de OpenTelemetry en cada Activity.

4. Proveedor de sandbox por sesión

Una forma más reciente. Cada ejecución de agente recibe su propia microVM o contenedor de un proveedor sandbox-as-a-service. El harness vive en algún lugar duradero; el sandbox es el entorno de ejecución desechable.

Proveedor Aislamiento Sesión máxima Concurrencia Persistencia Cold start
E2B Firecracker microVM 1 h Hobby / 24 h Pro 20 / 100 (hasta 1.100 con add-on) Pause/resume, ~4 s/GiB pause, ~1 s resume (beta pública) ~150 ms p50
Vercel Sandbox Firecracker microVM 45 min Hobby / 5 h Pro/Ent 10 / 2.000 Desechable n/a
Daytona Docker (Kata opcional) auto-stop/archive configurable según tier Stop → Archive → Delete; fork soportado ~90 ms (algunas configs 27 ms)
Modal Sandboxes gVisor ciclo de vida típico de 1–15 min alta Volúmenes para persistencia; snapshot de memoria en preview "about one second" según docs de Modal
Runloop Devboxes microVM (hipervisor propio) suspend/resume; snapshot+branch "more than 30,000 concurrent instances" según la ficha de AWS Marketplace Snapshot + branch desde estado en disco sub-1 s

Fuentes: la comparativa E2B vs Daytona, la documentación de sandboxes de Daytona y su changelog de fork/snapshot, la guía de sandboxes y la guía de cold start de Modal, la ficha de Runloop en AWS Marketplace y los precios de Vercel Sandbox. La documentación de Daytona añade una nota útil sobre la semántica de fork: "the new sandbox is fully independent … Daytona tracks the parent-child relationship in a fork tree." Cada sandbox derivado mantiene un enlace registrado con la base de la que se bifurcó, así que puedes consultar el linaje de cualquier sandbox derivado. El harness de Codex de OpenAI usa la variante per-worktree: "Codex works on a fully isolated version of that app, including its logs and metrics, which get torn down once that task is complete."

Recurre a esta forma cuando el agente ejecuta código no fiable, automatización de navegador, tests o instalaciones de paquetes. La contrapartida es el coste y el acoplamiento con el proveedor, ambos más altos que ejecutando workers compartidos.

El proveedor es dueño solo del sandbox. Harness, session, checkpoint y trace se quedan de tu lado, normalmente conectados como la forma queue + worker de la opción #2.

5. Anthropic Managed Agents (harness alojado)

Lanzado en beta pública el 8 de abril de 2026, tras la cabecera beta managed-agents-2026-04-01. Claude factura Managed Agents a tarifas estándar por token más 0,08 $ por hora de sesión. La facturación tiene granularidad de milisegundos y se aplica solo mientras el estado de la sesión es "running". El tiempo inactivo es gratis; el tiempo de sesión "replaces the Code Execution container-hour billing model when using Claude Managed Agents." Obtienes una sesión alojada, harness, sandbox y proxy MCP respaldado por vault. La separación cerebro/manos es lo que está comprando wake(sessionId): el harness puede reinicializarse en un nuevo worker sin perder estado. Vigila bien la forma del coste; un bucle de reintentos desbocado sobre una factura por hora de sesión sube más rápido que una factura por token.

Lee las advertencias. El descuento de Batch API no aplica ("Sessions are stateful and interactive. There is no batch mode."). Managed Agents no está disponible a través de AWS Bedrock ni Google Vertex AI. La coordinación multiagente y la autoevaluación siguen en preview de investigación. El lock-in es alto: intercambias libertad en el harness por no ejecutar tú mismo el bucle.

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 duradera, memoria, multi-tenant, human-in-the-loop, observabilidad, ejecución de código en sandbox y ejecuciones programadas. Soporta modos cloud, híbrido y self-hosted. Los proveedores de sandbox (LangSmith Sandboxes, Daytona, Modal, Runloop o personalizados) son intercambiables con un único valor de configuración. El estado vive en un sistema de ficheros virtual con backends conectables; la memoria se limita al usuario, al asistente o a ambos. El lock-in es menor que en Managed Agents: el harness tiene licencia MIT, las instrucciones usan el estándar abierto AGENTS.md y los agentes se exponen por MCP, A2A y Agent Protocol. Véase el análisis de LangChain runtime-behind-production-deep-agents.

Las cinco primitivas están alojadas por defecto, pero cada una es intercambiable por configuración. El sandbox queda detrás de un único valor de config. Session y checkpoint viven en un sistema de ficheros virtual con backends conectables. La traza 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 agente. Los services están ligados a HTTP y escalan a cero entre peticiones; el harness se ejecuta como request handler que devuelve cuando termina la ejecución. Los jobs se ejecutan hasta completarse sin entrypoint HTTP; el harness se ejecuta como worker one-shot que sale cuando termina la tarea. Ambos pueden alojar el harness, pero ninguno mantiene estado entre ejecuciones. Las sesiones y checkpoints tienen que vivir en Postgres, Spanner o un almacén externo similar.

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

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

Cloud Run aloja el harness. Session, checkpoint, sandbox y trace son servicios externos que conectas tú, normalmente Postgres o Spanner para session/checkpoint, el propio contenedor como sandbox, y Cloud Logging más OpenTelemetry para trace.

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

El timeout máximo de una función Lambda es 900 s (15 minutos), duro. API Gateway añade además un límite independiente de 29 s. Un harness de agente cuya ejecución mínima útil es «de minutos a horas» no puede sobrevivir en Lambda sin un almacén de estado externo y una estrategia de reinvocación que, en esencia, reconstruye la forma queue + worker desde cero. Usa Lambda para tool calls individuales, como recuperar ficheros o subir a S3, invocadas por un orquestador de mayor duración. No pongas ahí el orquestador.

Como mucho, Lambda aloja una tool call dentro de su límite de 15 minutos. El harness, session, checkpoint, sandbox y trace tienen que vivir en otro sitio.

9. Tarea AWS ECS / Fargate por ejecución

No hay un límite duro documentado para la duración de la tarea (a diferencia de Lambda). Según las cuotas de throttling de Fargate, los lanzamientos están limitados por tasa: ráfaga de 100, recarga a 20 por segundo, con on-demand y spot rastreados en presupuestos separados de 20/s. Cuotas de servicio de ECS: los servicios con descubrimiento de servicios AWS Cloud Map están limitados a 1.000 tareas por servicio; el techo teórico es 5.000 instancias EC2 por clúster. Fargate requiere modo awsvpc, así que cada tarea obtiene su propia interfaz de red y una IP privada, que es la forma adecuada cuando necesitas acceso dentro de la VPC a fuentes de datos sensibles. Fargate Spot está disponible; presupuesta interrupciones. La durabilidad corre de tu cuenta: no hay replay al estilo Temporal integrado.

Fargate aloja el harness y da a cada ejecución su propio sandbox: una tarea por ejecución. Session, checkpoint y trace van a servicios externos. RDS o DynamoDB más CloudWatch/X-Ray son las elecciones habituales.

10. Kubernetes Job o namespace por sesión

Buena opción cuando ya operas Kubernetes y quieres sandbox por sesión con controles a nivel de clúster. Mala cuando necesitas arranque en menos de un segundo, porque descargar la imagen del contenedor e inicializar el pod lleva demasiado en un cold start. El patrón es un Job por ejecución del agente, 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 agentes es caro en sobrecarga de configuración y carga operativa. Solo merece la pena si ya ejecutas K8s por otros motivos.

K8s aloja el harness y el sandbox, normalmente como un Job por ejecución y a veces con un namespace dedicado para un aislamiento más fuerte. Session y checkpoint viven en una DB externa o en un PersistentVolumeClaim. La traza fluye hacia el stack de observabilidad dentro del clúster que ya tengas.

11. Docker Compose local (solo desarrollo)

La referencia para la siguiente sección. La idea de esta forma es que refleje la topología de producción uno a uno (mismas primitivas, misma forma de red) mientras corre en una sola máquina. Lee la lista de «no apto para producción» al final de la siguiente sección antes de poner en producción cualquier cosa que se parezca a esto.

Compose refleja la forma #2 en un único host. Postgres mantiene session y checkpoint. El contenedor del worker es el harness. El montaje del workspace es el sandbox compartido. El stack opcional de OpenTelemetry es la traza.

Stack de referencia: Docker Compose

La topología de referencia, usada en slavadubrov/market-analyst-agent, es un worker de LangGraph, un checkpointer de Postgres, Qdrant para retrieval, un sidecar MCP, una queue Redis para ejecuciones asíncronas parecidas a producción y un stack opcional de observabilidad con Prometheus / Grafana / Loki / Tempo / OTel. En compose local, Redis es opcional solo porque el runner síncrono puede llamar directamente al worker. docker compose up levanta toda la topología en local.

La topología de referencia de Docker Compose

La única pieza que merece la pena mostrar inline es el cableado canónico de LangGraph. Es el ejemplo concreto más pequeño de la primitiva checkpoint:

from langgraph.checkpoint.postgres import PostgresSaver

DB_URI = "postgresql://agent:${POSTGRES_PASSWORD}@postgres:5432/agent"
with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates tables on first run
    graph = builder.compile(checkpointer=checkpointer)

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 agentes de larga duración no tienen ese lujo. Cuando una ejecución de seis horas falla, el evento interesante ocurrió hace cinco horas, la salida del terminal en vivo ha desaparecido y el worker que la produjo ya ha sido reemplazado. Nadie va a reconstruir la ejecución de memoria. Así que depuras a partir de artefactos duraderos que se escribieron mientras la ejecución seguía viva.

Los stacks de producción suelen cubrir cuatro tipos de artefacto, en dos grupos. Dos de ellos se leen después de que termine la ejecución, para postmortems y replay: un log de eventos consultable de cada paso y trazas OpenTelemetry de dónde se fueron el tiempo y los tokens. Otros dos se leen durante la ejecución, para observarla mientras sucede: un tail en vivo de lo que el agente está produciendo en el workspace y un stack de observabilidad por worktree que el propio agente puede consultar mientras sigue ejecutándose.

Log de eventos estructurado (lectura tras la ejecución)

Cada model call, tool call, resultado, error y aprobación escritos en almacenamiento duradero, indexados por ID de sesión y marca temporal. Una vez termina la ejecución, lo consultas como una tabla normal de base de datos. Addy Osmani fija el listón claramente en Long-running Agents: "If you can't reconstruct what the agent did in the last 24 hours from durable storage, what you have is a long-running shell script that happens to call an LLM, not a long-running agent."

Trazas OpenTelemetry GenAI (lectura tras la ejecución)

El mismo tipo de datos paso a paso, pero emitidos como spans usando los atributos estándar de las convenciones semánticas gen_ai.*: nombre del modelo, proveedor, número de tokens de entrada y salida, ID de conversación, nombre del workflow (estado de desarrollo a fecha de v1.36.0). Los campos específicos del proveedor viven en subespacios de nombres (anthropic.*, openai.*) indexados por gen_ai.provider.name. La razón para usar el estándar es la portabilidad: la misma traza se renderiza limpiamente en Tempo, Jaeger, Honeycomb o LangSmith sin tener que reinstrumentar el código cada vez que cambias de backend.

Línea temporal de tool calls más diffs del workspace (lectura durante la ejecución)

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

Stack efímero por worktree (leído por el propio agente, durante la ejecución)

Según la entrada de OpenAI sobre harnesses: "Logs, metrics, and traces are exposed to Codex via a local observability stack that's ephemeral for any given worktree." Cada worktree del agente obtiene su propio Loki + Prometheus + Tempo de corta duración, acotado a esa ejecución y a ninguna otra. El agente lo consulta mientras trabaja. Eso es lo que permite que un prompt como «ningún span de estos cuatro user journeys supera los dos segundos» se convierta en algo que el agente puede verificar directamente, en vez de algo que tenga que suponer.

(El evaluador con contexto limpio de la tabla de modos de fallo lee estos artefactos para decidir "done". Pertenece a la evaluación, no a la observabilidad; véase § ciclo de vida de una ejecución saludable. 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 procesador GenAI y un filtro de atributos sobre gen_ai.*.
  2. Tempo (o Jaeger) para trazas, indexadas por gen_ai.conversation.id / thread_id.
  3. Loki para entradas estructuradas del event log.
  4. Prometheus para gen_ai.client.token.usage, gen_ai.client.operation.duration, gen_ai.server.time_to_first_token (véanse las convenciones de métricas GenAI).
  5. Grafana con dashboards indexados por gen_ai.agent.name y gen_ai.request.model.

Alternativas alojadas (elige una, no tres):

  • LangSmith: integración nativa con LangGraph; también es el destino de despliegue para Deep Agents Deploy.
  • Braintrust: mejor encaje si la prioridad son los regression suites orientados a eval-first.
  • Arize Phoenix: OSS, nativo OTLP, combina bien con la instrumentación de OpenInference.
  • Dashboard de trazas de OpenAI: automático cuando usas OpenAI Agents SDK o su integración con Temporal.
  • Claude tracing de Anthropic: para sesiones que se ejecutan dentro de Managed Agents.

Instrumenta el nodo de LangGraph

# 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", "claude-sonnet-4-5")
span.set_attribute("gen_ai.response.model", "claude-sonnet-4-5")
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 de verdad necesitas

# 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 una ejecución falla, el worker debería dejar un /workspaces/${THREAD_ID}/_debug/ con los artefactos que pedirías en un postmortem:

  • session.jsonl: volcado completo del event log desde PostgresSaver (checkpointer.list({"thread_id": ...})).
  • last_state.json: StateSnapshot.values del último super-step correcto.
  • trace.json: spans exportados por 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 contra el commit del inicializador.
  • screenshots/*.png: lo que vio el agente.
  • PROGRESS.md, feature-list.json y cualquier otro archivo de progreso escrito por el agente.
  • env.txt: image tags, versión del modelo, commit SHA del harness.

Este bundle es lo que necesita un humano (u otro agente) para averiguar qué ocurrió. Sin él, cada ejecución fallida es una conjetura. «El agente se quedó atascado» es vago. Un informe de fallo útil se parece más a esto: la sesión s_123 gastó el 71 por ciento de los tokens en un bucle de reintento de tres comandos después de que fallara npm install.

Elegir la forma adecuada: guía de decisión

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

Empieza por la duración de la ejecución

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

  • Menos de 30 segundos, idempotente: SDK con ciclo de vida de petición en un app server.
  • 30 s a 60 min, sin necesidad de recuperación tras crash: queue + worker + checkpoint DB.
  • 60 min a 24 h: la misma queue + worker, o un Cloud Run Job para trabajo one-shot. Usa un motor de workflow duradero si además necesitas versionado y replay.
  • Más de 24 h, debe sobrevivir a despliegues: motor de workflow duradero (estilo Temporal). Cloud Run Jobs puede sostener trabajo largo hasta su límite por tarea, pero no aporta semántica de replay.
  • Bucles de entrenamiento RL de varios días: K8s Job + volumen + Temporal.

Una vez decidida la duración de ejecución, el resto es elección de plataforma.

Encaje de plataforma por caso de uso

Encaje de plataforma por caso de uso

La matriz es densa a propósito: once formas frente a muchos tipos de carga en una sola vista. Dos patrones explican casi cualquier lectura de ella.

Deep Agents Deploy es la única columna con verde en todas las filas. Eso significa que es la única forma de la lista que encaja con todos los tipos de carga que sigue la matriz: ejecuciones cortas, ejecuciones de varias horas, agentes de código, agentes de investigación y jobs programados. Esa amplitud es el argumento más fuerte a favor de elegirla. La contrapartida es la madurez. El harness salió hace poco y hay menos recorrido en producción alrededor de él que en alternativas más antiguas, como un stack de queue + worker + Postgres que los equipos llevan años ejecutando. Si la restricción que más te importa es «encaja con cualquier tipo de carga sin replatforming», acepta la menor madurez y elige Deep Agents Deploy. En caso contrario, prioriza la forma que ya operas.

Anthropic Managed Agents o encaja por completo con tu carga o no encaja en absoluto. El producto tiene tres restricciones duras: solo alojado, solo Claude y menos de 24 horas por sesión. Si tu carga cumple las tres, por ejemplo un agente interno de código que corre en ráfagas de 2–6 horas y prefieres no operar tú mismo el harness, Managed Agents encaja bien y elimina una gran parte del trabajo de plataforma de tu equipo. Si falla una sola restricción porque necesitas un modelo que no sea Claude, cumplimiento self-hosted o ejecuciones de 48 horas, Managed Agents no encaja. Ningún ajuste de configuración cambia eso.

Merece la pena modelar el precio antes de comprometerse, no después. La línea de coste por hora de sesión es 0,08 $/hora además de los costes estándar por token. Si una sola sesión se ejecutara de forma continua, eso serían unos 58 $/mes por sesión. Con 100 sesiones ejecutándose de forma continua, serían unos 5.800 $/mes antes de contar tokens. Multiplica 0,08 $ por tus horas previstas de sesiones concurrentes, súmalo a tu factura de tokens y compáralo con lo que costaría un stack de queue + worker en tu propia infraestructura. Hazlo antes de comprometerte, porque salir de Managed Agents más adelante es un ejercicio de replatforming, no un cambio de configuración.

Harness alojado frente a harness propio

La distinción aquí es operativa, no de quién escribió el código del harness. Alojado significa que el proveedor ejecuta el bucle del harness en su infraestructura y tú llamas a una API. Propio significa que ejecutas el bucle en tu propia infraestructura, aunque el código del harness venga de un proveedor.

LangChain aparece en ambos lados de esta línea, y eso confunde a la gente. Distribuyen LangGraph, una librería con licencia MIT que puedes alojar tú mismo (propio), y Deep Agents Deploy, un producto gestionado que ejecuta un harness de Deep Agents sobre LangSmith Deployment en su modo cloud por defecto (alojado). Misma empresa, dos modelos operativos distintos. Tú eliges el modelo, no el proveedor. (Deep Agents Deploy también tiene modo self-hosted para equipos que quieren la ergonomía del harness sin el componente cloud; ese modo cae en la categoría de propio).

Elige un harness alojado cuando no tengas capacidad de plataforma y las restricciones del proveedor encajen. Managed Agents significa solo Claude. Deep Agents Deploy en modo cloud significa LangSmith en producción. A cambio, el proveedor se ocupa de caching y compaction.

Un harness propio (LangGraph, Deep Agents Deploy en modo self-hosted o un harness custom sobre un SDK) es la decisión correcta cuando tienes platform engineers, cuando necesitas iterar sobre la forma del harness más rápido de lo que un proveedor va a publicar actualizaciones, cuando el cumplimiento exige que la residencia de los datos quede bajo tu control o cuando el routing multi-modelo entre proveedores no es negociable. Lo pagas en guardias y superficie operativa.

La mayoría de equipos deberían empezar con una opción alojada, medir qué necesitan cambiar y migrar a una opción propia solo cuando las restricciones de la alojada empiecen a doler.

Sandbox alojado frente a sandbox Docker / Fargate

Elige un sandbox alojado cuando importe el tiempo de creación del sandbox (menos de 200 ms), necesites pause/resume de sesión con estado de memoria o necesites semántica de fork/branch. Elige Docker o Fargate cuando ya pagues ese cómputo, necesites acceso interno en la VPC a fuentes de datos sensibles o tengas requisitos duros de residencia de datos.

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

Los agentes de larga duración suelen tener tres almacenes de estado funcionando al mismo tiempo, no uno solo, y cada uno guarda un tipo distinto de estado. Git guarda el estado del workspace: el código, los documentos y los archivos de progreso que el agente está cambiando. Cada commit da al harness un punto de recuperación estable y da a la siguiente sesión un historial compacto que inspeccionar. La checkpoint DB guarda el estado del grafo del harness: qué se decidió, qué nodos se ejecutaron, qué resultados llegaron y qué debe ejecutarse después. Eso es lo que permite al siguiente worker reanudar a mitad de ejecución. El artifact store guarda las salidas finales grandes, como PDFs, archivos parquet y capturas. Eso no pertenece ni a git ni a la checkpoint DB.

Cuándo usar git como estado

Usa git cuando la carga tenga forma de código (ediciones multifichero, refactors, generación de aplicaciones) o forma de documento hasta el punto de que importe el historial de archivos. El patrón es simple: crea una rama de ejecución, haz un commit inicializador y luego haz commits en límites significativos: tras el setup, tras cada funcionalidad, tras pasar tests, tras la limpieza final. Guarda el último commit SHA 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 luego lee PROGRESS.md o cualquier archivo de handoff que escribiera la sesión anterior.

Eso convierte a 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é cambió y qué versión pasó los tests. No puede decirle al harness qué nodo del grafo debe ejecutarse después, qué tool call está pendiente de aprobación o qué reintento ya consumió su clave de idempotencia. El harness de Anthropic usa commits inicializadores más commits por funcionalidad como fuente de verdad para recuperar el workspace; el modelo lee git log --oneline -8 para recuperar estado. Omite git cuando el producto del trabajo es una única respuesta conversacional. La sobrecarga no compensa.

Cuándo usar checkpointing en DB

Usa checkpointing estilo PostgresSaver cuando el agente tenga una estructura de grafo con varios nodos cuyo estado intermedio importe (planner → researcher → writer → verifier). El repo de referencia lo usa exactamente por esa razón. No metas artefactos del workspace a escala de terabytes en el checkpoint; eso va a object storage.

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

Recurre a object storage en tres situaciones. Primero, la salida es mayor de unos pocos cientos de KB. Las checkpoint DB no están hechas para guardar blobs grandes, y tratar de mantenerlos ahí hace dolorosos tanto la DB como el formato del checkpoint. Segundo, consumidores downstream como herramientas BI, clientes u otros servicios necesitan artefactos direccionables por URL que puedan descargar por sí mismos sin pasar por el agente. Tercero, la ventana de retención del estado de la ejecución y la ventana de retención del entregable divergen. Puede que borres el session log después de 30 días pero conserves el informe final durante años. Clavea la estructura por (thread_id, checkpoint_id, artifact_name) para que siempre puedas reconstruir qué ejecución produjo qué artefacto.

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

Añade puertas cuando la tool call sea destructiva e irreversible (escrituras en DB, movimiento de dinero, envío de comunicaciones externas), cuando la tool call salga del radio de explosión del agente (despliegues en producción, publicaciones de cara al cliente) o cuando los reguladores exijan revisión. El interrupt() de LangGraph y el middleware de aprobación de Deep Agents tienen soporte integrado para estas puertas. La Parte 4 ya cubrió por qué estas puertas son un problema de permisos, no de prompts.

Una checklist práctica para producción

Antes de poner en producción un agente de larga duración, responde estas preguntas en términos concretos de infraestructura.

  1. ¿Qué almacén es dueño de los eventos de sesión y los checkpoints?
  2. ¿Qué ocurre si el worker muere a mitad de una 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 en bruto?
  6. ¿Qué tool calls pueden reintentarse con seguridad?
  7. ¿Dónde se aplica el límite de coste por ejecución?
  8. ¿Qué comprobación con contexto limpio decide "done"?
  9. ¿Dónde viven las salidas finales cuando el sandbox ya no existe?
  10. ¿Podemos explicar mañana una ejecución fallida sin volver a ejecutarla?

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

Ideas clave

  1. Los agentes de larga duración necesitan un runtime, no solo un timeout HTTP más grande. El runtime mantiene la sesión, el workspace, los resultados de herramientas, los checkpoints, las trazas, los presupuestos, las aprobaciones y las credenciales fuera de la memoria del modelo.
  2. Los componentes principales son session, harness, sandbox, checkpoint y trace. Las comprobaciones de política y el broker de secretos atraviesan todos ellos.
  3. La primera pregunta de despliegue es la duración de la ejecución. Un helper de 20 segundos puede vivir en un app server. Una ejecución de código o investigación de seis horas necesita una queue, un worker, estado duradero y una estrategia de sandbox.
  4. Queue + worker + checkpoint DB es la opción práctica por defecto cuando quieres controlar el runtime. Los harnesses alojados como Anthropic Managed Agents o Deep Agents Deploy son mejores cuando encajan sus restricciones de proveedor y no quieres operar tú mismo el bucle.
  5. Las herramientas con efectos laterales necesitan claves de idempotencia. En queues y motores de workflow, los reintentos son normales. Sin deduplicación, un reintento puede enviar el mismo email, crear la misma PR o cobrar al mismo cliente dos veces.
  6. La observabilidad tiene que sobrevivir al worker. Para una ejecución fallida de seis horas, los artefactos útiles son el event log, el último checkpoint, la traza, la línea temporal de tool calls, el diff del workspace, las capturas y la metadata del entorno.
  7. Las suposiciones del runtime envejecen a medida que cambian los modelos. Vuelve a probar los resets de contexto, los patrones de evaluador, las superficies de herramientas y las reglas de presupuesto cuando cambies de modelo o de harness.
  8. Los secretos deben quedarse fuera del harness y fuera del contexto del modelo. El agente obtiene capacidades de herramientas, no credenciales en bruto.

Referencias

Análisis de ingeniería

LangGraph y Deep Agents

OpenAI Agents SDK

Temporal

Plataforma Anthropic

Proveedores de sandbox

Timeouts y cuotas de plataformas cloud

Observabilidad

Serie

El código de Market Analyst Agent (worker de LangGraph, checkpointer de Postgres, memoria Qdrant, sidecar MCP y la topología Docker Compose descrita arriba) está en GitHub.