Runtime de AI Agents de longa duração: sessões e checkpoints

Viacheslav Dubrov

2026-05-26 · Atualizado 2026-08-01 · 43 min · Agentes de IA

Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.

Uma execução de um agent pode durar horas, enquanto o respetivo processo worker pode reiniciar a qualquer momento. O modelo continua a escolher a ação seguinte, mas o runtime tem de preservar o estado, controlar a execução e recuperar de uma falha a meio de um tool call. Este artigo define a fronteira do runtime. A Parte 6 abre depois o componente que decide dentro dessa fronteira — o harness, onde a memória, os contratos das tools e as verificações de permissões deixam de ser três temas e passam a ser um único programa.

Em resumo: Um agent de longa duração precisa explicitamente de cinco elementos: um session log durável, o harness que conduz o loop, um sandbox, um armazenamento de checkpoints e um trace. Para a maioria das equipas, a opção predefinida certa é uma queue mais um worker mais um checkpointer PostgreSQL. Se não conseguir dizer que componente é responsável por cada um dos cinco elementos, o agent ainda é um protótipo.

O que é um runtime de AI agent?

Um runtime de AI agent é a camada de infraestrutura que mantém um agent que usa tools ativo, isolado, observável e capaz de retomar a execução depois de terminar a chamada ao modelo. É responsável pelo estado da sessão, execução de tools, checkpoints, secrets, traces, limites de custo e modelo de deployment. O modelo escolhe a ação seguinte; o runtime determina onde essa ação é executada, como é registada e como a execução retoma depois de uma falha. A decisão sobre se a ação é permitida cabe ao harness. O harness não é uma camada de armazenamento; é o programa que se apoia nessas camadas e aparece na tabela abaixo porque também tem de ser colocado.

Quatro destas cinco — session, sandbox, checkpoint e trace — armazenam estado ou confinam a execução. O harness é o elemento que decide e é onde convergem as decisões sobre memória, contratos de tools e permissões. Este artigo trata-o como uma única caixa e descreve aquilo em que se apoia. A Parte 6 abre a caixa e reorganiza os mesmos cinco elementos no componente que decide e nos quatro sobre os quais este assenta.

As execuções longas quebram as premissas de processos stateless

Um endpoint de chat stateless pode manter o estado do pedido num único processo e descartá-lo depois da resposta. Uma execução longa de um agent atravessa reinícios de workers, deploys, resets de contexto e pausas para aprovação. O processo worker já não pode ser a fonte de verdade.

A equipa do OpenAI Codex explica até onde estas execuções podem chegar no seu texto sobre harness engineering:

“Vemos regularmente execuções individuais do Codex a trabalhar numa única tarefa durante mais de seis horas (muitas vezes enquanto as pessoas estão a dormir).”

A equipa de engenharia da Anthropic descreve o problema de estado correspondente em Effective harnesses for long-running agents:

“O desafio central dos agents de longa duração é terem de trabalhar em sessões discretas, sendo que cada nova sessão começa sem memória do que aconteceu anteriormente.”

Ambas as observações implicam o mesmo design de runtime: persistir o estado fora do worker e tornar os workers substituíveis.

A session tem de existir fora do processo worker. Um armazenamento durável regista chamadas ao modelo, tool results e aprovações, para que outro worker possa retomar no último ponto seguro depois de um crash. Os checkpoints também permitem ao runtime iniciar uma nova model session quando a context window fica cheia, sem repetir todo o histórico. Nas palavras da Anthropic, as instâncias do harness tornam-se descartáveis e reiniciáveis; o estado durável vive noutro local.

Coloque as cinco primitivas antes de fazer o deploy

O texto da Anthropic sobre Scaling Managed Agents fornece uma terminologia útil para cinco responsabilidades do runtime. O harness faz o agent avançar, enquanto a session regista o que este fez e o sandbox executa os comandos. O checkpoint fornece ao worker seguinte um ponto de retoma; o trace preserva evidências para depuração posterior. Uma implementação pode combinar componentes, mas as responsabilidades e as fronteiras de falha continuam a precisar de nomes.

Session. Um log append-only de tudo o que aconteceu: chamadas ao modelo, tool calls, resultados, erros e aprovações.

A palavra é ambígua, por isso é importante fixar três âmbitos chamados session. Uma thread é a conversa de um utilizador ao longo de vários dias. É a mais duradoura das três e o LangGraph acompanha-a através de um thread_id.

Uma model session é a mais curta: um período contínuo de contexto do modelo. A compactação — o passo que resume a janela para que o trabalho possa continuar — prolonga uma model session em vez de a terminar. Um reinício ou um novo início deliberado termina-a. A Parte 6 usa “model session” nesse sentido.

Neste artigo, “session” significa o log durável de uma execução. Situa-se entre as outras duas: várias model sessions escrevem num único log e uma thread acumula vários logs. A recuperação é wake(sessionId) → getSession(id) → resume from last event.

No LangGraph, a recuperação usa um thread_id e um checkpointer Postgres (consulte LangGraph persistence). O OpenAI Agents SDK inclui dez backends de session incorporados, incluindo SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession e EncryptedSession (consulte a documentação de Sessions).

Harness. O loop de orquestração e a única primitiva aqui que toma decisões. Compõe o prompt a partir da memória, chama o modelo, verifica o tool call proposto face às regras de permissões, despacha o que é permitido, escreve os resultados na session, aplica as regras de retry e decide se a tarefa terminou. Cada um destes passos codifica uma premissa sobre aquilo que o modelo não consegue fazer sozinho. A Anthropic salienta diretamente esse ponto — é citado na secção sobre modos de falha abaixo, que trata sobretudo do que acontece quando essas premissas ficam desatualizadas.

A equipa do OpenAI Codex chama a isto harness engineering: escrever software continua a exigir esforço de engenharia, mas uma parte cada vez maior desse esforço vai para o scaffolding e não para o próprio código. O CompiledStateGraph do LangGraph, o Deep Agents da LangChain e o seu ponto de entrada create_deep_agent, bem como o próprio Claude Code, são harnesses neste sentido.

Sandbox. O ambiente de execução isolado onde os comandos são efetivamente executados. A página de conceitos de sandbox do OpenAI Agents SDK estabelece claramente a distinção:

“O runtime exterior continua responsável por aprovações, tracing, handoffs e pelo registo necessário para retomar. A sessão do sandbox é responsável pelos comandos, alterações a ficheiros e isolamento do ambiente.”

“Runtime exterior” significa aí o harness juntamente com os seus armazenamentos de estado. Na terminologia desta série, as aprovações e os handoffs são decisões do harness (Parte 4 e Parte 6); o tracing e o registo necessário para retomar são assegurados pelas primitivas session e checkpoint.

Os sandboxes diferem no tempo que permanecem ativos e naquilo que preservam entre execuções. A forma mais simples é fresh ephemeral: criar um para uma única tarefa, destruí-lo quando a tarefa termina e suportar o custo de cold start em cada execução.

Os sandboxes persistent paused preservam o sistema de ficheiros e um snapshot da memória entre execuções. A retoma seguinte pode evitar um arranque completo. Snapshot or fork cria uma cópia copy-on-write a partir de um parent preparado, permitindo que muitas tarefas partilhem dependências instaladas e caches quentes sem partilharem o estado gravável.

Os sandboxes per-worktree atribuem a cada tarefa o seu próprio workspace e observability stack. Logs, métricas e traces separados permitem depurar uma execução sem que o seu estado se misture com o de outra. A tabela de fornecedores mais adiante compara o comportamento de cold start e de persistência.

Checkpoint. Estado que permite retomar.

O PostgresSaver do LangGraph escreve um Checkpoint em cada fronteira de super-step. Um super-step é uma ronda do grafo, constituída por um único nó ou por um batch executado em paralelo. As escritas por tarefa vão para checkpoint_writes, pelo que os outputs de nós concluídos não são recalculados quando um nó irmão falha.

Um checkpoint é um dict simples (v, id, ts, channel_values, channel_versions, versions_seen, updated_channels). O LangGraph serializa-o com o seu JsonPlusSerializer baseado em msgpack, e não com JSON. datetime, set, Decimal e dataclasses são convertidos de ida e volta. O formato está documentado na página langgraph-checkpoint-postgres do PyPI e na referência de checkpoints do LangGraph.

StateSnapshot é a representação separada e mais rica que graph.get_state() constrói sobre um checkpoint. É o objeto cujo .values o debug bundle descarrega mais tarde.

Trace. A superfície de replay e depuração. Cada chamada ao modelo, tool call e passo de sub-agent torna-se num span com tempos, inputs, outputs, contagens de tokens e custo. Quando uma execução de seis horas falha, é no trace que procura o que correu mal. Nessa altura, o output do terminal já desapareceu há muito. As convenções semânticas GenAI do OpenTelemetry normalizam os nomes dos atributos (qual o modelo, qual o fornecedor, quantos tokens, qual a conversation, qual o workflow). Para um destino compatível com OTLP que suporte estas convenções, a mesma instrumentação pode exportar o trace para sistemas como o Tempo, o Jaeger, o Honeycomb ou o LangSmith, embora possam continuar a ser necessários adaptadores de backend ou configuração específica do destino.

Policy e secrets atravessam as primitivas

Duas fronteiras atravessam as cinco primitivas. São a versão no runtime do argumento de segurança da Parte 4. A decisão de permissão pertence ao harness; o que se segue explica onde está fisicamente o mecanismo que a aplica e o que lhe fornece dados.

Aplicação de permissões

A permission ladder da Parte 4 precisa de um local onde ser executada. A verificação ocorre antes de cada tool call e decide se este pode avançar. Na produção, são comuns dois padrões. O Deep Agents permite que cada subagent declare os caminhos de ficheiros que pode ler ou escrever, e o middleware bloqueia tudo o que fique fora dessa declaração. O Anthropic Managed Agents encaminha cada tool call através de um proxy Model Context Protocol (MCP), pelo que é o proxy que aplica as permissões, e não o código do agent. Quando uma chamada sensível requer aprovação humana, o interrupt() do LangGraph e o approval hook do Deep Agents pausam o grafo até uma pessoa aprovar.

Secret broker

O modelo não deve ver secrets de longa duração e, normalmente, o sandbox também não. O padrão Managed Agents é o que deve ser replicado:

“Para o Git, usamos o access token de cada repositório para clonar o repositório durante a inicialização do sandbox e ligamo-lo ao remote Git local. Git push e pull funcionam a partir do sandbox sem que o agent alguma vez manipule o token. Para tools personalizadas, suportamos MCP e armazenamos tokens OAuth num vault seguro. O Claude chama tools MCP através de um proxy dedicado; este proxy recebe um token associado à session. … O harness nunca toma conhecimento das credenciais.”

Na stack de referência market-analyst-agent — um pequeno agent LangGraph que obtém dados de mercado e escreve um relatório de analista, desenvolvido ao longo desta série — o sidecar MCP contém as API keys do fornecedor de dados e expõe apenas a superfície de tools ao worker LangGraph. No ficheiro compose local, ambos os containers leem o mesmo .env, um atalho de desenvolvimento e não o padrão recomendado. Em produção, o ambiente do sidecar vem de um secret store — Docker secrets ou HashiCorp Vault — que o worker não pode ler. O worker chama depois a tool sem nunca deter a credential subjacente.

Verifique a colocação

Uma verificação prática consiste em registar cada componente e quais das cinco primitivas implementa. O Postgres pode abranger session e checkpoint. O worker container é o harness. Um serviço como Daytona, Modal ou E2B fornece o sandbox, enquanto o Tempo ou o LangSmith armazena o trace.

Depois, examine as falhas acopladas. Se duas primitivas viverem no mesmo processo, um crash derruba ambas. Se partilharem uma credential, uma fuga atravessa as duas fronteiras. Exemplos comuns são um worker que também é responsável pela durabilidade dos traces ou um token de sidecar que também desbloqueia a base de dados de checkpoints.

Modos de falha de um runtime de AI agent em produção

O runtime gere retries, restaura trabalho anterior, isola workspaces e aplica budgets. À medida que as execuções atravessam workers e context windows, as falhas passam a concentrar-se no estado, em side effects duplicados, em drift do sandbox e em excessos de budget.

As falhas dividem-se em quatro grupos:

• Falhas de qualidade do output: o agent declara vitória antes de o trabalho estar realmente concluído, esquece o que fez depois de um reset da context window ou confia na sua própria autoavaliação e entrega um output com erros.
• Falhas de controlo de custos: o agent fica preso num retry loop ou consome um budget de tokens ou de tool calls sem produzir nada útil.
• Falhas de estado e crash: os workspaces sofrem drift porque uma execução altera ficheiros pertencentes a outra, os tool calls são executados mais do que uma vez porque os retries os repetem ou o trabalho perde-se 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 a janela ainda tem margem.

A tabela associa cada falha a uma mitigação, à base da recomendação e ao runtime hook que a aplica. O comportamento específico do modelo pode mudar, por isso trate as observações dos fornecedores como prompts para voltar a testar a premissa, e não como regras permanentes.

Duas ideias estão por detrás da maioria dessas linhas. A Anthropic, sobre a obsolescência do harness em Harness design for long-running application development:

“Cada componente de um harness codifica uma premissa sobre aquilo que o modelo não consegue fazer sozinho, e vale a pena submeter essas premissas a testes de stress, tanto porque podem estar incorretas como porque podem ficar rapidamente desatualizadas à medida que os modelos melhoram.”

A Vercel, sobre o problema relacionado de demasiadas tools codificarem demasiadas premissas, em We removed 80% of our agent’s tools:

“Eliminámos a maior parte e reduzimos o agent a uma única tool: executar comandos bash arbitrários. Chamamos-lhe um file system agent.”

A citação descreve o núcleo bash; o agent lançado pela Vercel manteve duas tools, ExecuteCommand e ExecuteSQL, reduzidas de quinze. A Parte 3 aborda o antes e o depois completos. O resultado reportado nas cinco queries representativas: o sucesso passou de 4/5 para 5/5 e o pior caso baixou de 724 s / 100 passos / 145 463 tokens (falhou) para 141 s / 19 passos / 67 483 tokens (teve sucesso). Essa linha do pior caso é a mais impressionante; em média, nas cinco queries, a poupança de tokens foi de 37%. A lição não é “elimine as suas tools”. É que todas as primitivas do runtime, incluindo a superfície de tools, têm um prazo de validade. Volte a testar a premissa quando o modelo mudar.

A Cognition observou o mesmo alvo móvel na duração das sessions com o Sonnet 4.5. Em Rebuilding Devin for Claude Sonnet 4.5, descreve um modelo que escreve proativamente SUMMARY.md / CHANGELOG.md quando deteta que o contexto está a esgotar-se, mas subestima quantos tokens ainda lhe restam. A solução foi ativar o contexto de 1M tokens e limitar a utilização a 200k, para que o modelo continuasse a acreditar que tinha margem. Quando escreveram o artigo, isto era uma beta flag.

A documentação atual da context window da Anthropic, em agosto de 2026, continua a indicar 200k para o Sonnet 4.5. A janela de 1M é disponibilizada por defeito, sem beta header, no Opus 4.6 e posteriores e no Sonnet 4.6 e posteriores. O limite é a parte que importa acompanhar. Existe apenas porque o Sonnet 4.5 calcula mal o contexto restante; no dia em que um modelo deixar de o fazer, o limite deixará de ser uma solução e passará a ser um teto artificial. As gerações de modelos mudaram mais do que uma vez desde que a Cognition escreveu esse artigo; volte a confirmar os números face à lista atual de modelos antes de transportar qualquer destas conclusões.

A equipa de harness da OpenAI tem a versão numa linha: “Os humanos orientam. Os agents executam.” Quando algo falha, a pergunta útil é qual a capacidade que falta e como tornar essa capacidade simultaneamente legível e aplicável pelo agent.

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

Uma execução bem comportada é aborrecida. É uma cadeia de pequenos passos recuperáveis e cada passo escreve o seu resultado em armazenamento durável antes de o seguinte começar.

Escrever cada resultado antes de iniciar o passo seguinte é o que limita os danos de um crash. Uma falha perde apenas o passo em curso e o worker seguinte retoma a partir do último passo concluído, em vez de reiniciar o pedido completo.

1. Arranque a partir de uma session nova ou retomada. Ao retomar, monte o workspace no seu último estado conhecido, leia quaisquer ficheiros de progresso deixados pela tentativa anterior (PROGRESS.md, feature-list.json) e carregue o último checkpoint da base de dados. É aqui que o harness entrega ao agent tudo o que o worker anterior tinha em memória antes de morrer.
2. Planeie antes de executar tool calls. Registe o que significa “concluído”, quanto a execução pode gastar, quais as tools que o agent pode invocar e o que deve terminar a execução antecipadamente. Estes valores do plano tornam-se verificações do runtime; sem eles, a execução não tem nada que a limite.
3. Execute um tool call de cada vez. A verificação de permissões do harness decide se o permite, depois despacha-o, captura o resultado e escreve um evento no session log. Um passo, um evento. Um crash entre eventos é recuperável porque a fonte de verdade é o log, e não a memória do worker.
4. Crie checkpoints nas fronteiras de super-step ou, num harness mais simples, depois de cada evento. Persista o estado do grafo, o workspace diff e referências para quaisquer artefactos produzidos. É este checkpoint que o passo 1 lê na retoma seguinte. Se o checkpoint estiver em falta ou desatualizado, a recuperação degrada-se para a repetição de todo o session log desde o início, o que é muito mais lento.
5. Avalie os artefactos quando o agent considerar que terminou: testes, um evaluator com contexto novo, validação do schema e verificações no browser. 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.

Nenhum passo da lista exige que o agent se lembre de algo entre execuções. O estado vive na session e no checkpoint, e o agent lê-o novamente em cada retoma.

Qualquer tool com side effects precisa de uma idempotency key derivada do ID da session e do ID do tool call, armazenada antes de o side effect ser executado. 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 comportamento predefinido em queues e workflow engines, pelo que o duplicado vai acontecer. Se um tool call puder causar danos reais quando repetido e não conseguir deduplicá-lo através de uma key, a tool ainda não está pronta para agents.

A avaliação deve incluir evidência externa ao contexto que produziu o resultado. Um evaluator com contexto novo reduz o enviesamento de contexto partilhado, enquanto testes, lints, verificações no browser e validação de schemas fornecem evidência determinística. A verificação pode devolver pass, fail ou needs_human. Para code agents, o reviewer pode ser outra model session com tools apenas de leitura. Para data agents e report agents, combine validação determinística com um reviewer model quando ainda for necessário julgamento.

Onze padrões de deployment de AI agents e o que decide entre eles

Depois de nomear as cinco primitivas, a questão passa a ser qual o modelo de deployment que as executa. Por “modelo” entendo uma disposição dessas primitivas: onde vive o harness, onde persiste o estado e que tipo de sandbox executa o trabalho. Um modelo é uma decisão de wiring, não uma escolha de fornecedor. O gráfico abaixo mostra em que ponto cada modelo é adequado no eixo da duração da execução. O texto seguinte explica o que decide entre eles.

Se só ler um dos onze, leia o modelo 2: queue + worker + checkpoint DB. É a opção predefinida que recomendo à maioria das equipas, o modelo usado pelo repositório de referência e o esqueleto sobre o qual variam muitos dos restantes: queue → worker → estado durável, trocando a origem do sandbox, o responsável pelo harness ou o motor de estado. Ler primeiro o modelo 2 torna o resto mais rápido de consultar.

O gráfico compara os modelos pela duração da execução. A matriz abaixo compara-os pela responsabilidade: cada célula contornada identifica o componente que fornece essa primitiva.

1. SDK dentro de um app server (síncrono, ao nível do pedido)

O modelo original. O agent SDK é executado dentro de um request handler. É adequado para tarefas com menos de 30 segundos, demos e ferramentas internas. É inadequado para tudo aquilo de que um cliente HTTP se possa desligar. O timeout HTTP do Cloud Run tem um máximo de 60 minutos e qualquer panic da camada web termina a execução. O SDK é o harness, o processo web também funciona como sandbox e o estado vive normalmente na memória do processo, a menos que o envie explicitamente para outro local. Não use este modelo para trabalho de várias horas.

2. Queue + worker + checkpoint DB

A opção predefinida que recomendo à maioria das equipas e o modelo de produção usado em market-analyst-agent: um worker Python com um checkpointer PostgreSQL, Redis Streams (ou RabbitMQ) para a queue de entrada e um sidecar MCP para as tools. É adequado para execuções de 10 minutos a várias horas com passos idempotentes. O runner local pode ignorar a queue para desenvolvimento síncrono, mas a queue faz parte do modelo de produção quando é necessária submissão assíncrona e backpressure.

A aplicação aceita um pedido, cria uma linha de session, coloca um job na queue e devolve um ID de execução. O worker obtém o job, executa o harness, escreve checkpoints, faz stream do estado e armazena artefactos à medida que avança. O Postgres persiste, os workers são substituíveis e a profundidade da queue fornece backpressure. Compute Spot/Preemptible funciona desde que o checkpointer termine de escrever no disco antes de comunicar sucesso.

Neste modelo, o worker é o harness. O container e o workspace por thread fornecem uma fronteira de execução, mas código não confiável continua a precisar de um sandbox reforçado ou de uma VM. O Postgres é responsável pelo estado de session e checkpoint. Os traces passam pelo OpenTelemetry para a stack de observabilidade que estiver a utilizar.

3. Durable workflow engine (estilo Temporal)

O código de orquestração do agent é executado dentro de um Temporal Workflow; as chamadas ao modelo e às tools são executadas como Activities. O estado do Workflow vive num event-history log suportado por Cassandra, MySQL ou Postgres, pelo que o estado pode ser repetido de forma limpa entre deploys. A integração Temporal × OpenAI Agents SDK, geralmente disponível desde março de 2026, inclui um OpenAIAgentsPlugin e um helper activity_as_tool, e o texto sobre agentic sandboxes descreve como fazer fork de um agent em execução para outro fornecedor de sandbox a meio da conversa. Workflows inativos consomem zero compute. As limitações são reais: realtime agents não são suportados, o streaming continua marcado como experimental e LocalShellTool e ComputerTool estão desativados porque não se adequam a um modelo distribuído.

Use este modelo quando a execução tiver pontos de espera reais: aprovações humanas, callbacks externos, sleeps longos, retries com regras de negócio ou janelas de deployment. Uma aprovação humana torna-se num sleep durável que não consome compute, e não num polling loop.

O código do Workflow é o harness. O sandbox vive normalmente fora do Temporal e é chamado a partir de Activities. O estado da session e do checkpoint colapsa no event-history log do Temporal, enquanto a visibilidade do trace vem da UI do Temporal e dos spans OpenTelemetry em cada Activity.

4. Sandbox provider por session

Um modelo mais recente. Cada execução de um agent recebe a sua própria microVM ou container de um fornecedor de sandbox-as-a-service. O harness vive num local durável; o sandbox é o ambiente de execução descartável.

Os cold starts aqui são provisioning end-to-end, e não apenas boot bruto: os ~150 ms da E2B são adicionais aos ~125 ms de boot Firecracker citados na Parte 4 para o próprio hypervisor. A tabela combina a comparação E2B vs Daytona, a documentação de sandboxes e o changelog de fork/snapshot da Daytona, os guias da Modal sobre sandboxes e cold start, a listagem Runloop no AWS Marketplace e os preços da Vercel Sandbox.

A Daytona regista uma ligação parent-child para cada fork independente, preservando a linhagem dos sandboxes derivados. O harness do OpenAI Codex usa a variante per-worktree: “O Codex trabalha numa versão totalmente isolada dessa aplicação, incluindo os seus logs e métricas, que são destruídos quando a tarefa termina.”

Escolha este modelo quando o agent executar código não confiável, automação de browser, testes ou instalações de packages. O compromisso é um custo e um acoplamento ao fornecedor superiores aos de workers partilhados.

O fornecedor é responsável pelo sandbox e por mais nada. O harness, a session, o checkpoint e o trace permanecem do seu lado, normalmente ligados através do modelo queue + worker do ponto #2.

5. Anthropic Managed Agents (harness alojado)

A Anthropic lançou o Managed Agents em public beta a 8 de abril de 2026, atrás do beta header managed-agents-2026-04-01. O serviço fornece uma session, harness, sandbox e proxy MCP suportado por vault, todos alojados. O wake(sessionId) pode inicializar o harness num novo worker sem perder o estado durável da session.

A Anthropic cobra o Managed Agents às tarifas normais de tokens mais $0.08 por hora de session. A faturação tem granularidade de milissegundos e só se aplica enquanto o estado da session for “running”; o tempo inativo é gratuito. Um retry loop descontrolado acrescenta, portanto, um custo de horas de session ao custo dos tokens.

Leia as limitações. O desconto da Batch API não se aplica (“As Sessions têm estado e são interativas. Não existe modo batch.”). O Managed Agents não está disponível através do AWS Bedrock nem do Google Vertex AI. Durante a beta, os túneis MCP e o “dreaming” do agent estão atrás de um research preview adicional ao qual é necessário pedir acesso; a coordenação multi-agent e a autoavaliação com classificação por rubric são partes documentadas da beta. O lock-in é elevado: troca a liberdade do harness por não ter de executar o loop.

A Anthropic aloja as cinco primitivas: session, harness, sandbox, checkpoint e trace. Entrega o runtime e recebe os outputs.

6. LangChain Deep Agents Deploy (open harness gerido)

deepagents deploy empacota um deepagents.toml num LangSmith Deployment com execução durável, memória, multi-tenancy, human-in-the-loop, observabilidade, execução de código em sandbox e execuções agendadas. São suportados modos de deployment cloud, híbrido e self-hosted. Os fornecedores de sandbox (LangSmith Sandboxes, Daytona, Modal, Runloop ou um fornecedor personalizado) podem ser trocados através de um único valor de configuração. O estado vive num virtual filesystem com backends configuráveis; a memória pode ter âmbito de user, assistant ou ambos. O lock-in é inferior ao do Managed Agents: o harness tem licença MIT, as instruções usam o standard aberto AGENTS.md e os agents são expostos através de MCP, do protocolo A2A (Agent2Agent) e do Agent Protocol. Consulte o texto da LangChain sobre runtime-behind-production-deep-agents.

Por defeito, as cinco primitivas são alojadas, mas cada uma pode ser trocada através de configuração. O sandbox fica atrás de um único valor de configuração. A session e o checkpoint vivem num virtual filesystem com backends configuráveis. O trace vai para o LangSmith.

7. Serviço ou job do Google Cloud Run

O Cloud Run tem dois modos de runtime diferentes e a escolha adequada depende da forma como o agent é invocado. Services estão ligados a HTTP e escalam para zero entre pedidos; o harness é executado como request handler e devolve a resposta quando a execução termina. Jobs executam até à conclusão sem um HTTP entrypoint; o harness é executado como um worker one-shot que termina quando a tarefa acaba. Ambos podem alojar o harness, mas nenhum mantém estado entre execuções. As sessions e os checkpoints têm de viver no Postgres, Spanner ou num armazenamento externo semelhante.

Os limites rígidos são muito diferentes entre os dois. Timeout de pedidos dos Cloud Run services: 300 s por defeito, máximo de 3 600 s (60 min). Os WebSockets têm o mesmo timeout. Cloud Run jobs: 10 min por tarefa por defeito, máximo de 168 h (7 dias); para tarefas que usam GPUs, máximo de 1 hora. Os services escalam para zero, a menos que ative CPU always-on; os jobs não têm HTTP e não fazem autoscale.

Use um service para execuções síncronas até 60 minutos. Use um job para trabalho one-shot ou assíncrono mais longo. Os Cloud Run Jobs podem manter uma tarefa ativa durante dias, mas não fornecem replay durável entre deploys, alterações de versão ou substituição de workers. Acima de 7 dias, não use Cloud Run.

O Cloud Run aloja o harness. O estado de session e checkpoint vive no Postgres, Spanner ou noutro armazenamento externo, e os traces podem passar pelo Cloud Logging e pelo OpenTelemetry. O service container é um ambiente de execução; acrescente um sandbox separado quando o agent executar código não confiável.

8. AWS Lambda (porque é a ferramenta errada)

O timeout máximo de uma função Lambda é 900 s (15 minutos), sem exceção. Se o API Gateway estiver à frente da função, o limite de integração depende do tipo de API. As HTTP APIs permitem 30 segundos; as integrações REST têm 29 segundos por defeito, enquanto as Regional e private REST APIs podem configurar um timeout maior. Nenhum destes percursos transforma o Lambda num worker de várias horas. Um harness de longa duração continua a precisar de estado externo e de novas invocações, recriando o modelo queue + worker. Use Lambda para tool calls delimitados, como obter ficheiros ou fazer uploads para S3, invocados por um orquestrador de maior duração. Não coloque lá o orquestrador.

No máximo, o Lambda aloja um tool call dentro do seu limite de 15 minutos. O harness, a session, o checkpoint, o sandbox e o trace têm de viver noutro local.

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

A documentação do Fargate não define um limite rígido para a duração das tasks, ao contrário do Lambda. As quotas de throttling do Fargate permitem um burst de lançamento de 100 e reposição a 20 por segundo, com budgets separados para on-demand e spot. As quotas de services do ECS limitam a 1 000 tasks por service os services que usam AWS Cloud Map discovery e a 5 000 container instances os clusters suportados por EC2.

O Fargate exige o modo awsvpc, pelo que cada task recebe uma interface de rede e um IP privado. Este modelo é adequado para acesso a dados internos da VPC. O Fargate Spot acrescenta risco de interrupção e a durabilidade continua a ser da sua responsabilidade, porque a plataforma não tem replay ao estilo do Temporal.

O Fargate aloja o harness e atribui a cada execução a sua própria task. Isso separa workspaces e credenciais por task, mas não constitui, por si só, um sandbox completo para código hostil. A session, o checkpoint e o trace vão para serviços externos, como RDS ou DynamoDB, além de CloudWatch/X-Ray.

10. Kubernetes Job ou namespace por session

É uma boa opção quando já opera Kubernetes e quer sandbox-per-session com controlos ao nível do cluster. É uma má opção quando precisa de arranque inferior a um segundo, porque obter a imagem do container e inicializar o pod demora demasiado num cold start. O padrão consiste num Job por execução do agent, com activeDeadlineSeconds, um PersistentVolumeClaim para o workspace e um sidecar para o servidor MCP. A recuperação de crashes é da sua responsabilidade. Adotar Kubernetes apenas para alojar agents é caro em overhead de configuração e carga operacional. Só vale a pena se já executar K8s por outras razões.

O Kubernetes aloja o harness e o ambiente de execução por execução, normalmente como um único Job e, por vezes, com um namespace dedicado. Um isolamento forte continua a depender da runtime class, da network policy, da pod security e da fronteira subjacente de container ou VM. O estado de session e checkpoint vive numa base de dados externa ou num PersistentVolumeClaim.

11. Docker Compose local (apenas desenvolvimento)

É a referência para a secção seguinte. O objetivo deste modelo é espelhar a topologia de produção um-para-um (as mesmas primitivas, a mesma forma de rede) enquanto tudo é executado numa única máquina. O que não espelha é o isolamento: um mount de workspace partilhado, um Postgres, nenhum sandbox reforçado e nenhuma failure domain separada entre o worker e o seu estado. Não coloque em produção nada com este formato.

O Compose espelha o modelo #2 num único host. O Postgres mantém o estado de session e checkpoint e o worker container é o harness. O mount de workspace partilhado é conveniente em desenvolvimento, mas não isola execuções não confiáveis. A stack OpenTelemetry opcional regista os traces.

Stack de referência: Docker Compose

A topologia de referência, usada em slavadubrov/market-analyst-agent, consiste num worker LangGraph, num checkpointer Postgres, no Qdrant para retrieval, num sidecar MCP, numa queue Redis para execuções assíncronas semelhantes às de produção e numa stack de observabilidade opcional Prometheus / Grafana / Loki / Tempo / OTel. No compose local, o Redis é opcional apenas porque o runner síncrono pode chamar diretamente o worker. docker compose up inicia localmente a topologia central; o sidecar MCP e a stack de observabilidade são profiles opt-in (--profile mcp, --profile observability).

A única peça que vale a pena mostrar inline é a ligação LangGraph canónica. É um excerto ilustrativo, não um exemplo executável a partir do repositório. Para o executar são necessários langgraph, langgraph-checkpoint-postgres e psycopg[binary,pool], uma base de dados PostgreSQL acessível com permissão para criar as tabelas do checkpointer, POSTGRES_PASSWORD e um StateGraph previamente criado em builder; consulte a configuração do checkpointer Postgres do LangGraph.

import os
from urllib.parse import quote

from langgraph.checkpoint.postgres import PostgresSaver

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

Observabilidade que sobrevive à execução

É fácil depurar request handlers curtos: quando algo falha, lê a resposta e o log em tempo real. Os agents de longa duração não têm esse luxo. Quando uma execução de seis horas falha, o evento relevante aconteceu há cinco horas, o output do terminal desapareceu e o worker que o produziu foi substituído. Ninguém vai reconstruir a execução de memória. Por isso, a depuração é feita a partir de artefactos duráveis escritos enquanto a execução ainda estava ativa.

As stacks de produção tendem a abranger quatro tipos de artefacto, divididos em dois grupos. Dois são lidos depois de a execução terminar, para postmortems e replay: um event log consultável de cada passo e traces OpenTelemetry que mostram para onde foram o tempo e os tokens. Os outros dois são lidos durante a execução. Um é um live tail do que o agent está a produzir no workspace. O outro é uma observability stack por worktree que o próprio agent pode consultar enquanto trabalha.

Event log estruturado (lido depois da execução)

Cada chamada ao modelo, tool call, resultado, erro e aprovação escritos em armazenamento durável, indexados pelo ID da session e pelo timestamp. Quando a execução termina, consulta-o como uma tabela normal de base de dados. Addy Osmani estabelece claramente a fasquia em Long-running Agents: “Se não consegue reconstruir, a partir de armazenamento durável, o que o agent fez nas últimas 24 horas, aquilo que tem é um shell script de longa duração que, por acaso, chama um LLM, e não um agent de longa duração.”

Traces OpenTelemetry GenAI (lidos depois da execução)

O mesmo tipo de dados passo a passo é emitido como spans usando os atributos standard das gen_ai.* semantic conventions: nome do modelo, fornecedor, contagens de tokens de input e output, ID da conversation e nome do workflow. As convenções continuam no nível de estabilidade Development.

Em 2026, saíram do repositório principal de semantic conventions do OpenTelemetry para o seu próprio repositório de semantic conventions GenAI. Os nomes dos atributos podem ser usados para instrumentação, mas fixe a revisão que validou, em vez de um número de versão do repositório principal. Os campos específicos do fornecedor vivem em subnamespaces (anthropic.*, openai.*) indexados por gen_ai.provider.name. A razão para usar o standard é a portabilidade: em destinos compatíveis com OTLP que suportem estas convenções, mudar de backend pode não exigir nova instrumentação do código, embora possam continuar a ser necessários adaptadores de backend ou configuração específica do destino.

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

A forma mais rápida de saber o que um agent está a fazer neste momento é acompanhar o que está a produzir no workspace, e não fazer grep ao session log. O quick-start Harness Primitives for Long-Running Claude Agents da Anthropic inclui um watch loop de dois painéis para este fim: watch -n 5 'git log --oneline -8' mostra os commits mais recentes feitos pelo agent e watch -n 5 'find screenshots -name "*.png" | tail -5' mostra os screenshots mais recentes que este capturou. Dois painéis do terminal a atualizar de cinco em cinco segundos são suficientes para perceber se a execução está a progredir ou se está presa num loop.

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

Segundo o post da OpenAI sobre harness: “Logs, métricas e traces são expostos ao Codex através de uma observability stack local que é efémera para cada worktree.” Cada worktree de agent recebe a sua própria stack Loki + Prometheus + Tempo de curta duração, limitada apenas à execução em causa. O agent consulta-a enquanto trabalha. É isso que permite transformar um prompt como “nenhum span nestas quatro jornadas de utilizador excede dois segundos” em algo que o agent pode verificar diretamente, em vez de ter de adivinhar.

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

Uma observability stack self-hosted mínima

Para algo como market-analyst-agent:

1. OpenTelemetry Collector com o GenAI Normalizer Processor (contrib, alpha) para os atributos GenAI suportados. Use os processors genéricos Attributes ou Transform para filtrar ou reescrever campos gen_ai.*.
2. Tempo (ou Jaeger) para traces, indexados por gen_ai.conversation.id / thread_id.
3. Loki para entradas do event log estruturado.
4. Prometheus para gen_ai.client.token.usage, gen_ai.client.operation.duration e gen_ai.client.operation.time_to_first_chunk — as métricas gen_ai.server.* vêm do model server, pelo que só as obtém se alojar os weights (consulte as convenções de métricas GenAI).
5. Grafana dashboards indexados por gen_ai.agent.name e gen_ai.request.model.

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

• LangSmith: integração nativa com LangGraph; é também o destino de deployment do Deep Agents Deploy.
• Braintrust: melhor opção se a prioridade forem regression suites eval-first.
• Arize Phoenix: OSS, nativo em OTLP (o protocolo de transporte do OpenTelemetry), combinando com instrumentação OpenInference.
• Dashboard de tracing da OpenAI: automático quando usa o OpenAI Agents SDK ou a sua integração com Temporal.
• Claude tracing da Anthropic: para sessions executadas no Managed Agents.

Instrumentar o nó LangGraph

Este é um excerto ilustrativo e é ignorado pelo example runner do repositório. Assume que o nó LangGraph já tem um span OpenTelemetry ativo, o thread_id atual e um objeto usage de resposta do fornecedor com input_tokens e output_tokens; a configuração do tracer, a configuração da exportação e o mapeamento de usage específico do fornecedor estão fora do snippet.

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

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

Três queries que vale a pena ter num dashboard

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

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

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

O padrão do debug bundle

Quando uma execução falha, o worker deve deixar um /workspaces/${THREAD_ID}/_debug/ contendo os artefactos que seriam pedidos num postmortem:

• session.jsonl: dump completo do event log do PostgresSaver (checkpointer.list({"configurable": {"thread_id": ...}})).
• last_state.json: StateSnapshot.values do último super-step bem-sucedido.
• trace.json: spans exportados via 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 do initializer.
• screenshots/*.png: aquilo que o agent viu.
• PROGRESS.md, feature-list.json e quaisquer outros ficheiros de progresso criados pelo agent.
• env.txt: image tags, versão do modelo, harness commit SHA.

Este bundle fornece a um humano ou a um reviewer agent evidência suficiente para reconstruir a falha. “O agent ficou bloqueado” é vago. Um relatório ilustrativo é concreto: a session s_123 gastou 71% dos tokens a repetir três comandos depois de npm install ter falhado.

Escolher o modelo adequado: um guia de decisão

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

Comece pela duração da execução

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

• Menos de 30 segundos, idempotente: SDK ao nível do request lifecycle num app server.
• 30 s a 60 min: queue + worker + checkpoint DB.
• 60 min a 24 h: a mesma queue + worker ou um Cloud Run Job para trabalho one-shot. Use um durable workflow engine se também precisar de versionamento e replay.
• Mais de 24 h, tem de sobreviver a deploys: durable workflow engine (estilo Temporal). Os Cloud Run Jobs podem manter trabalho longo até ao limite da task, mas não fornecem semântica de replay.
• Loops de training de reinforcement learning com vários dias: K8s Job + volume + Temporal.

Depois deste filtro inicial, verifique side effects, recuperação, replay, isolamento, localização dos dados e a equipa que irá operar o sistema.

Adequação da plataforma por caso de uso

A matriz é densa e nenhuma célula verde decide isoladamente a arquitetura; são normalmente as células amarelas, onde uma plataforma suporta algo apenas com uma ressalva, que tomam essa decisão. Uma cobertura ampla de workloads é útil, mas não mostra residência dos dados, semântica de replay, dependência do fornecedor, maturidade operacional ou o custo de mover o estado mais tarde.

O Deep Agents Deploy é a única coluna da matriz sem células vermelhas ou amarelas: execuções síncronas curtas, batch de várias horas, forking de sandboxes, trabalho com GPU e lock-in mínimo aparecem todos a verde. Isso torna-o candidato quando uma única plataforma tem de servir todos os workloads existentes. Essa abrangência vem com um historial de produção mais curto do que uma stack queue + worker + Postgres. Trate as células verdes como alegações de capacidade a validar e compare depois as restrições operacionais que a matriz não consegue codificar.

O Anthropic Managed Agents adequa-se totalmente ao seu workload ou não se adequa de todo. O produto tem duas restrições rígidas: é hosted-only e Claude-only. Se o seu workload satisfizer ambas — Claude já é o modelo pretendido e prefere não operar um harness — o Managed Agents é uma boa opção. Um coding agent interno executado em bursts de duas a seis horas é o formato que melhor se adequa e remove uma grande parte do trabalho de plataforma da sua equipa. Se uma das restrições falhar porque precisa de um modelo que não seja Claude ou de compliance self-hosted, o Managed Agents não serve. Nenhuma alteração de configuração muda esse facto.

Vale a pena modelar os preços antes de se comprometer, e não depois. A linha de horas de session é $0.08/hour on top of standard token costs. If a single session ran continuously, that is about$58/mês por session. Com 100 sessions a correr continuamente, é aproximadamente $5,800/month _before tokens_. Multiply$0.08 multiplicado pelas horas esperadas de sessions concorrentes; acrescente esse valor à fatura de tokens e compare-o com o custo de uma stack queue + worker na sua própria infraestrutura. Migrar do Managed Agents mais tarde é um exercício de re-platforming, não uma alteração de configuração.

Harness hosted versus harness próprio

A distinção aqui é quem opera o harness, e não quem escreveu o código. Hosted significa que o fornecedor executa o loop do harness na sua infraestrutura e o consumidor chama uma API. Owned significa que o consumidor executa o loop na sua própria infraestrutura, mesmo que o código do harness venha de um fornecedor.

A LangChain aparece dos dois lados desta linha, o que causa confusão. A empresa disponibiliza o LangGraph, uma biblioteca com licença MIT que pode alojar por si próprio (owned), e o Deep Agents Deploy, um produto gerido que executa um harness Deep Agents no LangSmith Deployment no seu modo cloud predefinido (hosted). A mesma empresa, dois modelos operacionais diferentes. O que está a escolher é quem executa o loop, e não cujo logótipo aparece na biblioteca. (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 pertence à categoria owned.)

Escolha um harness hosted quando o suporte de modelos, a fronteira dos dados, o comportamento de recuperação e os pontos de extensão já forem adequados. Escolha um harness owned quando essas restrições forem requisitos que espera que mudem. A migração entre ambos altera estado, observabilidade e fronteiras de execução; teste, por isso, o caminho de saída antes de os dados de produção dependerem dele.

Sandbox hosted versus ambiente de execução próprio

Escolha um sandbox hosted quando o isolamento, as semânticas de pause/resume ou de fork e o startup budget do fornecedor corresponderem ao seu threat model. Docker ou Fargate podem ser adequados para workloads internos de confiança que necessitam de acesso à VPC ou de residência de dados estrita, mas um container normal não é uma fronteira suficiente para código hostil. A Parte 4 percorre as opções de isolamento para esse caso.

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

Os agents de longa duração usam normalmente três state stores em simultâneo, porque cada um é responsável por um artefacto diferente.

O Git armazena o estado do workspace: o código, os documentos e os ficheiros de progresso alterados pelo agent. Cada commit fornece ao harness um ponto de recuperação estável e à session seguinte um histórico compacto.

A checkpoint database armazena o estado do grafo: o que foi decidido, quais os nós executados, que resultados regressaram e o que deve ser executado em seguida. O artifact store contém outputs finais grandes, como PDFs, ficheiros Parquet e screenshots. Esses artefactos não pertencem ao Git nem à checkpoint database.

Quando usar git como estado

Use git quando o workload tiver forma de código (edições em vários ficheiros, refactors, geração de aplicações) ou forma de documento suficientemente complexa para que o histórico de ficheiros seja relevante. O padrão é simples: crie uma run branch, faça um initializer commit e depois commits em fronteiras significativas: após a configuração, após cada feature, depois de os testes passarem e após a limpeza final. Armazene o SHA do commit mais recente do workspace junto à linha do checkpoint. Ao retomar, o worker seguinte faz checkout da branch, lê git log --oneline -8, inspeciona git status e o diff mais recente e depois lê PROGRESS.md ou o ficheiro de handoff escrito pela session anterior.

Assim, o git torna-se uma superfície de recuperação para o artefacto em edição, e não um substituto da checkpoint DB. O Git pode responder a duas perguntas: o que mudou e qual a versão que passou os testes. Não consegue dizer ao harness que nó do grafo deve ser executado em seguida, qual o tool call que aguarda aprovação ou qual o retry que já utilizou a sua idempotency key. O harness da Anthropic usa initializer commits mais commits por feature como fonte de verdade para a recuperação do workspace; o modelo lê git log --oneline -8 para recuperar o estado. Ignore o git quando o produto do trabalho for uma única resposta conversacional. O overhead não compensa.

Quando usar checkpointing numa DB

Use checkpointing ao estilo de PostgresSaver quando o agent tiver uma estrutura de grafo com vários nós cujo estado intermédio seja relevante (planner → researcher → writer → verifier). O repositório de referência usa-o precisamente por essa razão. Não coloque artefactos de workspace à escala de terabytes no checkpoint; esses devem ir para object storage.

Quando usar um artifact store (S3 / GCS)

Use object storage quando:

• o output for maior do que aquilo que a checkpoint database deve transportar;
• os consumidores a jusante precisarem de um artefacto endereçável por URL sem passarem pelo agent; ou
• o deliverable e o estado da execução tiverem janelas de retenção diferentes.

Por exemplo, pode eliminar o session log após 30 dias, mas manter o relatório final durante anos. Organize o layout por (thread_id, checkpoint_id, artifact_name) para que a execução produtora continue a ser reconstruível.

Quando adicionar gates de aprovação humana

Adicione gates quando o tool call for destrutivo e irreversível (escritas numa DB, movimentação de dinheiro, envio de comunicações externas), quando o tool call sair do blast radius do agent (deploys de produção, publicações destinadas a clientes) ou quando os reguladores exigirem revisão. O interrupt() do LangGraph e o approval middleware do Deep Agents têm suporte incorporado para estes gates. A Parte 4 explicou por que razão estes gates são uma questão de permissões, e não de prompts.

Checklist prática de produção

Antes de colocar em produção um agent de longa duração, responda a estas perguntas em termos concretos de infraestrutura.

1. Que store é responsável pelos eventos da session e pelos checkpoints?
2. O que acontece se o worker morrer a meio de um tool call?
3. Uma execução pode corromper o workspace de outra?
4. Que ações requerem aprovação?
5. O modelo ou o sandbox podem ler credentials em bruto?
6. Que tool calls podem ser repetidos em segurança?
7. Onde é aplicado o limite de custo por execução?
8. Que evaluator com contexto novo decide “done”?
9. Onde vivem os outputs finais depois de o sandbox desaparecer?
10. Amanhã conseguiremos explicar uma execução falhada sem a voltar a executar?

Se a resposta a alguma destas perguntas for “o prompt diz ao agent para ter cuidado”, o sistema ainda não está deployed. Continua a ser uma demo.

A camada seguinte é o loop do harness

Este runtime consegue manter uma execução ativa e recuperável, mas a durabilidade não prova que o trabalho está correto. A Parte 6, Harness Engineering para AI Agents, abre a primitiva harness da tabela acima: como um trace permite saber qual de várias falhas ocorreu, onde vivem as regras de retry e stop, o que um handoff tem de preservar e como uma verificação de aceitação externa decide que uma execução terminou. É também o último artigo da série.

Referências

Textos de engenharia

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

LangGraph e Deep Agents

• Documentação do LangGraph, Persistence.
• Referência do LangGraph, Checkpoints.
• langgraph-checkpoint-postgres no PyPI.
• Documentação da LangChain, Deep Agents overview.
• Blog da LangChain, The runtime behind production Deep Agents.

OpenAI Agents SDK

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

Temporal

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

Plataforma Anthropic

• Anthropic, Claude platform pricing: tarifas por hora de session do Managed Agents.
• anthropics/cwc-long-running-agents: Code with Claude 2026 take-home com evaluator subagent e padrões de progress files.

Sandbox providers

• ZenML, E2B vs Daytona: sandbox comparison for platform engineers.
• Documentação da Daytona, Sandboxes.
• Changelog da Daytona, Sandbox fork and snapshot endpoints.
• Documentação da Modal, Sandboxes.
• Documentação da Modal, Cold start guide.
• Runloop no AWS Marketplace.
• Preços e limites da Vercel Sandbox.

Timeouts e quotas de plataformas cloud

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

Observabilidade

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

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.