Anthropic separa o cérebro da IA das mãos que executam código
Um podcast com os chefes de engenharia e produto da Anthropic detalha a arquitetura que separa o modelo que raciocina do ambiente que roda o código, e por que isso virou questão de segurança e de latência.
· 7 min de leitura
Este artigo foi escrito por Lucas Ferraz. Conteúdo produzido por agente de IA da redação AI Brasil, sob revisão editorial humana. Saiba como produzimos no expediente.
O podcast Latent Space publicou em 27 de outubro de 2026 uma entrevista de mais de uma hora com Katelyn Lesse (chefe de Engenharia) e Angela Jiang (chefe de Produto) da Anthropic, gravada um dia depois do lançamento do Opus 5.5. Para quem só acompanha o anúncio de modelo pelo blog oficial, o episódio abre uma parte que normalmente fica escondida: como a Anthropic constrói, internamente, os agentes que depois viram produto (Claude Code, Claude Platform) usando os mesmos primitivos que expõe para quem paga pela API.
O fio condutor da conversa é uma distinção simples de explicar e difícil de implementar: separar o cérebro do agente (o modelo e o histórico da sessão) das mãos (o ambiente que executa código). A Anthropic chama essa arquitetura de Managed Agents, e ela não é só um detalhe de infraestrutura. Ela muda a latência, a resiliência e a superfície de ataque de qualquer agente construído em cima da API da Claude.
O harness fica, o sandbox vai e volta
No desenho antigo, descrito no episódio, o agente de código inteiro rodava dentro do sandbox, atrás de uma API. Isso significava subir o ambiente de execução e o agente juntos antes de dar a primeira resposta, e significava também que, se o sandbox caísse, o agente inteiro caía com ele. Sessão e execução eram a mesma coisa.
No Managed Agents, o harness (o log da sessão, o estado da conversa, a lógica de orquestração) fica fora do sandbox e persiste independente dele. O ambiente de execução só é criado quando uma tarefa realmente precisa rodar código, e se esse ambiente falhar, a sessão continua: a Anthropic recria o sandbox sem derrubar o agente inteiro. Como escreveu swyx, host do podcast, ao resumir o ponto:
O harness pode persistir enquanto um ambiente de execução é criado quando necessário; um sandbox que falha não precisa derrubar toda a sessão do agente.
The harness can persist while an execution environment is created when needed; a failed sandbox does not have to take the whole agent session with it.swyx, Latent Space
Para quem projeta runtime de agente, essa separação vira uma pergunta prática antes de qualquer linha de código: o que precisa sobreviver a uma falha, o que executa código não confiável, e qual segredo realmente precisa estar presente onde o código roda? A implementação muda de produto para produto, mas as três perguntas valem para qualquer harness caseiro também.
Por que isso também é uma defesa de segurança
A mesma separação resolve um problema de credencial. Se o código gerado pelo modelo roda num sandbox que nunca recebeu a credencial de serviço da aplicação, não existe credencial ali para o código vazar, nem por acidente nem por injeção de prompt. No episódio, a dupla descreve credenciais mantidas fora do sandbox e anexadas por um proxy, com controles sobre para onde o tráfego do sandbox pode ir. O documento público da Anthropic sobre contenção (linkado nas notas do episódio) detalha esse conjunto mais amplo de isolamento usado em todos os produtos da empresa.
| Aspecto | Abordagem anterior | Managed Agents |
|---|---|---|
| Onde roda o agente | Tudo dentro do sandbox, atrás de uma API | Harness fora, sandbox só para execução |
| Latência inicial | Sobe ambiente e agente antes da primeira resposta | Harness responde na hora, sandbox sob demanda |
| Sandbox cai | Agente inteiro cai junto | Sessão continua, sandbox é recriado |
| Credencial de serviço | Podia ficar acessível no ambiente de execução | Fica fora do sandbox, anexada via proxy |
Quem já construiu agente de código com acesso a shell reconhece o problema: é tentador dar ao ambiente de execução a mesma credencial que o resto da aplicação usa, porque é mais simples. A arquitetura descrita no podcast argumenta pelo caminho mais chato de montar (proxy, credencial separada, rede controlada), mas elimina uma classe inteira de vazamento sem precisar confiar no comportamento do modelo.
A proteção contra destilação que pode quebrar seu harness
Uma mudança menos visível do lançamento do Opus 5.5 mexe direto com quem integra a API. A Anthropic reforçou a exigência de preservar os blocos de raciocínio (thinking blocks) entre turnos de conversa, uma resposta direta a um artigo acadêmico, citado no episódio como "Stealing Reasoning Traces from Proprietary LLMs", que mostrou ser possível extrair o raciocínio de modelos proprietários e usar isso para destilar um modelo concorrente mais barato.
O raciocínio por trás é de negócio e de segurança ao mesmo tempo: a Anthropic roda classificadores de segurança sobre os tokens que o modelo produz, e um modelo destilado, rodando sem esses classificadores, perde essa camada de proteção. Mas a consequência prática, admitida no episódio, é que exigir a preservação desses blocos pode quebrar harnesses existentes, principalmente estratégias de compactação de contexto que descartavam ou reescreviam o raciocínio entre chamadas para economizar tokens.
Se o seu agente usa Opus 5.5 e tem uma rotina própria de compactação de histórico, vale testar explicitamente o que acontece quando o bloco de thinking de um turno anterior é reaproveitado no próximo. É o tipo de mudança que não aparece destacada no changelog, mas derruba integração em produção.
Dreaming: memória construída em cima do mesmo primitivo
O Managed Agents também serve de base para experimentos de memória entre sessões, incluindo um recurso que a equipe chama de dreaming. A implementação é mais simples do que o nome sugere: um agente inspeciona o trabalho anterior de outro agente e escreve memórias de volta, usando os mesmos primitivos de sessão e sandbox já descritos. Não é um sistema de memória separado, é uma composição do que já existe.
A dupla também foi direta sobre prioridade: memória e aprendizado continuam importantes, mas boa parte da atenção recente da equipe foi para segurança, à medida que lançar modelo ficou mais difícil. A estratégia declarada é manter o harness base relativamente simples e deixar para quem desenvolve em cima da API experimentar verificadores, agentes em paralelo e outras estratégias. Vale tratar isso como direção, não como promessa de recurso já entregue.
O que isso custa e por que o Claude Platform virou número de S-1
A entrevista foi gravada logo depois de a Anthropic protocolar seu S-1 para abertura de capital, e um dado do próprio arquivamento entrou na conversa: mais de 50% dos clientes com receita anualizada acima de 100 mil dólares usam o Claude Platform, a camada de API e primitivos de agente que a empresa vende para quem constrói produto em cima do modelo. É o mesmo Claude Platform usado internamente para construir o Claude Code, o que os entrevistados chamam de dogfooding.
Sobre preço, o material confirma que o Opus 5.5 custa menos para rodar do que a geração anterior, mas a economia exata depende da carga de trabalho e de quanto ela usa contexto em cache, sem um número fechado de dólar por token divulgado no episódio. Quem decide entre Opus e modelos mais baratos da mesma família ainda precisa rodar a própria conta com os preços publicados no anúncio oficial do Opus 5.5, cruzando intensidade de cache com volume de chamada.
O que muda para quem constrói agente hoje
A entrevista não é um tutorial, mas dá um roteiro de perguntas para quem está desenhando um agente próprio, mesmo sem usar Managed Agents diretamente:
- Separe o que precisa sobreviver a uma falha (o estado da conversa) do que pode ser recriado a qualquer momento (o ambiente de execução)
- Nunca injete a credencial de produção inteira no ambiente onde o código gerado pelo modelo roda; use um proxy com escopo limitado
- Teste explicitamente o comportamento do seu harness quando blocos de raciocínio de turnos anteriores são reaproveitados, antes de trocar de versão de modelo
- Trate avaliação em ambiente próprio, não só benchmark público, como parte do processo de adoção de modelo novo
Um trecho de pseudo-código ilustra a ideia central, como caminho que eu seguiria num agente típico que separa sessão de execução:
# harness: persiste independente do sandbox
session = load_session(session_id)
# sandbox só é criado quando há código para rodar
if task.needs_execution:
sandbox = create_sandbox(network_policy="restricted")
result = sandbox.run(task.code, credentials=None) # sem credencial de serviço
session.append(result)
sandbox.destroy()O ponto não é copiar a implementação exata da Anthropic, que não foi publicada em código aberto, mas aplicar a mesma lógica de separação em qualquer runtime próprio: sessão de um lado, execução descartável do outro, credencial nunca dentro do sandbox.
Fonte: Latent Space

Cobre a parte técnica da inteligência artificial para quem constrói e opera sistemas: desenvolvedores, analistas e times de TI. Compara modelos, mostra o código e o prompt, mede o resultado e diz quanto custa, para o leitor conseguir repetir na própria empresa.