Anthropic diz que agente único roda até 2x mais rápido que times de subagentes

A Anthropic publicou em 25 de outubro de 2026 uma recomendação direta para quem constrói sistemas de agentes de IA (programas que usam um modelo de linguagem para planejar e executar tarefas sozinhos, chamando ferramentas quando precisam): na maioria dos casos, um agente único que carrega contexto sob demanda supera um time de subagentes especializados. A empresa também lançou um kit de migração no GitHub para ajudar equipes a avaliar a troca.

A recomendação não é teórica. Segundo a Anthropic, ela vem da experiência do time de Applied AI em várias implantações corporativas, onde um agente único usando o que a empresa chama de skills (pacotes de instruções e ferramentas reunidos por tarefa, carregados só quando o agente precisa deles) bateu tanto desenhos de prompt monolítico quanto arquiteturas com vários subagentes em qualidade. Em uma comparação citada pela empresa, a versão com agente único rodou cerca de duas vezes mais rápido que a versão com múltiplos subagentes.

O problema que a Anthropic diz ter encontrado

Uma empresa cliente, não identificada, tinha uma dúzia de subagentes especializados dentro do agente que atendia seus clientes. O resultado, segundo a Anthropic, foi inconsistência na experiência de marca e alta latência (tempo de resposta), porque cada troca de um subagente para outro significa perder parte do contexto da conversa.

A Anthropic ilustra isso com um fluxo de desenvolvimento de software: numa arquitetura com vários agentes, um escreve a funcionalidade, outro escreve os testes e um terceiro faz a revisão de código, perdendo contexto a cada passagem. Numa arquitetura de agente único, o mesmo agente escreve a funcionalidade e os testes, porque já tem o contexto completo, e só delega a um verificador separado a tarefa de rodar os testes e reportar o resultado.

A lei de Conway aplicada a agentes

A Anthropic batiza o padrão de "Lei de Conway" para agentes: a arquitetura do sistema acaba copiando o organograma da empresa, com cada time lançando seu próprio subagente até acumular centenas de agentes sobrepostos, sem padrão compartilhado. O resultado é o que a empresa chama de "Frankenprompt": cada time acrescenta regras ao system prompt (o conjunto de instruções que define o comportamento do agente) até elas começarem a se contradizer.

A aposta da Anthropic é que um system prompt limpo, de quatro a cinco ferramentas de dados enxutas e regras fixas de formato de saída cobrem boa parte dos casos de uso. Como exemplo prático, a empresa diz ter cortado o system prompt do Claude Code em mais de 80% nos modelos mais recentes, em parte porque skills e ferramentas agora carregam só quando necessário.

Isso só é possível, segundo a Anthropic, porque modelos mais novos (a partir do Opus 4.5, além do Opus 5.5 e do Fable 5.1) conseguem gerenciar planos complexos num único laço de raciocínio, comentando o próprio progresso e checando o próprio trabalho. Parte da orquestração que antes exigia uma camada de agentes separada agora o próprio modelo resolve sozinho.

Quando manter os subagentes ainda faz sentido

A Anthropic não defende abandonar subagentes em todos os casos. A empresa lista três situações em que eles continuam justificados:

1. Quando a janela de contexto de um agente único mostra degradação de desempenho mensurável.
2. Quando várias tarefas precisam rodar em paralelo, cada uma com sua própria janela de contexto.
3. Quando um agente único tem dificuldade real para escolher entre as ferramentas disponíveis.

Sobre esse último ponto, a Anthropic registra um detalhe técnico relevante para quem já está construindo: a seleção de ferramentas pelo modelo tende a piorar acima de 30 a 50 definições de ferramenta (tool na terminologia de chamadas de função). Isso é um limite prático a considerar antes de empilhar integrações num só agente.

O kit de migração e um alerta sobre cortar errado

Para quem quer avaliar a troca, a Anthropic publicou um kit de migração no GitHub com um fluxo de três etapas: identificar os padrões de arquitetura já existentes no sistema atual, avaliar alternativas de consolidação e verificar se a abordagem escolhida realmente funciona antes de ir para produção.

A empresa avisa que consolidar sem cuidado pode quebrar comportamentos que funcionavam. Em um teste com um agente de suporte, juntar um subagente ao agente principal reduziu a latência, mas quebrou um processo que antes funcionava bem: o agente principal passou a responder sozinho em vez de consultar o especialista certo para aquele tipo de pergunta. É o tipo de regressão que só aparece com teste real, não em benchmark isolado.

Para informações de referência (como guias de estilo, especificações de produto ou definições de métricas), a recomendação é usar bases de conhecimento consultadas sob demanda por uma ferramenta de busca, ou embutidas como arquivos de referência dentro de uma skill. A Anthropic desaconselha explicitamente buscar esse contexto via código e injetá-lo direto no prompt, prática que infla o tamanho do prompt sem necessidade.

O que isso muda para quem constrói agentes

Para times de engenharia que já têm um sistema multiagente em produção, a recomendação da Anthropic é menos um veredito e mais um convite à auditoria: rodar o kit de migração para mapear onde a arquitetura ficou complexa por reflexo organizacional, e não por necessidade técnica real. Vale checar, em especial, quantas definições de ferramenta cada agente carrega hoje: passar de 30 a 50 é um sinal concreto de que a seleção de ferramentas pelo modelo pode estar degradando sem que ninguém tenha notado ainda.

A recomendação da Anthropic também não está isolada. Um estudo da empresa Vals encontrou que times de agentes podem ser mais rápidos que um agente único, mas não entregam qualidade maior: escalar de dez para 30 ou 100 agentes não trouxe ganho de qualidade, só custo significativamente mais alto. Eric Provencher, desenvolvedor da OpenAI, já havia questionado o valor de "enxames" de agentes, chamando-os de "quase certamente" dinheiro desperdiçado.

O ponto prático para quem decide arquitetura hoje é que a complexidade de orquestração que antes precisava ser escrita à mão, com vários agentes especializados e um orquestrador por cima, está sendo absorvida pelos próprios modelos mais recentes. Isso não elimina o trabalho de engenharia, mas desloca ele: menos tempo desenhando fluxos entre agentes, mais tempo cuidando de um system prompt enxuto, de uma biblioteca de skills bem mantida e de testes que peguem regressões antes de produção.

Fonte: The Decoder