Vale a pena orquestrar vários agentes de IA ou um agente só resolve?

Fala aí, beleza? Ninguém olha pra um painel com seis agentes rodando ao mesmo tempo e fica neutro: ou acha insano, ou desconfia que é teatro caro

A promessa é bonita: divide a tarefa, cada agente pega um pedaço, tudo em paralelo, resposta melhor no fim

O outro lado da conta quase nunca aparece no print: contexto duplicado, agente A partindo de uma premissa e agente B de outra, e tu no final revisando tudo pra descobrir quem inventou o quê

Este post não é hype nem anti hype, é um critério de decisão: quando dividir compensa, quando um agente só resolve, e o que as fontes primárias realmente dizem sobre isso

Agente único x múltiplos agentes: comparativo direto

Antes de qualquer arquitetura, se liga na comparação nos eixos que de fato decidem a parada

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 116 aulas
• 4 projetos
• 9h 23min

Conhecer formação

Essa última linha é o coração da coisa, e vale abrir

No harness da Anthropic, cada subagente pode gastar dezenas de milhares de tokens explorando e devolver ao coordenador apenas um resumo condensado, frequentemente de 1.000 a 2.000 tokens

Tem um padrão irmão desse pra evitar o efeito telefone sem fio: os subagentes chamam ferramentas pra armazenar o trabalho em sistemas externos e passam referências leves de volta pro coordenador, em vez de despejar tudo na conversa central

Ou seja: parte do ganho não vem de "vários cérebros", vem de manter a janela principal limpa 🙂

Sinais de que a tarefa é grande demais para um agente só:

Cada sinal aqui é uma pergunta que tu responde sobre a TUA tarefa, não sobre a arquitetura dos outros

A tarefa tem muitas buscas independentes que rodariam em fila?

O exemplo mais concreto que a Anthropic dá é esse: ao identificar todos os membros de conselho das empresas de Tecnologia da Informação do S&P 500, o sistema multi-agente acertou decompondo a tarefa em subagentes, enquanto o agente único falhou com buscas sequenciais lentas

Repara no formato do problema: são N itens que não conversam entre si, e o gargalo é a fila, não o raciocínio

Se a tua tarefa tem essa cara, rodar vários agentes em paralelo deixa de ser luxo e vira o jeito óbvio

A exploração está poluindo a janela de contexto principal?

Se metade do contexto do teu agente é lixo de investigação (arquivo que ele abriu e descartou, busca que não deu em nada), isolar essa parte em um subagente já paga sozinho

Tu precisa restringir o que cada parte pode fazer?

Separar em agentes permite limitar ferramentas por papel: o que só lê, lê; o que escreve, escreve

Dá pra empurrar parte do trabalho pra um modelo mais barato?

Tarefa mecânica não precisa do modelo mais caro, e rotear isso pra um modelo rápido é motivo legítimo pra dividir

Se tu respondeu "não" pra todas, calma que a próxima seção é a tua

Sinais de que um agente só resolve (e orquestrar vai custar caro):

A Anthropic é bem direta em delimitar onde multi-agente NÃO é boa escolha, e vale ler com atenção antes de montar enxame

Domínios que exigem que todos os agentes compartilhem o mesmo contexto, ou que têm muitas dependências entre agentes, não são bons candidatos a multi-agente hoje

E tem uma frase que dói em quem trabalha com código: a maioria das tarefas de código tem menos subtarefas realmente paralelizáveis do que pesquisa, e os agentes ainda não são bons em coordenar e delegar em tempo real

A LangChain relativiza na mesma direção: nem toda tarefa complexa exige multi-agente, e um único agente com as ferramentas e o prompt certos frequentemente entrega resultado similar

E o diagnóstico mais afiado veio da Cognition, no Don’t Build Multi-Agents

O texto defendia um agente único e linear, um passo por vez, e apontava que a falha de sistemas multi-agente sempre desce a contexto faltando: subagentes agindo sobre suposições conflitantes que ninguém estabeleceu antes

É o custo de coordenação em estado puro: cada agente resolveu bem o pedaço dele, partindo de premissas diferentes, e o resultado final não fecha

Os padrões de orquestração que funcionam na prática:

Aqui entra a parte que muita gente perdeu

A própria Cognition atualizou a posição em Multi-Agents: What’s Actually Working (Walden Yan, publicado em 22/04/2026), e essa atualização substitui o texto de 2025

Não é retratação, é refinamento: multi-agente funciona melhor hoje quando as ESCRITAS ficam single-threaded e os agentes adicionais contribuem com inteligência, não com ações

Traduzindo pro nosso dia a dia: só um agente mexe no arquivo, os outros opinam

Os três padrões que eles dizem funcionar na prática:

1. Code-Review-Loop: um revisor com contexto limpo olhando o que foi produzido
2. Smart Friend: um modelo de fronteira consultado pra pegar sutilezas que o agente principal, mais fraco, deixa passar
3. map-reduce-and-manage: um gerente divide o trabalho, os filhos executam, o gerente sintetiza e reporta

E o que fica de fora? Enxames desestruturados de agentes negociando entre si são tratados como distração

Se o terceiro padrão te soou familiar, é porque é o mesmo desenho do padrão supervisor da LangChain: um coordenador central que delega a agentes especializados e sintetiza as saídas

O padrão de revisão tem número, e é o que mais me convenceu: mesmo em PRs escritos pelo próprio Devin, o Devin Review pega em média 2 bugs por PR, dos quais cerca de 58% são severos (erros de lógica, casos de borda faltando, vulnerabilidades de segurança)

E tem o detalhe que muda tudo: a técnica funciona melhor quando o agente que codifica e o que revisa NÃO compartilham contexto antes

Faz sentido, né? Quem escreveu já está convencido do próprio raciocínio 😀

Como isso aparece na prática ao montar multiagentes:

No vídeo abaixo eu monto um fluxo multiagente do zero no n8n, e várias coisas dessas seções apareceram na cara sem eu procurar

Antes, a forma convencional de montar multiagentes ali era criar subfluxos e chamar um workflow a partir do outro, o que separava as coisas e dificultava o debug

Mas eu faço questão de reconhecer a vantagem do formato antigo: o agente separado podia ser reaproveitado por outros agentes, então nem sempre juntar tudo no mesmo fluxo é melhor

No vídeo eu monto um agente orquestrador (com memória e chat model) e adiciono os subagentes como ferramentas dentro do mesmo fluxo

Criei dois: um de pesquisa na internet e outro que consulta uma planilha com vídeos publicados no YouTube

Deixei o prompt de cada subagente ser definido pelo modelo, pro orquestrador montar a instrução do subagente sozinho

Primeiro teste, um simples "oi, tudo bem?": o orquestrador não acionou subagente nenhum e respondeu direto

Isso pra mim é sinal de roteamento inteligente, ele não paga o custo de delegar quando não precisa

Depois perguntei sobre versão do n8n e acompanhei o caminho todo da execução: orquestrador, agente de pesquisa, ferramenta de busca e volta pro orquestrador montar a resposta final

A resposta veio com informação de versão desatualizada, e eu comento isso no próprio vídeo: corrigir esse dado não era o foco da demonstração, o foco era ver o caminho da execução

Aí testei o segundo subagente perguntando por vídeos publicados, e o orquestrador acionou o agente certo, que foi na planilha

E é aqui que eu preciso ser honesto: acertar o roteamento sem NENHUM prompt de orquestração foi sorte

Com mais agentes no fluxo, o orquestrador vai errar o destino, é questão de tempo

A correção foi escrever uma system message no orquestrador listando quais agentes existem e pra que serve cada um, e eu trato isso como passo obrigatório, não opcional

Depois disso refiz os testes: pergunta de versão caiu no agente de pesquisa, pergunta de vídeo caiu no agente da planilha, e conversa fiada não acionou subagente nenhum

Um detalhe que eu gostei: quando o orquestrador ficou em dúvida, ele não chutou um agente, devolveu a pergunta pedindo esclarecimento, o que me deu a deixa pra ajustar o prompt

Ou seja, o custo de coordenação existe e ele tem nome: é o prompt de orquestração que tu vai ter que escrever e manter conforme o fluxo cresce

Se o teu caso é montar isso com mais peças e mais gente usando, eu já falei em detalhe sobre orquestrar agentes de IA no n8n em empresas por lá

Como o Claude Code trata subagentes (e o que isso ensina sobre a decisão):

Dá pra descer da teoria pro ferramental que muita gente aqui usa todo dia, e aqui eu falo do Claude Code, o agente da Anthropic que tu roda no terminal

Ele tem subagentes de fábrica, e o jeito como isso foi desenhado diz muito sobre quando dividir

Os subagentes do Claude Code são arquivos Markdown com frontmatter YAML

Os de usuário ficam em ~/.claude/agents/ e valem em todos os projetos, e os de projeto ficam em .claude/agents/, valendo só naquele projeto e podendo ser compartilhados com o time

Os campos do frontmatter são name, description, tools e model:

---
name: nome-do-subagente
description: quando o Claude deve delegar pra ele
tools: quais ferramentas ele pode usar
model: qual modelo ele roda
---

O description não é enfeite: o Claude usa a description de cada subagente pra decidir quando delegar

É exatamente a mesma lição do meu teste no n8n, só que embutida na ferramenta: a orquestração vive na descrição, não na sorte

E pra que servem, segundo a documentação oficial? Preservar contexto (mantendo exploração e implementação fora da conversa principal), impor restrições limitando quais ferramentas o subagente usa, reaproveitar configurações entre projetos, especializar comportamento com um system prompt focado e controlar custo roteando tarefas pra modelos mais rápidos e baratos como o Haiku

Repara que a lista inteira é sobre contexto, limite e custo… nenhum item promete "mais inteligência por ter mais agentes"

Tome cuidado com um detalhe que pegou gente desprevenida: a partir da v2.1.198 o comando /agents do Claude Code não abre mais o assistente interativo de criação, ele exibe um lembrete pra pedir ao Claude ou editar .claude/agents/ diretamente

Os arquivos, o frontmatter e os diretórios seguem iguais, só o assistente no terminal saiu, e a documentação oficial ainda descrevia o fluxo antigo, o que gerou a issue no repositório do Claude Code

Veredito: vale a pena orquestrar vários agentes?

Vale, mas só quando as três condições batem juntas

Primeira: o valor da tarefa justifica gastar cerca de 15x os tokens de um chat, contra os cerca de 4x de um agente único

Segunda: as subtarefas são de verdade independentes, tipo varrer N itens que não conversam entre si

Terceira: as escritas permanecem em uma linha só, com os agentes extras entrando pra pensar, não pra agir

E tem um dado que eu acho o mais incômodo de todos: nos experimentos da Anthropic, o uso de tokens sozinho explica 80% da variância de desempenho, com número de chamadas de ferramenta e escolha do modelo como os outros dois fatores

Lê de novo devagar

Parte relevante do ganho do multi-agente é gasto convertido em resultado, não mágica de arquitetura

O placar existe e é forte (o sistema multi-agente com Opus 4 como líder e subagentes Sonnet 4 marcou 90,2% de superioridade sobre o agente único Opus 4 na eval interna de pesquisa), mas ele veio junto com a fatura

E pra quem NÃO vale: fluxo com muitas dependências entre etapas e contexto que todo mundo precisa enxergar

Nesse caso, orquestrar só multiplica a chance de dois agentes decidirem coisas incompatíveis e tu pagar a revisão pra descobrir isso

Conclusão

Se eu pudesse te dar um único próximo passo, não seria montar enxame

Seria testar o padrão de menor custo e maior retorno: pega o que o teu agente principal produziu e joga pra um revisor com contexto limpo, sem ele ter acompanhado a construção

Depois mede: o gasto extra virou qualidade de verdade, ou só virou texto bonito?

Começa simples, com um agente, e só divide quando aparecer um sinal da lista (muitas buscas independentes, contexto poluído, necessidade de restringir ferramenta ou de rotear pra modelo mais barato)

E quando dividir, escreve o prompt de orquestração no primeiro dia, não no dia em que o roteamento começar a errar 😀

até o próximo post!