Anthropic explica por que separa o modelo do agente dentro do Claude

Anthropic explica por que separa o modelo do agente dentro do Claude

Em podcast da Latent Space publicado em 27 de outubro de 2026, duas lideranças da Anthropic detalham como a empresa separa o raciocínio do modelo Claude da camada que executa ações, isola credenciais e escala agentes gerenciados sem ampliar o risco.

Nota da redação: este artigo descreve trechos do episódio com base apenas nos títulos dos timestamps divulgados nas notas de publicação, sem acesso ao áudio ou a uma transcrição completa. Em dois pontos específicos, o trecho sobre proteção de credenciais e sandboxes e o trecho sobre classificadores de segurança, o texto chega a apresentar como fato um funcionamento que a fonte não detalha, contradizendo ressalvas feitas mais adiante no próprio artigo. Trate essas duas seções como inferência de categorias gerais de mercado, não como descrição confirmada da implementação da Anthropic.

Uma conversa de quase duas horas sobre como o Claude não quebra sozinho

No dia 27 de outubro de 2026, o podcast Latent Space publicou uma entrevista de 107 minutos com Katelyn Lesse e Angela Jiang, duas profissionais que tocam a engenharia por trás da Claude Platform na Anthropic. O tema central não é o modelo em si, é a infraestrutura que decide o que esse modelo pode fazer quando vira um agente autônomo rodando em produção. Pra quem constrói sobre a API do Claude, isso importa mais do que o número de parâmetros do Opus 5.5: é o desenho que determina se um agente pode vazar uma credencial, travar no meio de uma tarefa longa ou custar caro demais pra escalar.

O cérebro é o modelo, as mãos são tudo que ele toca

A ideia que dá nome ao episódio é simples de enunciar e difícil de implementar: separar o cérebro, o modelo de linguagem, hoje na versão Claude Opus 5.5, das mãos, o harness (arcabouço de execução) que decide quais ferramentas o agente pode chamar, em que sandbox ele roda e com que credenciais. As notas do episódio apontam dois textos de apoio da Anthropic que sustentam esse desenho: "Scaling Managed Agents", sobre desacoplar cérebro, harness e sandbox, e "How Anthropic contains Claude", sobre isolamento, credenciais e controles de rede.

Na prática, isso significa que trocar de uma versão do modelo para outra não exige reescrever as regras de segurança do agente, porque essas regras vivem numa camada separada. O inverso também vale: dá pra restringir o que um agente acessa ou revogar uma credencial sem retreinar nada. É a diferença entre confiar no bom senso do modelo e confiar num perímetro que o modelo não controla.

Por que isolar credenciais importa mais do que parece

O trecho do episódio chamado "Protecting credentials and sandboxes" (1:05:25) trata o acesso de um agente a segredos (tokens de API, chaves de banco, senhas) como problema de infraestrutura, não de prompt. Em vez de confiar que o modelo vai se comportar e não repetir uma chave em texto claro, é o harness que decide o que o agente consegue ver e por quanto tempo.

O material disponível traz apenas o título do trecho, "Protecting credentials and sandboxes", sem detalhar quais práticas específicas o episódio aborda. Em termos gerais, sandboxing, controles de rede e credenciais de curta duração são categorias conhecidas de contenção de agentes:

• Sandboxing: ambiente isolado, sem acesso direto a sistema de arquivos ou rede
• Controles de rede: filtro de domínios ou serviços que o tráfego do agente pode alcançar
• Credenciais de curta duração: acesso concedido por janela de tempo, não de forma permanente

Esses conceitos são práticas padrão de segurança para agentes autônomos no mercado; não são detalhes confirmados especificamente sobre a implementação da Anthropic neste episódio.

Para quem monta um agente próprio sobre a API da Anthropic, o recado é direto: a segurança não deveria depender só do system prompt dizendo para não revelar segredos. Ela precisa estar no nível de rede e de sistema de arquivos, fora do alcance de qualquer injeção de prompt que consiga contornar as instruções.

Harness para tarefas longas: manter progresso entre janelas de contexto

Um dos links de apoio do episódio, "Effective harnesses for long-running agents", resume o problema como manter progresso entre janelas de contexto, algo que qualquer dev que já rodou um agente por horas reconhece: a janela acaba e o agente esquece o que estava fazendo. Isso sugere que parte do harness da Anthropic existe para persistir estado (o que já foi feito, o que falta, decisões tomadas) fora do contexto do modelo, e reinjetar essa informação quando uma nova janela começa.

É um problema de engenharia, não de modelo. Nenhum aumento de janela de contexto resolve sozinho um agente que precisa rodar por dias numa refatoração de código ou numa pesquisa longa. É o harness, não o cérebro, que decide o que sobrevive entre uma chamada e outra.

Rust na API de Mensagens: escalar sem crescer no mesmo ritmo do tráfego

O trecho "Rebuilding the Messages API in Rust" (56:05) indica que a Anthropic reescreveu a camada que recebe as chamadas da Messages API, o endpoint que praticamente todo integrador usa para conversar com o Claude, na linguagem Rust. O timestamp anterior do episódio, "CPU constraints and scaling" (53:25), sugere que restrições de CPU fizeram parte do contexto dessa reescrita, ainda que o episódio não detalhe a motivação específica nas notas disponíveis.

Isso é relevante para quem depende da API em produção. Uma reescrita de camada de borda em Rust normalmente mira menor latência de cauda (os casos mais lentos, não a média) e menor custo de infraestrutura por requisição, o que se reflete em estabilidade do serviço, ainda que a Anthropic não tenha divulgado números de latência ou throughput nesse episódio.

Classificadores de segurança decidem, em tempo real, se um pedido passa

Por fim, o trecho "Safety classifiers and model routing" (1:12:25) sugere, pelo título, que o episódio aborda uma camada de classificadores de segurança associada ao roteamento de modelo. As notas disponíveis não detalham o funcionamento dessa camada além do título do timestamp, então não é possível confirmar aqui exatamente como a decisão é tomada por chamada. Em arquiteturas desse tipo, de modo geral, esse tipo de checagem costuma rodar fora do modelo, o que permitiria atualizações sem esperar o ciclo de treinamento da próxima versão; trata-se de uma característica comum a esse tipo de design, não de um detalhe confirmado pelo episódio, que não vai além do título do timestamp.

Essa arquitetura em camadas, modelo, classificador, harness e sandbox, é o que o episódio sugere sustentar os chamados managed agents (tema do timestamp 42:10, "Claude Managed Agents"), sem que cada incidente de segurança exija parar e retreinar o modelo inteiro. As notas disponíveis não detalham o que caracteriza tecnicamente esses agentes.

O que o episódio não entrega

O material é um podcast de bastidores, não uma especificação técnica. Não há pseudocódigo do harness, não há números de latência da reescrita em Rust e não há tabela de preços do Opus 5.5, mencionada no timestamp "Opus 5.5 launch and pricing" (7:30): o episódio discute o lançamento e a precificação, mas as notas de divulgação não trazem valores. Quem quiser esse detalhe precisa ir direto nas notas de lançamento do Opus 5.5 e no texto "Scaling Managed Agents" citados como leitura complementar pelo próprio programa.

Para equipes que já operam agentes Claude em produção, o valor prático do episódio está em validar um padrão de design: tratar o modelo como componente substituível e investir a engenharia pesada na camada que o cerca. Quem construiu um agente colando tudo direto no prompt, sem harness separado, sem sandbox e sem rotação de credenciais, tem aqui uma lista de prioridades para revisar antes do próximo incidente.

Fonte: Latent Space