Inteligência Artificial
A Anthropic desacoplou o loop de inferência, o sandbox de execução e o log de sessão. A arquitetura resolve dores reais de agentes em produção.
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. A escolha arquitetural que fizeram é a parte mais interessante do anúncio.
Na analogia clássica de infraestrutura, servidores são tratados como pets (únicos, com nome, alimentados à mão) ou como cattle (fungíveis, numerados, abatí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 de forma independente.
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.
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, o que pesa mais, 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.
Cada sandbox é exposto ao modelo como uma ferramenta única: execute(name, input) → string. 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.
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. 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, essa é a mudança que mais pesa.
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 harness e modelo estão amarrados no mesmo binário, você paga esse custo em regressões silenciosas a cada upgrade. Se estão desacoplados, dá para 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. O ponto não é otimizar TTFT em laboratório. É conseguir atualizar o modelo sem refazer integrações.
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 constrói com ferramentas que escondem o log atrá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. Não é paranoia. É a única forma de rodar código gerado por modelo sem criar dívida de segurança que volta 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 de testes, versionamento e observabilidade próprios. 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.
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 é outra. Como esse agente sobrevive a seis upgrades de modelo nos próximos doze meses sem virar um pesadelo operacional? O que a Anthropic publicou é 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 quem 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