Divida seus agentes por contexto, não por cargo
A maioria dos sistemas multiagente quebra porque a pessoa divide o trabalho como dividiria num time — quem planeja, quem escreve, quem testa. A própria Anthropic chama isso de anti-padrão. Aqui está a divisão que funciona, e a conta que vem junto.
- #agents
- #claude-code
- #architecture
O primeiro sistema multiagente que quase todo mundo monta tem cara de organograma: um agente que planeja, um que implementa, um que testa, passando o trabalho adiante. Parece óbvio que é assim. E é exatamente o formato que a Anthropic aponta como modo de falha — cortar entre planejamento, implementação e teste vira o que eles chamam de telefone sem fio, perdendo contexto em cada passagem.
A regra que entra no lugar: divida por fronteira de contexto, não por fase do problema.
Por que a divisão em organograma falha
Fases de uma mesma tarefa compartilham um único bloco de contexto. Se você corta entre elas, cada passagem precisa espremer esse contexto num resumo — e cada resumo perde algo que o próximo agente precisava. Você não paralelizou nada: colocou compressão com perda entre as etapas e deixou três agentes responsáveis por aquilo que um só já entendia.
Fronteira de contexto é outra coisa. Dois agentes que de fato nunca precisam do material bruto um do outro rodam lado a lado sem perder nada na passagem.
Os três casos que justificam um segundo agente
A orientação da Anthropic lista três. Se a sua tarefa não cai em nenhum deles, um único agente bem equipado é a construção melhor:
- Proteção de contexto — o ruído de uma frente sujaria o raciocínio da outra. Histórico de pedidos não devia estar na janela enquanto um agente faz diagnóstico técnico.
- Paralelização — caminhos de investigação realmente independentes, em que um agente líder abre as frentes e nenhuma precisa ler as outras.
- Especialização — você passou de mais ou menos 20 ferramentas, os domínios conflitam, ou dois trabalhos exigem
system promptsque se contradizem.
O que o dinheiro compra
Às vezes, bastante. O sistema de pesquisa da Anthropic — Opus 4 liderando, subagentes em Sonnet 4 — superou uma instância única de Opus 4 em 90,2% nas avaliações internas de pesquisa. O líder planeja, abre subagentes em paralelo, sintetiza o que volta e entrega tudo para um CitationAgent dedicado, que liga cada afirmação à fonte numa passada própria.
O dimensionamento que eles publicam é menor do que quase todo mundo imagina. Busca simples de fato: 1 agente, de 3 a 10 chamadas de ferramenta. Comparação direta: de 2 a 4 subagentes, de 10 a 15 chamadas cada. Só pesquisa realmente complexa passa de 10 subagentes.
A parte que todo mundo deixa vaga
A lição de engenharia que eles mais repetem não é sobre topologia. É sobre o briefing que você entrega ao subagente. Toda delegação precisa de quatro coisas: um objetivo, um formato de saída, orientação sobre quais ferramentas e fontes usar, e limites explícitos de tarefa. Deixe isso vago e os subagentes duplicam trabalho ou pulam calados justamente aquilo que importava — que é exatamente a falha que leva as pessoas a concluir que multiagente "não funciona".
Minha regra prática: se você não consegue escrever o briefing em quatro linhas cobrindo esses quatro pontos, a tarefa não está pronta pra ser delegada. Isso é problema de especificação, não de arquitetura.
Faça isso hoje
Pegue uma tarefa que você vem tocando numa sessão longa de um agente só e faça uma pergunta: as partes precisam ler o contexto bruto umas das outras? Se precisam, mantenha um agente e dê ferramentas melhores pra ele. Se não precisam, corte exatamente ali — e escreva o briefing de cada lado antes de escrever qualquer configuração.
No Claude Code essa divisão é um arquivo. Coloque um em .claude/agents/ pra um subagente do projeto, ou em ~/.claude/agents/ pra ter em todos. Só name e description são obrigatórios; tools serve pra cercar o que ele pode fazer:
---
name: safe-researcher
description: Research agent with restricted capabilities
tools: Read, Grep, Glob, Bash
---
O corpo do arquivo vira o system prompt daquele subagente — e é o único prompt que ele recebe, junto com detalhes básicos do ambiente, não o seu system prompt principal. Escreva pensando nisso.
Fontes
Continue lendo
Mais guias parecidos com este.
Skill, workflow ou agente? Uma pergunta decide
Muito dev parte pro agente quando um workflow de 20 linhas resolveria mais barato, mais rápido e sem surpresa. Essa é a escada de três níveis, com as definições da própria Anthropic — e a única pergunta que diz qual construir.
Loop engineering: quando você para de dar `prompt` e começa a gerenciar
O Head do Claude Code disse que não dá mais `prompt` — os `loops` dão por ele. Aqui está o que um `loop` é de verdade, as peças que formam um, e um roteiro pra colar e rodar o seu primeiro sem escrever código.
Construa seu primeiro agente de IA (sem o hype)
Um agente não é um trabalhador autônomo mágico — é um loop com ferramentas e um objetivo. Aqui vão três portas de entrada reais, do agente gerenciado sem instalação ao que roda 24/7 no seu próprio hardware, e como escolher por onde começar esta semana.