Quem já rodou um agente LLM em produção conhece o padrão: o container trava no meio de uma tarefa longa, a sessão se perde, o cliente recebe uma resposta incompleta e a equipe passa a madrugada reconstituindo o que aconteceu pelos logs. A Anthropic publicou esta semana um post de engenharia descrevendo como o time construiu o Claude Managed Agents para atacar exatamente esse problema — e a escolha arquitetural que fizeram é a parte mais interessante do anúncio.

O problema de agentes que são “pets”

Na analogia clássica de infraestrutura, servidores são tratados como pets (únicos, com nome, alimentados à mão) ou como cattle (fungíveis, numerados, descartáveis). A maior parte dos agentes LLM em produção hoje é construída como pet: um container único roda o loop de inferência, os logs de sessão, as chamadas de ferramenta e o código gerado pelo modelo — tudo junto. Se o container cai, tudo cai com ele.

O time da Anthropic — Lance Martin, Gabe Cemaj e Michael Cohen — descreve a decisão de virtualizar três elementos separadamente: a sessão (log append-only de eventos), o harness (o loop de inferência que conversa com Claude), e o sandbox (o ambiente que executa as ferramentas). Cada um vira cattle. Cada um pode ser reiniciado, substituído ou escalado independentemente.

Se isso soa familiar para quem trabalha com sistemas distribuídos, é porque é. É a mesma lição que o mundo de Kubernetes aprendeu há uma década, aplicada ao novo domínio de agentes.

O que cada peça faz na prática

A sessão é o ponto de verdade. Em vez de comprimir ou truncar contexto de forma irreversível quando ele cresce, o harness persiste cada evento — prompt, tool call, resposta, erro — em um log durável. Quando o modelo precisa de contexto, ele não depende do que sobrou na memória do container: ele chama `getEvents()` e pede exatamente a fatia que interessa. O post captura bem a ideia: “é difícil saber quais tokens os turnos futuros vão precisar”. Colocar o log como storage externo resolve isso sem adivinhação.

O harness é stateless. Como a sessão vive fora do processo, qualquer worker consegue pegar uma sessão onde ela parou. A API é simples: `wake(sessionId)`. Isso permite restarts transparentes, deploys sem downtime, e — mais importante — permite que o harness evolua (novos modelos, novos loops) sem reescrever o histórico.

O sandbox é descartável. Se o container onde Claude está executando código falha, o resultado não é um incidente de sistema. É um erro de tool call que volta para Claude como qualquer outro erro, e o modelo decide se tenta de novo, muda de estratégia ou pede ajuda. Falha de infraestrutura vira matéria-prima para o loop de raciocínio, não uma parada abrupta.

Cada sandbox é exposto ao modelo como uma ferramenta única: `execute(name, input) → string`. Isso significa que Claude pode rotear trabalho entre múltiplos ambientes — um sandbox para código Python, outro para análise de dados em outra VPC, um servidor MCP remoto — sem saber nem se importar onde cada um roda.

Os números que importam

A Anthropic reporta duas melhorias que ajudam a entender por que a arquitetura vale o trabalho.

Time-to-first-token caiu cerca de 60% no p50 e mais de 90% no p95. A razão é simples: containers não são mais provisionados preventivamente para cada sessão. Eles sobem quando Claude efetivamente chama uma ferramenta. Sessões curtas, que dominavam o custo no modelo anterior, praticamente não pagam tempo de cold start.

Credenciais nunca chegam ao sandbox. Tokens OAuth, chaves de API e credenciais de git ficam em um vault, e são injetadas via proxy ou vinculadas a recursos no momento da inicialização. O código que Claude escreve nunca enxerga os segredos. É uma mudança importante para quem leva a sério o fato de que um modelo rodando código arbitrário dentro de um container é, por definição, um vetor de risco interno.

A lição sobre harnesses que envelhecem

Tem um trecho do post que deveria ser citado em toda discussão sobre agentes. O time observou que o mesmo harness, ao migrar de Claude Sonnet 4.5 para Opus 4.5, começou a se comportar pior. O Sonnet 4.5 tinha o que eles chamaram de “ansiedade de contexto” — reduzia a ambição da tarefa conforme o limite de contexto se aproximava. O harness foi projetado para compensar essa ansiedade. O Opus 4.5 não tem o mesmo comportamento, e as compensações viraram sabotagem.

A conclusão é dura: harnesses codificam premissas sobre o que o modelo não consegue fazer sozinho. Cada versão nova do modelo torna um pedaço dessas premissas obsoleto. Se o harness e o modelo estão amarrados no mesmo binário, você paga esse custo em forma de regressões silenciosas a cada upgrade. Se estão desacoplados, você pode testar, rolar para trás, ou adaptar o harness sem tocar na sessão nem no sandbox.

Para quem constrói agentes corporativos, essa é a parte que mais importa. Não é sobre otimizar TTFT em um laboratório — é sobre conseguir atualizar o modelo sem refazer integrações.

O que isso significa para quem vai colocar agentes em produção

Três implicações práticas:

Primeiro, pare de tratar contexto como algo que cabe em uma janela. Se o seu agente precisa compactar histórico para caber no prompt, você está tratando o contexto como memória RAM quando deveria tratá-lo como disco. Logs de sessão estruturados, consultáveis sob demanda, são o padrão que vai ganhar. Quem está construindo com ferramentas que escondem o log por trás de abstrações opacas vai bater no mesmo teto que a Anthropic bateu antes de reescrever.

Segundo, separe credenciais do ambiente de execução desde o primeiro dia. Isso não é paranoia — é a única forma de rodar código gerado por modelo sem criar dívida de segurança que vai voltar em auditoria. O padrão de proxy com vault descrito pela Anthropic é implementável com ferramentas maduras (HashiCorp Vault, AWS Secrets Manager com IAM roles), e deve ser a linha de base.

Terceiro, trate o harness como software de infraestrutura, não como cola descartável. Ele precisa ter testes, versionamento e observabilidade próprios. Ele precisa ser desacoplado o suficiente para sobreviver a três ou quatro trocas de modelo sem reescrita. Se a sua abordagem atual é “um script Python com um loop while”, você está construindo dívida.

Onde isso encosta no trabalho real

A maioria das empresas que pede para a gente construir um agente começa com a pergunta errada: “qual modelo devo usar?”. A pergunta certa é “como meu agente sobrevive a seis upgrades de modelo nos próximos doze meses sem virar um pesadelo operacional?”. O que a Anthropic publicou é essencialmente o blueprint dessa resposta — e confirma decisões que já vínhamos tomando em projetos de agentes corporativos: sessão durável fora do container, harness stateless com wake semântico, sandbox tratado como efêmero, segredos fora do escopo do modelo.

Nem toda empresa precisa reimplementar Managed Agents internamente. Mas todo mundo que vai rodar um agente sério em produção precisa entender por que essa arquitetura existe — e perguntar qual camada da própria stack ainda está presa em um container de estimação esperando para cair.

Leitura recomendada na íntegra no blog de engenharia da Anthropic: Claude Managed Agents: Decoupling Architecture.

Leia também: Como a IA está transformando operações empresariais