Ir para o conteúdo

Tradução automática

Este artigo foi traduzido automaticamente a partir da versão original em inglês.

Runtime de Agentes de IA de Longa Duração em 2026: Sessões, Sandboxes, Checkpoints e Harnesses

Parte 5 da série Engineering the Agentic Stack

Os quatro artigos anteriores abordaram o interior do agente: loops de raciocínio, arquitetura de memória, uso de ferramentas, segurança. Este trata do exterior: o runtime de produção à volta de agentes de IA de longa duração.

Em 2026, os agentes de IA em produção deixaram de ser request handlers e passaram a ser background workers. Uma execução pode durar algumas horas. O worker que a aloja pode não durar isso. A engenharia interessante saiu do agente e passou para o runtime à sua volta. O modelo escolhe o próximo passo. O runtime decide o que acontece a esse passo quando o worker morre a meio de uma chamada.

TL;DR: Agentes de IA de longa duração precisam de um runtime fora do modelo: logs de sessão, lógica de harness, isolamento por sandbox, checkpoints, traces, verificações de política, segredos e limites de custo. Queue + worker + checkpoint DB é o padrão por omissão quando controlas a stack; hosted harnesses encaixam quando as restrições do fornecedor são aceitáveis. Escolhe primeiro pela duração da execução, depois pela semântica de recuperação, necessidades de replay, isolamento por sandbox e responsabilidade operacional.

É um artigo longo. Eis o que vais encontrar:

A primeira metade percorre as cinco primitivas de runtime e os modos de falha que cada uma existe para tratar. A segunda metade compara onze formas de deployment — SDK-in-an-app-server, queue + worker, Temporal, Anthropic Managed Agents, Deep Agents Deploy, Cloud Run, Lambda, ECS, Kubernetes Job per session, mais duas — e termina com um guia de decisão para escolher uma.

O que muda quando sessões de agentes de longa duração ultrapassam processos

Há um ano, "fazer deploy de um agente" significava embrulhar um endpoint de chat num container e apontar-lhe um load balancer. O trabalho era indistinguível de qualquer outro serviço web Python. Isso deixou de ser verdade no momento em que os agentes começaram a correr durante horas em vez de segundos.

A equipa do OpenAI Codex quantificou a nova baseline no seu artigo 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)."

A equipa de engenharia da Anthropic formulou o problema estrutural com igual clareza em 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."

Leva esta frase a sério e toda a stack de runtime muda de forma. Três consequências decorrem de "sessões discretas sem memória partilhada", e cada uma força uma peça específica de infraestrutura para dentro do design.

Se as sessões são discretas, a sessão tem de viver fora do processo. O estado em memória desaparece no momento em que o worker termina, por isso a sessão tem de ser escrita para um durable store que o worker seguinte consiga ler. Se uma sessão puder retomar após um crash, o registo durável tem de conter tudo o que aconteceu até aí, não apenas a resposta final. Isso permite ao worker seguinte retomar no ponto certo em vez de repetir a execução desde o início. Se o modelo encher a sua context window antes de o trabalho acabar, algo tem de fazer checkpoint do progresso, desmontar a sessão atual e iniciar uma nova que carregue o checkpoint em vez de repetir todo o histórico. Na formulação da Anthropic, o harness torna-se "cattle": instâncias descartáveis, reiniciáveis, idênticas. O estado vive noutro sítio.

O modelo decide o que fazer a seguir. O runtime decide se o passo é permitido, onde é executado, como é registado e como a execução retoma após um crash. O resto deste artigo é sobre esse runtime.

As cinco primitivas de runtime de que todo o agente de IA de longa duração precisa

O artigo Scaling Managed Agents da Anthropic deu à indústria um vocabulário funcional, e grande parte do ecossistema convergiu para ele. Cinco componentes fazem a maior parte do trabalho de runtime. O harness faz avançar o agente passo a passo; a sessão regista o que ele fez; a sandbox é onde os comandos executam; o checkpoint é o que o worker seguinte lê ao retomar; o trace é o que lês dias depois quando precisas de perceber o que correu mal. Cada componente é substituível desde que a responsabilidade se mantenha intacta.

As cinco primitivas de runtime

Sessão. Um log append-only de tudo o que aconteceu: chamadas ao modelo, tool calls, resultados, erros, aprovações. Recovery é wake(sessionId) → getSession(id) → resume from last event. Em LangGraph isto é um thread_id mais um checkpointer Postgres (ver LangGraph persistence). O OpenAI Agents SDK inclui dez backends de sessão built-in, incluindo SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession e EncryptedSession (ver a documentação de Sessions).

Harness. O loop de orquestração. Chama o modelo, faz parsing de tool calls, executa-as, escreve os resultados de volta na sessão e aplica regras de retry. A Anthropic coloca-o sem rodeios:

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

A equipa do Codex da OpenAI chama a esta disciplina harness engineering: escrever software continua a exigir disciplina, mas agora uma parte maior vai para o scaffolding do que para o código em si. O CompiledStateGraph do LangGraph, o create_deep_agent do Deep Agents e o próprio Claude Code são todos harnesses neste sentido.

Sandbox. O ambiente de execução isolado onde os comandos realmente correm. A página de sandbox concepts do OpenAI Agents SDK traça a fronteira de forma clara:

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

As sandboxes diferem pela duração de vida e pelo que recordam entre execuções. A forma mais simples é fresh ephemeral: arranca uma para uma única tarefa, destrói-a quando a tarefa termina e paga o custo de cold start em cada execução. Sandboxes persistent paused mantêm-se vivas entre execuções num estado pausado; o filesystem e um snapshot de memória mantêm-se, por isso a retoma seguinte é sub-second em vez de exigir um boot completo. Snapshot or fork vai um passo mais longe: cada tarefa ramifica uma imagem copy-on-write a partir de uma parent que já tem dependências instaladas e caches aquecidas, para que o trabalho caro de setup aconteça uma vez e N tarefas partilhem a imagem base. Sandboxes per-worktree dão a cada tarefa o seu próprio workspace e a sua própria stack de observabilidade: logs, métricas e traces separados. Isso permite depurar a execução de um agente sem contaminar a de outro. Números concretos de cold start e persistência por fornecedor estão na tabela mais abaixo nesta secção.

Checkpoint. Estado retomável. O PostgresSaver do LangGraph escreve um StateSnapshot em cada fronteira de super-step, com escritas por tarefa para checkpoint_writes para que outputs de nodes bem-sucedidos não sejam recalculados quando um sibling falha. O snapshot é um dict serializável em JSON (v, ts, id, channel_values, channel_versions, versions_seen, pending_sends) documentado na página PyPI de langgraph-checkpoint-postgres e na referência de checkpoints do LangGraph.

Trace. A superfície de replay e debug. Cada model call, tool call e passo de sub-agent torna-se um span com timing, inputs, outputs, contagem de tokens e custo. Quando uma execução de seis horas falha, o trace é o que lês para perceber o que correu mal. O output de terminal da execução já desapareceu nessa altura. As GenAI semantic conventions do OpenTelemetry normalizam os nomes de atributos (que modelo, que provider, quantos tokens, que conversa, que workflow), para que o mesmo trace seja renderizado de forma limpa em Tempo, Jaeger, Honeycomb ou LangSmith sem voltar a instrumentar.

Política e segredos são fronteiras de runtime separadas

Duas fronteiras atravessam as cinco primitivas e é mais fácil pensá-las como preocupações separadas. São a versão de runtime do argumento de segurança da Parte 4.

Motor de políticas

Uma verificação de permissões corre antes de cada tool call e decide se ela avança. Dois padrões são comuns em produção. O Deep Agents permite que cada subagent declare que file paths pode ler ou escrever, e o middleware bloqueia qualquer coisa fora dessa declaração. O Anthropic Managed Agents encaminha cada tool call através de um proxy MCP, por isso o proxy aplica as permissões em vez do código do agente. Quando uma chamada sensível precisa de aprovação humana, o interrupt() do LangGraph e o approval hook do Deep Agents põem o graph em pausa até uma pessoa dizer que sim.

Secret broker

O modelo não deve ver segredos de longa duração, e normalmente a sandbox também não. O padrão de Managed Agents é o que vale a pena 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."

Na stack de referência market-analyst-agent, o sidecar MCP lê tokens OAuth de um Docker secret (em produção, HashiCorp Vault) e expõe apenas a superfície de tools ao worker LangGraph. O worker nunca vê o token. git push funciona. cat ~/.ssh/id_rsa não.

Uma verificação prática de sanidade para a tua própria stack: escreve todos os componentes que executas e que uma das cinco primitivas cada um implementa. Postgres pode cobrir sessão e checkpoint. O container do worker é o harness. Um serviço de hosted sandbox como Daytona, Modal ou E2B é a sandbox. Tempo ou LangSmith é o trace. Se descobrires que duas primitivas vivem no mesmo processo, um crash deita ambas abaixo. Se duas partilharem a mesma credencial, uma fuga compromete ambas. Ambas as situações são fáceis de introduzir por acidente quando se está a avançar depressa: um worker que também escreve traces, um token de sidecar que também desbloqueia a checkpoint DB.

Modos de falha do runtime de agentes de IA em produção

O runtime existe para as coisas que o modelo não consegue fazer sozinho: gerir retries, lembrar-se do que fez há três horas, isolar o filesystem de uma execução do de outra, parar antes de gastar o orçamento. A esta altura já nomeámos sete peças: harness, log de sessão, sandbox, checkpointer, tracer, motor de políticas, secret broker. Quando uma única execução de agente ultrapassa cerca de 30 minutos de wall time, começa a aparecer um conjunto reconhecível de falhas. A maior parte não tem nada a ver com qualidade de raciocínio; são problemas de estado, retries, sandboxes e orçamentos.

As falhas dividem-se em quatro grupos vagos:

  • Falhas de qualidade de output: o agente declara vitória antes de o trabalho estar realmente concluído, esquece-se do que fez após um reset da context window, ou confia na sua própria autoavaliação e entrega output com erros.
  • Falhas de controlo de custos: o agente fica preso num loop de retry, ou gasta um orçamento de tokens ou tool calls sem produzir nada de útil.
  • Falhas de estado e crash: workspaces divergem porque uma execução mexe em ficheiros que pertencem a outra, tool calls disparam mais de uma vez porque retries as repetem, ou perde-se trabalho quando um worker morre entre eventos.
  • Falhas de context window: o modelo resume e termina cedo porque pensa que está a ficar sem espaço, mesmo quando ainda existe margem na janela.

A tabela abaixo mapeia cada falha para o padrão de mitigação, o hook de runtime onde a mitigação vive, e se a mitigação continua a ser necessária na geração atual de modelos. Algumas já não são necessárias. Quanto mais antigo for o teu harness, mais mitigações obsoletas provavelmente contém.

Modos de falha e as suas mitigações

Failure mode Mitigation Still needed? Runtime hook
Premature completion: agent declares victory early Separação generator/evaluator: um evaluator com contexto limpo lê ficheiros (não o chat) e vota "done" ou "not done". FAIL por omissão em cada verificação de aceitação. Sim; o quick-start cwc-long-running-agents da própria Anthropic continua a incluir um subagent evaluator. Sub-agent sem tools Write/Edit e com a sua própria context window
Feature amnesia across context windows O agent initializer escreve claude-progress.txt, feature-list.json, init.sh. O coding agent lê-os em cada cold boot. Sim; a compactação, por si só, não fecha a lacuna. Boot hook antes da primeira model call de cada sessão
Duplicated work after session reset Log de eventos append-only mais um ficheiro de handoff estruturado. Cada nova sessão começa com pwd → read PROGRESS.md → review tests. Sim Checkpoint PostgresSaver do LangGraph mais artefacto progress.md
Context anxiety: model summarises and quits early (a) Ativar a beta de 1M tokens mas limitar a utilização efetiva a 200k (fix do Sonnet 4.5 da Cognition). (b) Desmontar a sessão e reconstruir a partir de um handoff. Não no Opus 4.5; a Anthropic refere que "the behavior was gone" e que os resets "had become dead weight." Sim no Sonnet 4.5 e GPT-5/Codex. O driver exterior limita o comprimento da sessão, inicia a seguinte e retoma a partir do checkpoint
Self-evaluation optimism: model marks its work passing Evaluator separado mais grounding com Playwright/MCP no DOM real, não em screenshots. O harness design da Anthropic para frontend penaliza defaults de "AI-style". Sim O evaluator corre numa sessão de sandbox separada sem tools de escrita
Stuck loops and retry storms Limite de iterações por turno, exponential backoff, circuit breaker com base na taxa de erro de tools. Orçamento rígido para tool calls. Sim Decorator no node de execução de tools; RetryPolicy em Temporal Activities (ver Temporal OpenAI Agents SDK contrib)
Workspace drift: agent edits unrelated files Commits Git como checkpoints, middleware de permissões de ficheiros, montagem de workspace por sessão. O middleware do Deep Agents permite declarar read/write por path. Sim Middleware de permissões de ficheiros do LangGraph ou fork por tarefa em Daytona/Runloop
Runaway token or tool cost Orçamento de tokens por execução, orçamento por tool, kill switch ligado a um contador Prometheus. Sim; uma sessão Opus de 24 horas com mau budget pode gastar o orçamento semanal de API numa tarde (Addy Osmani sobre long-running agents). Atributos de span de atribuição de custo mais regra Alertmanager
Non-idempotent tool calls Idempotency key por tool call. Em durable workflows, retries podem disparar a mesma tool call mais do que uma vez, por isso uma chave de deduplicação bloqueia o duplicado. Sim Temporal Activity com start_to_close_timeout e idempotency key
Lost work after process or sandbox crash Log de sessão durável fora do processo; checkpoint após cada super-step. wake(sessionId) → getSession(id) → resume. Sim PostgresSaver em cada super-step, ou embrulhar como um Temporal Workflow

Duas ideias aparecem em todas as linhas. Anthropic, sobre harnesses desatualizados em 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 o problema relacionado de demasiadas tools codificarem demasiadas suposições, em 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."

O resultado reportado pela Vercel numa query representativa: a taxa de sucesso passou de 80% para 100%, e o pior caso caiu de 724 s / 100 passos / 145,463 tokens (falhou) para 141 s / 19 passos / 67,483 tokens (sucesso). A lição não é "apaga as tuas tools". É que cada primitiva do teu runtime, incluindo a superfície de tools, tem um prazo de validade. Volta a testar a suposição quando o modelo muda.

A Cognition viu o mesmo alvo móvel na duração das sessões com Sonnet 4.5. Em Rebuilding Devin for Claude Sonnet 4.5, descrevem um modelo que escreve proativamente SUMMARY.md / CHANGELOG.md ao detetar exaustão de contexto, mas subestima quantos tokens ainda lhe restam. A correção deles é ativar a beta de 1M tokens e limitar o uso a 200k para que o modelo continue a acreditar que tem margem. Essa mitigação também acabará por se tornar peso morto.

A equipa de harness da OpenAI tem a versão de uma linha desta disciplina: "Humans steer. Agents execute." Quando algo falha, a pergunta não é "tenta com mais força". É "que capacidade está em falta, e como a tornamos simultaneamente legível e aplicável para o agente?"

O ciclo de vida de uma execução saudável

Uma execução bem comportada é aborrecida. É uma cadeia de pequenos passos recuperáveis, cada um a escrever o seu resultado para armazenamento durável antes de o seguinte começar, em vez de um pedido gigante que tem de ter sucesso ponta a ponta. Dividir uma execução em passos dessa forma é o que lhe permite sobreviver a crashes: quando algo falha, só se perde o passo que estava em voo, e o worker seguinte retoma a partir do último passo concluído em vez de recomeçar.

O ciclo de vida de uma execução de agente em produção

  1. Arrancar a partir de uma sessão nova ou de uma retomada. Na retoma, montar o workspace no seu último estado conhecido, ler quaisquer ficheiros de progresso deixados pela tentativa anterior (PROGRESS.md, feature-list.json), e carregar o último checkpoint da base de dados. É aqui que o harness entrega ao agente tudo o que o worker anterior tinha em memória antes de morrer.
  2. Planear antes de qualquer tool call disparar. Registar o aspeto de "done", quanto a execução pode gastar, que tools o agente pode invocar e o que deve fazer a execução parar mais cedo. Estes valores do plano tornam-se verificações de runtime; sem eles, a execução não tem nada que a contrarie.
  3. Executar uma tool call de cada vez. A camada de políticas decide se a chamada é permitida. O harness corre-a, captura o resultado e escreve um evento no log de sessão. Um passo, um evento. Um crash entre eventos é recuperável porque o log, e não a memória do worker, é a source of truth.
  4. Fazer checkpoint nas fronteiras de super-step, ou após cada evento num harness mais simples. Persistir o estado do graph, o diff do workspace e referências a quaisquer artefactos produzidos. É este checkpoint que o passo 1 lê na próxima retoma. Se o checkpoint faltar ou estiver desatualizado, a recuperação degrada-se para replay completo do log de sessão desde o início, o que é muito mais lento.
  5. Avaliar face aos artefactos quando o agente pensa que terminou: testes, revisor com contexto limpo, validação de schema, browser checks. Se a verificação passar, a execução termina com sucesso. Se falhar, a execução retoma a partir do último checkpoint limpo com a mensagem de falha adicionada ao contexto e tenta novamente.

Não há nenhum passo nessa lista que exija que o agente se lembre de alguma coisa entre execuções. O estado vive na sessão e no checkpoint, e o agente volta a lê-lo em cada retoma.

Tools com side effects precisam de idempotência. Qualquer tool com side effects precisa de uma idempotency key derivada do ID da sessão e do ID da tool call, armazenada antes de o side effect disparar. 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). A execução at-least-once é o padrão em queues e workflow engines. Se repetir uma tool call puder causar dano real, a tool não está pronta para agentes.

A avaliação tem de correr fora do contexto produtor. O mesmo contexto que produziu a resposta não consegue julgar com fiabilidade se a resposta está correta. Um evaluator novo lê ficheiros e artefactos, executa testes, lints, browser checks ou validação de schema, e devolve pass, fail ou needs_human. Para code agents, isto é outra sessão de modelo com tools read-only. Para data agents e report agents, é um validador determinístico mais um modelo revisor.

Onze padrões de deployment de agentes de IA e o que decide entre eles

Depois de nomeadas as cinco primitivas, a pergunta passa a ser que forma de deployment as executa. Por "forma" quero dizer uma disposição dessas primitivas: onde vive o harness, onde o estado persiste e que tipo de sandbox executa o trabalho. Não é apenas uma escolha de fornecedor. O gráfico abaixo mostra onde cada forma é confortável no eixo da duração da execução. O texto a seguir explica o que decide entre elas.

Se só leres uma das onze, lê a forma 2: queue + worker + checkpoint DB. É a predefinição que recomendo para a maioria das equipas, a forma usada pelo repositório de referência e o esqueleto sobre o qual a maior parte das outras varia: queue → worker → durable state, trocando a origem da sandbox, o dono do harness ou o motor de estado. Ler primeiro a forma 2 torna o resto mais rápido de percorrer.

Formas de deployment e os seus sweet spots por duração de execução

O gráfico compara formas pela duração da execução. A matriz abaixo compara-as por ownership: onde vive fisicamente cada uma das cinco primitivas. As células verdes são onde a forma fornece a primitiva; as cinzentas são onde a ligas tu próprio.

Onde vive cada primitiva em cada forma de deployment

1. SDK dentro de um app server (síncrono, com âmbito de request)

A forma original. O SDK do agente corre dentro de um request handler. Boa para tarefas abaixo de 30 segundos, demos e ferramentas internas. Má para qualquer coisa de que um cliente HTTP se possa desligar. O timeout HTTP do Cloud Run vai até 60 minutos, e qualquer panic na web tier mata a execução. O SDK é o harness, o processo web também funciona como sandbox, e o estado costuma viver em memória de processo a menos que o empurres explicitamente para outro lado. Não uses isto para trabalho de várias horas.

2. Queue + worker + checkpoint DB

A predefinição que recomendo para a maioria das equipas, e a forma de produção usada em market-analyst-agent: um worker Python com checkpointer PostgreSQL, Redis Streams (ou RabbitMQ) para a queue de entrada, e um sidecar MCP para tools. Boa para execuções de 10 minutos a várias horas com passos idempotentes. O runner local pode contornar a queue para desenvolvimento síncrono, mas a queue faz parte da forma de produção assim que precisas de submissão assíncrona e backpressure.

A aplicação aceita um pedido, cria uma linha de sessão, coloca um job na queue e devolve um ID de execução. O worker vai buscar o job, corre o harness, escreve checkpoints, faz streaming de estado e guarda artefactos enquanto avança. O Postgres sobrevive, os workers são cattle, e a profundidade da queue dá-te backpressure. Compute Spot/Preemptible funciona desde que o checkpointer termine de escrever para disco antes de reportar sucesso.

Nesta forma, o worker é o harness. O container do worker mais uma montagem de workspace por thread são a sandbox. O Postgres é dono do estado de sessão e checkpoint. Os traces seguem via OpenTelemetry para a stack de observabilidade que estiveres a usar.

3. Durable workflow engine (estilo Temporal)

O código de orquestração do agente corre dentro de um Temporal Workflow; model calls e tool calls correm como Activities. O estado do workflow vive num log de histórico de eventos suportado por Cassandra, MySQL ou Postgres, por isso o estado faz replay de forma limpa entre deploys. A integração em public preview Temporal × OpenAI Agents SDK inclui um helper OpenAIAgentsPlugin e um helper activity_as_tool, e o artigo sobre agentic sandboxes descreve fazer fork de um agente em execução para outro fornecedor de sandbox a meio de uma conversa. Workflows em idle não consomem compute. As limitações são reais: agentes de streaming e voz não são suportados na integração atual, e LocalShellTool e ComputerTool estão desativados porque não se ajustam a um modelo distribuído.

Usa esta forma quando a execução tem pontos reais de espera: aprovações humanas, callbacks externos, sleeps longos, retries com regras de negócio, janelas de deploy. Uma aprovação humana torna-se um sleep durável que não consome compute, não um loop de polling.

O código do Workflow é o harness. A sandbox normalmente vive fora do Temporal e é chamada a partir de Activities. O estado de sessão e checkpoint colapsa no log de histórico de eventos do Temporal, enquanto a visibilidade de traces vem da UI do Temporal mais spans OpenTelemetry em cada Activity.

4. Sandbox provider por sessão

Uma forma mais recente. Cada execução de agente recebe a sua própria microVM ou container de um fornecedor de sandbox-as-a-service. O harness vive algures de forma durável; a sandbox é o ambiente de execução descartável.

Provider Isolation Max session Concurrency Persistence Cold start
E2B Firecracker microVM 1 h Hobby / 24 h Pro 20 / 100 (up to 1,100 add-on) Pause/resume, ~4 s/GiB pause, ~1 s resume (public beta) ~150 ms p50
Vercel Sandbox Firecracker microVM 45 min Hobby / 5 h Pro/Ent 10 / 2,000 Disposable n/a
Daytona Docker (optional Kata) auto-stop/archive configurável por tier Stop → Archive → Delete; fork suportado ~90 ms (algumas configs 27 ms)
Modal Sandboxes gVisor ciclo de vida típico 1–15 min alta Volumes para persistência; snapshot de memória em preview "about one second" segundo a documentação da Modal
Runloop Devboxes microVM (custom hypervisor) suspend/resume; snapshot+branch "more than 30,000 concurrent instances" segundo a listagem na AWS Marketplace Snapshot + branch a partir de estado em disco sub-1 s

Fontes: a comparação E2B vs Daytona, a própria documentação de sandboxes da Daytona e o changelog de fork/snapshot, o guia de sandboxes e o guia de cold start da Modal, a listagem Runloop na AWS Marketplace e os preços do Vercel Sandbox. A documentação da Daytona acrescenta uma nota útil sobre a semântica de fork: "the new sandbox is fully independent … Daytona tracks the parent-child relationship in a fork tree." Cada sandbox derivada mantém um link registado para a base de que ramificou, para que possas consultar a linhagem de qualquer sandbox derivada. O harness do Codex da OpenAI usa a 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."

Opta por esta forma quando o agente executa código não confiável, browser automation, testes ou instalações de pacotes. O trade-off é custo e acoplamento ao fornecedor, ambos mais elevados do que correr workers partilhados.

O fornecedor é dono apenas da sandbox. Harness, sessão, checkpoint e trace ficam do teu lado, normalmente ligados como a forma queue + worker do ponto #2.

5. Anthropic Managed Agents (hosted harness)

Lançado em public beta em 8 de abril de 2026, atrás do beta header managed-agents-2026-04-01. O Claude cobra pelos Managed Agents às taxas normais de tokens mais $0.08 por session-hour. A faturação é granular ao milissegundo e aplica-se apenas enquanto o estado da sessão for "running". Idle é gratuito; o runtime da sessão "replaces the Code Execution container-hour billing model when using Claude Managed Agents." Recebes uma sessão alojada, harness, sandbox e proxy MCP suportado por vault. A separação brain/hands é o que wake(sessionId) está a comprar: o harness pode ser reinicializado num novo worker sem perder estado. Vigia bem a forma do custo; um loop de retry fora de controlo numa fatura por session-hour acumula mais depressa do que numa por token.

Lê as limitações. O desconto da Batch API não se aplica ("Sessions are stateful and interactive. There is no batch mode."). Managed Agents não está disponível através de AWS Bedrock nem Google Vertex AI. Coordenação multi-agent e autoavaliação continuam em research preview. O lock-in é elevado: trocas liberdade de harness por não correres tu próprio o loop.

A Anthropic aloja as cinco primitivas: sessão, harness, sandbox, checkpoint e trace. Entregas o runtime e recebes os outputs.

6. LangChain Deep Agents Deploy (managed open harness)

deepagents deploy empacota um deepagents.toml numa LangSmith Deployment com durable execution, memória, multi-tenancy, human-in-the-loop, observabilidade, execução de código em sandbox e scheduled runs. São suportados modos cloud, hybrid e self-hosted. Os sandbox providers (LangSmith Sandboxes, Daytona, Modal, Runloop ou custom) podem ser trocados com um único valor de configuração. O estado vive num virtual filesystem com backends pluggable; a memória é scoped por utilizador, assistant ou ambos. O lock-in é menor do que em Managed Agents: o harness tem licença MIT, as instruções usam o standard aberto AGENTS.md e os agentes são expostos via MCP, A2A e Agent Protocol. Ver o artigo da LangChain runtime-behind-production-deep-agents.

As cinco primitivas são alojadas por omissão, mas cada uma pode ser trocada por configuração. A sandbox está atrás de um único valor de configuração. Sessão e checkpoint vivem num virtual filesystem com backends pluggable. O trace vai para LangSmith.

7. Google Cloud Run service ou job

O Cloud Run tem dois modos de runtime diferentes, e o que encaixa depende de como o agente é invocado. Services estão presos a HTTP e escalam para zero entre requests; o harness corre como request handler que devolve quando a execução termina. Jobs correm até à conclusão sem entrypoint HTTP; o harness corre como one-shot worker que termina quando a tarefa acaba. Ambos podem alojar o harness, mas nenhum mantém estado entre execuções. Sessões e checkpoints têm de viver em Postgres, Spanner ou um external store semelhante.

Os limites rígidos são muito diferentes nos dois casos. Cloud Run service request timeout: 300 s por omissão, máximo 3,600 s (60 min). WebSockets têm o mesmo timeout. Cloud Run jobs: 10 min por omissão por tarefa, máximo 168 h (7 dias); para tarefas com GPUs, máximo 1 hora. Services escalam para zero a menos que atives CPU sempre ligada; jobs não têm HTTP nem autoscaling.

Usa um service para execuções síncronas até 60 minutos. Usa um job para trabalho assíncrono ou one-shot mais longo. Cloud Run Jobs podem manter uma tarefa viva durante dias, mas não te dão durable replay entre deploys, mudanças de versão ou substituição de worker. Acima de 7 dias, não uses Cloud Run.

Cloud Run aloja o harness. Sessão, checkpoint, sandbox e trace são serviços externos que ligas tu, tipicamente Postgres ou Spanner para sessão/checkpoint, o próprio container como sandbox, e Cloud Logging mais OpenTelemetry para trace.

8. AWS Lambda (porque é a ferramenta errada)

O timeout máximo de uma função Lambda é 900 s (15 minutos), fixo. O API Gateway acrescenta um limite separado de 29 s por cima disso. Um harness de agente cuja execução útil mínima é "minutos a horas" não sobrevive em Lambda sem um external state store e uma estratégia de re-invocation que essencialmente reconstrói a forma queue + worker desde o zero. Usa Lambda para tool calls individuais, como fetches de ficheiros ou uploads para S3, invocados por um orquestrador de maior duração. Não coloques lá o orquestrador.

No máximo, Lambda aloja uma tool call dentro do seu limite de 15 minutos. O harness, sessão, checkpoint, sandbox e trace têm todos de viver noutro sítio.

9. AWS ECS / Fargate task por execução

Sem limite rígido documentado para a duração da task (ao contrário de Lambda). Segundo as quotas de throttling do Fargate, os lançamentos têm rate limit: burst de 100, com reposição a 20 por segundo, com on-demand e spot acompanhados em orçamentos separados de 20/s. Quotas de serviço ECS: serviços com service discovery AWS Cloud Map ficam limitados a 1,000 tasks por serviço; o teto teórico é 5,000 instâncias EC2 por cluster. O Fargate exige modo awsvpc, por isso cada task recebe a sua própria interface de rede e um IP privado, que é a forma certa quando precisas de acesso a dados internos da VPC. O Fargate Spot está disponível; faz orçamento para interrupção. A durabilidade é tua responsabilidade: não há replay estilo Temporal built-in.

O Fargate aloja o harness e dá a cada execução a sua própria sandbox: uma task por execução. Sessão, checkpoint e trace vão para serviços externos. RDS ou DynamoDB mais CloudWatch/X-Ray são as escolhas habituais.

10. Kubernetes Job ou namespace por sessão

Bom quando já operas Kubernetes e queres sandbox por sessão com controlos à escala do cluster. Mau quando precisas de arranque sub-second, porque puxar a imagem do container e inicializar o pod demora demasiado num cold start. O padrão é um Job por execução de agente, com activeDeadlineSeconds, um PersistentVolumeClaim para o workspace e um sidecar para o servidor MCP. A recuperação de crash é tua para construir. Adotar Kubernetes apenas para alojar agentes é caro em overhead de configuração e carga operacional. Só compensa se já corres K8s por outras razões.

O K8s aloja o harness e a sandbox, normalmente como um Job por execução e por vezes com um namespace dedicado para isolamento mais forte. Sessão e checkpoint vivem numa DB externa ou num PersistentVolumeClaim. O trace flui para a stack de observabilidade in-cluster que já tiveres.

11. Docker Compose local (apenas dev)

A referência para a secção seguinte. O objetivo desta forma é espelhar a topologia de produção um-para-um (mesmas primitivas, mesma forma de rede) enquanto corre numa única máquina. Lê a lista "not production-safe" no fim da secção seguinte antes de fazeres shipping de algo que se pareça com isto.

O Compose espelha a forma #2 num único host. O Postgres guarda sessão e checkpoint. O container do worker é o harness. A montagem do workspace é a sandbox partilhada. A stack OpenTelemetry opcional é o trace.

Stack de referência: Docker Compose

A topologia de referência, usada em slavadubrov/market-analyst-agent, é um worker LangGraph, um checkpointer Postgres, Qdrant para retrieval, um sidecar MCP, uma queue Redis para execuções assíncronas semelhantes a produção, e uma stack de observabilidade opcional com Prometheus / Grafana / Loki / Tempo / OTel. Em compose local, o Redis é opcional apenas porque o runner síncrono pode chamar o worker diretamente. docker compose up levanta toda a topologia localmente.

A topologia Docker Compose de referência

A única peça que vale a pena mostrar inline é a ligação canónica do LangGraph. É o exemplo concreto mais pequeno da 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)

Observabilidade que sobrevive à execução

Request handlers curtos são fáceis de depurar: quando algo falha, lês a resposta e o log em tempo real. Agentes de longa duração não têm esse luxo. Quando uma execução de seis horas falha, o evento interessante aconteceu há cinco horas, o output do terminal em direto já desapareceu e o worker que o produziu foi substituído. Ninguém vai reconstruir a execução de memória. Por isso depuras a partir de artefactos duráveis escritos enquanto a execução ainda estava viva.

As stacks de produção tendem a cobrir quatro tipos de artefacto, em dois grupos. Dois deles lês depois de a execução terminar, para postmortems e replay: um log de eventos consultável de cada passo, e traces OpenTelemetry de onde o tempo e os tokens foram gastos. Dois deles lês durante a execução, para observar o que está a acontecer: um live tail do que o agente está a produzir no workspace, e uma stack de observabilidade por worktree que o próprio agente pode consultar enquanto ainda está a correr.

Log de eventos estruturado (lido após a execução)

Cada model call, tool call, resultado, erro e aprovação escritos para armazenamento durável, indexados por ID de sessão e timestamp. Depois de a execução terminar, consultas isto como uma tabela normal de base de dados. Addy Osmani coloca a fasquia de forma simples em 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."

Traces OpenTelemetry GenAI (lidos após a execução)

O mesmo tipo de dados passo a passo, mas emitidos como spans usando os atributos standard das semantic conventions gen_ai.*: nome do modelo, provider, contagem de tokens de input e output, ID da conversa, nome do workflow (estado de desenvolvimento na v1.36.0). Campos específicos de provider vivem em subnamespaces (anthropic.*, openai.*) indexados por gen_ai.provider.name. A razão para usar o standard é portabilidade: o mesmo trace é renderizado corretamente em Tempo, Jaeger, Honeycomb ou LangSmith sem re-instrumentar o código sempre que mudas de backend.

Timeline de tool calls mais diffs de workspace (lidos durante a execução)

A forma mais rápida de saber o que um agente está a fazer agora é fazer tail ao que está a produzir no workspace, não grepar num log de sessão. O quick-start Harness Primitives for Long-Running Claude Agents da Anthropic inclui dois hooks para isto: watch -n 5 'git log --oneline -8' mostra os commits mais recentes feitos pelo agente, e watch -n 5 'find screenshots -name "*.png" | tail -5' mostra os screenshots mais recentes que tirou. Dois painéis de terminal a atualizar de cinco em cinco segundos bastam para perceber se uma execução está realmente a progredir ou apenas a rodar em falso.

Stack efémera por worktree (lida pelo próprio agente, durante a execução)

Segundo o artigo da 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 de agente recebe o seu próprio Loki + Prometheus + Tempo de curta duração, isolado apenas àquela execução. O agente consulta-o enquanto trabalha. É isso que permite que um prompt como "no span in these four user journeys exceeds two seconds" se torne algo que o agente pode verificar diretamente, em vez de algo que tenha de adivinhar.

(O evaluator com contexto limpo da tabela de modos de falha lê estes artefactos para decidir "done". Pertence à avaliação, não à observabilidade; ver § ciclo de vida de uma execução saudável. Depende de todas as superfícies acima.)

Uma stack mínima de observabilidade self-hosted

Para algo como market-analyst-agent:

  1. OpenTelemetry Collector com o processador GenAI e um filtro de atributos em gen_ai.*.
  2. Tempo (ou Jaeger) para traces, indexados por gen_ai.conversation.id / thread_id.
  3. Loki para entradas estruturadas de log de eventos.
  4. Prometheus para gen_ai.client.token.usage, gen_ai.client.operation.duration, gen_ai.server.time_to_first_token (ver as GenAI metrics conventions).
  5. Grafana dashboards indexados por gen_ai.agent.name e gen_ai.request.model.

Alternativas hosted (escolhe uma, não três):

  • LangSmith: integração nativa com LangGraph; também é o target de deployment do Deep Agents Deploy.
  • Braintrust: melhor encaixe se a prioridade forem suites de regressão eval-first.
  • Arize Phoenix: OSS, OTLP-native, combina com instrumentação OpenInference.
  • Dashboard de tracing da OpenAI: automático quando usas o OpenAI Agents SDK ou a sua integração com Temporal.
  • Claude tracing da Anthropic: para sessões a correr dentro de Managed Agents.

Instrumentar o node do 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)

Nomes de atributos retirados literalmente do registo de semantic conventions GenAI do OpenTelemetry.

Três queries de que realmente precisas

# 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 }

O padrão debug bundle

Quando uma execução falha, o worker deve largar /workspaces/${THREAD_ID}/_debug/ com os artefactos que pedirias num postmortem:

  • session.jsonl: dump completo do event log a partir do PostgresSaver (checkpointer.list({"thread_id": ...})).
  • last_state.json: StateSnapshot.values do último super-step bem-sucedido.
  • trace.json: spans exportados em OTLP para a execução.
  • tool_calls.csv: (ts, tool, input_hash, latency_ms, status, error).
  • workspace.tar.zst: o diretório do workspace mais git diff face ao commit initializer.
  • screenshots/*.png: o que o agente viu.
  • PROGRESS.md, feature-list.json e quaisquer outros ficheiros de progresso escritos pelo agente.
  • env.txt: image tags, versão do modelo, harness commit SHA.

Este bundle é o que um humano (ou outro agente) precisa para perceber o que aconteceu. Sem ele, cada execução falhada é um palpite. "O agente ficou preso" é vago. Um relatório de falha útil parece-se mais com isto: a sessão s_123 gastou 71 por cento dos tokens num loop de retry de três comandos depois de npm install ter falhado.

Escolher a forma certa: um guia de decisão

A maior parte da comparação acima reduz-se a um pequeno conjunto de decisões.

Começa pela duração da execução

Usa a duração da execução como primeiro filtro:

  • Abaixo de 30 segundos, idempotente: SDK no ciclo de vida do request dentro de um app server.
  • 30 s a 60 min, sem necessidade de crash recovery: queue + worker + checkpoint DB.
  • 60 min a 24 h: a mesma queue + worker, ou um Cloud Run Job para trabalho one-shot. Usa um durable workflow engine se também precisares de versioning e replay.
  • Mais de 24 h, tem de sobreviver a deploys: durable workflow engine (estilo Temporal). Cloud Run Jobs conseguem manter trabalho longo até ao seu limite por tarefa, mas não fornecem semântica de replay.
  • Loops de treino RL multi-dia: K8s Job + volume + Temporal.

Depois de a duração da execução estar decidida, o resto é escolha de plataforma.

Encaixe de plataforma por caso de uso

Encaixe de plataforma por caso de uso

A matriz é densa de propósito: onze formas em muitos tipos de workload numa única vista. Dois padrões moldam quase todas as leituras da mesma.

O Deep Agents Deploy é a única coluna com verde em todas as linhas. Isso significa que é a única forma no conjunto que encaixa em todos os tipos de workload que a matriz acompanha: execuções curtas, execuções de várias horas, code agents, research agents, scheduled jobs. Essa amplitude é o argumento mais forte para a escolher. O trade-off é a maturidade. O harness foi lançado recentemente, e tem menos histórico em produção do que alternativas mais antigas como uma stack queue + worker + Postgres que equipas já operam há anos. Se a restrição mais importante para ti for "encaixa em todos os tipos de workload sem re-platforming", aceita a menor maturidade e escolhe Deep Agents Deploy. Caso contrário, prefere a forma que já operas.

Anthropic Managed Agents ou encaixa totalmente no teu workload, ou não encaixa de todo. O produto tem três restrições rígidas: é apenas hosted, apenas Claude, e abaixo de 24 horas por sessão. Se o teu workload cumprir as três, por exemplo um coding agent interno que corre em rajadas de 2-6 horas e preferes não operar tu próprio um harness, Managed Agents encaixa bem e remove uma grande parte do trabalho de plataforma da tua equipa. Se uma restrição falhar porque precisas de um modelo não-Claude, conformidade self-hosted, ou execuções de 48 horas, Managed Agents não serve. Nenhuma configuração muda isso.

Vale a pena modelar o preço antes de te comprometeres, não depois. A linha de session-hour custa $0.08/hora além dos custos normais de tokens. Se uma única sessão corresse continuamente, isso dá cerca de $58/mês por sessão. Com 100 sessões a correr continuamente, são cerca de $5,800/mês antes dos tokens. Multiplica $0.08 pelas horas esperadas de sessões concorrentes, soma à tua fatura de tokens e compara com o custo de uma stack queue + worker na tua própria infraestrutura. Faz isto antes de te comprometeres, porque migrar para fora de Managed Agents mais tarde é um exercício de re-platforming, não uma alteração de config.

Hosted harness vs owned harness

A distinção aqui é operacional, não sobre quem escreveu o código do harness. Hosted significa que o fornecedor corre o loop do harness na infraestrutura dele e tu chamas uma API. Owned significa que corres o loop na tua própria infraestrutura, mesmo que o código do harness tenha vindo de um fornecedor.

A LangChain aparece dos dois lados desta linha, o que confunde muita gente. Enviam LangGraph, uma library com licença MIT que fazes self-host (owned), e Deep Agents Deploy, um produto managed que corre um harness Deep Agents sobre LangSmith Deployment no seu modo cloud por omissão (hosted). A mesma empresa, dois modelos operacionais diferentes. Tu escolhes o modelo, não o fornecedor. (O Deep Agents Deploy também tem um modo self-hosted para equipas que querem a ergonomia do harness sem o componente cloud; esse modo cai no grupo owned.)

Escolhe um hosted harness quando não tens capacidade de plataforma e as restrições do fornecedor encaixam. Managed Agents significa apenas Claude. Deep Agents Deploy em modo cloud significa LangSmith em produção. Em troca, o fornecedor é dono de caching e compactação.

Um owned harness (LangGraph, Deep Agents Deploy em modo self-hosted, ou um harness custom em cima de um SDK) é a escolha certa quando tens platform engineers, quando precisas de iterar na forma do harness mais depressa do que o fornecedor vai lançar updates, quando requisitos de conformidade empurram a residência dos dados para debaixo do teu controlo, ou quando routing multi-modelo entre providers é inegociável. Pagas isso em pages e área operacional.

A maioria das equipas deve começar em hosted, medir o que precisa de mudar e migrar para owned apenas quando as restrições do hosted começarem a doer.

Hosted sandbox vs sandbox Docker / Fargate

Escolhe uma hosted sandbox quando o tempo de criação da sandbox importa (sub-200 ms), quando precisas de pause/resume de sessão com estado de memória, ou quando precisas de semântica de fork/branch. Escolhe Docker ou Fargate quando já pagas esse compute, quando precisas de acesso interno à VPC para fontes de dados sensíveis, ou quando tens restrições duras de residência de dados.

State stores: Git, DB e object storage lado a lado

Agentes de longa duração costumam ter três state stores a correr ao mesmo tempo, não uma, e cada uma guarda um tipo de estado diferente. O Git guarda o estado do workspace: o código, documentos e ficheiros de progresso que o agente está a alterar. Cada commit dá ao harness um ponto estável de recuperação e dá à sessão seguinte um histórico compacto para inspecionar. A checkpoint DB guarda o estado do graph do harness: o que foi decidido, que nodes correram, que resultados voltaram e o que deve correr a seguir. É isso que permite ao worker seguinte retomar a meio da execução. O artifact store guarda os grandes outputs finais, como PDFs, ficheiros parquet e screenshots. Esses não pertencem nem ao git nem à checkpoint DB.

Quando usar git como estado

Usa git quando o workload tiver forma de código (edições em múltiplos ficheiros, refactors, geração de apps) ou forma documental suficiente para que o histórico de ficheiros importe. O padrão é simples: criar uma run branch, fazer um commit initializer e depois fazer commits em fronteiras relevantes: após setup, após cada feature, depois de os testes passarem, depois da limpeza final. Guarda o SHA do commit mais recente do workspace ao lado da linha de checkpoint. Na retoma, o worker seguinte faz checkout da branch, lê git log --oneline -8, inspeciona git status e o diff mais recente, depois lê PROGRESS.md ou qualquer outro ficheiro de handoff escrito pela sessão anterior.

Isto faz do git uma superfície de recuperação para o artefacto em edição, não um substituto para a checkpoint DB. O Git consegue responder a duas perguntas: o que mudou, e que versão passou nos testes. Não consegue dizer ao harness que node do graph deve correr a seguir, que tool call está à espera de aprovação, ou que retry já gastou a sua idempotency key. O harness da Anthropic usa commits initializer mais commits por feature como source of truth para recuperação do workspace; o modelo lê git log --oneline -8 para recuperar estado. Salta o git quando o produto do trabalho é uma única resposta conversacional. O overhead não compensa.

Quando usar checkpointing em DB

Usa checkpointing do tipo PostgresSaver quando o agente tem uma estrutura em graph com vários nodes cujo estado intermédio importa (planner → researcher → writer → verifier). O repositório de referência usa-o precisamente por essa razão. Não coloques artefactos de workspace à escala de terabytes no checkpoint; esses vão para object storage.

Quando usar um artifact store (S3 / GCS)

Recorre a object storage em três situações. Primeiro, quando o output é maior do que algumas centenas de KB. Checkpoint DBs não foram feitas para guardar blobs grandes, e tentar mantê-los lá torna tanto a DB como o formato de checkpoint penosos. Segundo, quando consumidores downstream como ferramentas BI, clientes ou outros serviços precisam de artefactos endereçáveis por URL que consigam ir buscar sozinhos sem passar pelo agente. Terceiro, quando a janela de retenção do estado da execução e a janela de retenção do entregável divergem. Podes apagar o log de sessão ao fim de 30 dias mas guardar o relatório final durante anos. Indexa o layout por (thread_id, checkpoint_id, artifact_name) para que consigas sempre reconstruir que execução produziu que artefacto.

Quando adicionar gates de aprovação humana

Adiciona gates quando a tool call é destrutiva e irreversível (escritas em DB, movimento de dinheiro, envio de comunicações externas), quando a tool call sai do blast radius do agente (deploys para produção, publicações customer-facing), ou quando reguladores exigem revisão. Tanto o interrupt() do LangGraph como o approval middleware do Deep Agents têm suporte built-in para estes gates. A Parte 4 cobriu porque é que estes gates são uma questão de permissões, não de prompts.

Uma checklist prática para produção

Antes de um agente de longa duração ir para produção, responde a estas perguntas em termos concretos de infraestrutura.

  1. Que store é dona dos eventos de sessão e checkpoints?
  2. O que acontece se o worker morrer a meio de uma tool call?
  3. Uma execução consegue corromper o workspace de outra?
  4. Que ações exigem aprovação?
  5. O modelo ou a sandbox conseguem ler credenciais em bruto?
  6. Que tool calls podem repetir com segurança?
  7. Onde é aplicado o limite de custo por execução?
  8. Que verificação com contexto limpo decide "done"?
  9. Onde vivem os outputs finais depois de a sandbox desaparecer?
  10. Conseguimos explicar amanhã uma execução falhada sem a repetir?

Se a resposta a qualquer uma destas for "o prompt diz ao agente para ter cuidado", o sistema ainda não está em produção. Continua a ser uma demo.

Principais conclusões

  1. Agentes de longa duração precisam de um runtime, não apenas de um timeout HTTP maior. O runtime mantém a sessão, workspace, resultados de tools, checkpoints, traces, orçamentos, aprovações e credenciais fora da memória do modelo.
  2. Os componentes centrais são sessão, harness, sandbox, checkpoint e trace. Verificações de política e secret brokering atravessam todos eles.
  3. A primeira pergunta de deployment é a duração da execução. Um helper de 20 segundos pode viver num app server. Uma execução de coding ou research de seis horas precisa de uma queue, worker, estado durável e uma estratégia de sandbox.
  4. Queue + worker + checkpoint DB é a predefinição prática quando queres controlar o runtime. Hosted harnesses como Anthropic Managed Agents ou Deep Agents Deploy são melhores quando as restrições do fornecedor encaixam e não queres operar tu próprio o loop.
  5. Tools com side effects precisam de idempotency keys. Em queues e workflow engines, retries são normais. Sem deduplicação, um retry pode enviar o mesmo email, criar o mesmo PR ou cobrar duas vezes ao mesmo cliente.
  6. A observabilidade tem de sobreviver ao worker. Numa execução falhada de seis horas, os artefactos úteis são o event log, último checkpoint, trace, timeline de tool calls, diff de workspace, screenshots e metadados do ambiente.
  7. As suposições de runtime envelhecem à medida que os modelos mudam. Volta a testar resets de contexto, padrões de evaluator, superfícies de tools e regras de orçamento quando mudares de modelos ou harnesses.
  8. Os segredos devem ficar fora do harness e fora do contexto do modelo. O agente recebe capacidades de tools, não credenciais em bruto.

Referências

Artigos de engenharia

LangGraph e Deep Agents

OpenAI Agents SDK

Temporal

Plataforma Anthropic

Sandbox providers

Timeouts e quotas de plataformas cloud

Observabilidade

Série

O código do Market Analyst Agent (worker LangGraph, checkpointer Postgres, memória Qdrant, sidecar MCP e a topologia Docker Compose descrita acima) está no GitHub.