Arquitetura Multi-Agente: Dividir no Escuro Vai Sair Caro

“Dividir meu agente em vários vai deixar ele mais inteligente?”

A resposta é “depende”. Pesquisas da Anthropic mostram que sistemas multi-agente podem superar agentes individuais em até 90% - mas só quando a arquitetura certa é escolhida. Na prática, a diferença de desempenho varia drasticamente dependendo do tipo de tarefa que você está resolvendo.

Aqui vão três cenários representativos que revelam quando cada padrão realmente entrega resultado.

Os Quatro Padrões em Resumo

Antes de entrar nos cenários, um panorama rápido das arquiteturas:

• Subagentes: Um agente principal invoca agentes especializados como ferramentas. Forte em execução paralela, mas todo resultado precisa voltar pelo agente principal
• Skills: Um único agente carrega prompts especializados sob demanda. Leve, mas o contexto vai acumulando ao longo do tempo
• Handoffs: O agente ativo é trocado a cada etapa. Feito sob medida para fluxos sequenciais, mas não consegue rodar tarefas em paralelo
• Router: Classifica consultas, despacha em paralelo e agrega resultados. Stateless - nenhum contexto de conversação é mantido

Agora vamos ver como cada um se comporta em cenários reais.

Cenário 1: Requisições Pontuais

Imagine que o usuário diz “Compra um café pra mim” - uma única requisição em que um agente especializado pode chamar uma ferramenta buy_coffee.

Comparação de desempenho:

• Subagentes: 4 chamadas (principal → sub → execução da ferramenta → retorno ao principal → resposta)
• Skills / Handoffs / Router: 3 chamadas (execução direta)

O ponto-chave: Tarefas pontuais não precisam de gerenciamento de estado, então Skills, Handoffs e Router são os mais eficientes. Subagentes adicionam uma ida e volta extra pelo agente principal, e isso se traduz diretamente em latência. Para tarefas simples, não faz sentido montar uma arquitetura multi-agente.

Na prática: Bots de FAQ, execução de comandos simples e consultas pontuais a dados funcionam perfeitamente bem com um único agente. Multi-agente aqui é over-engineering.

Cenário 2: Requisições Repetidas

Agora o usuário diz “Compra mais um café” - a mesma requisição feita duas vezes. O contexto da conversa é carregado entre as interações.

Comparação de desempenho (segundo turno):

• Subagentes: 4 chamadas → 8 no total (stateless, ciclo completo toda vez)
• Skills / Handoffs: 2 chamadas → 5 no total (redução de 40%)
• Router: 3 chamadas → 6 no total (redução de 25%)

O ponto-chave: Padrões com estado - Skills e Handoffs - dominam aqui. Eles reutilizam o contexto já carregado e pulam completamente as etapas de roteamento e inicialização. Subagentes, stateless por design, repetem o ciclo inteiro toda vez. A contrapartida é que subagentes oferecem melhor isolamento de contexto - o que compensa o overhead quando segurança ou sandboxing são prioridade.

Na prática: Chatbots, assistentes conversacionais e serviços baseados em sessão precisam de padrões com estado. Se os usuários frequentemente dizem coisas como “faz do mesmo jeito de antes”, priorize Skills ou Handoffs. Um Router pode ser encapsulado dentro de um agente com estado como ferramenta, se necessário.

Cenário 3: Consultas Multi-Domínio

O usuário pergunta “Compare Python, JavaScript e Rust” - uma consulta que cruza vários domínios especializados. Considere aproximadamente 2 mil tokens de documentação de referência por linguagem.

Comparação de desempenho:

• Subagentes: 5 chamadas, ~9 mil tokens (cada sub trabalha em contexto isolado)
• Skills: 3 chamadas, ~15 mil tokens (os contextos dos três skills se acumulam no principal)
• Handoffs: 7+ chamadas, ~14 mil+ tokens (apenas execução sequencial)
• Router: 5 chamadas, ~9 mil tokens (execução paralela)

O ponto-chave: Padrões com execução paralela - Subagentes e Router - vencem de forma decisiva. Subagentes processam a documentação de cada linguagem em contextos isolados, usando 67% menos tokens que Skills (9 mil vs 15 mil). Skills fazem menos chamadas, mas empilham o conhecimento dos três domínios no contexto principal, fazendo o custo de tokens disparar. Handoffs, limitados à execução sequencial, são a pior escolha para esse tipo de trabalho.

Na prática: Sistemas de pesquisa, análises comparativas de múltiplas fontes e bases de conhecimento corporativas que consultam vários domínios independentes simultaneamente pedem Subagentes ou Router. Quando se lida com grandes volumes de conhecimento por domínio, o isolamento de contexto impacta diretamente no custo de tokens.

Guia de Seleção de Padrões

Cenário	Padrão Recomendado
Tarefas pontuais	Um único agente é suficiente
Requisições repetidas com frequência	Skills ou Handoffs
Múltiplos domínios consultados ao mesmo tempo	Subagentes ou Router
Fluxos de trabalho sequenciais	Handoffs

Uma Dica Prática a Mais

Não comece com multi-agente. Comece com um único agente bem configurado, com bons prompts e ferramentas bem definidas. Só parta para padrões multi-agente quando esbarrar numa limitação clara - e aí use os cenários acima para escolher o padrão certo.

A lição da pesquisa da Anthropic não é “mais agentes = melhor”. É que a arquitetura certa para a tarefa certa é o que entrega aquela melhoria de 90%.