Orquestração multi-agente: quando vale e quando é peso morto

Em 12 de junho de 2025, a Cognition publicou um texto chamado Don't Build Multi-Agents.

No dia seguinte, a Anthropic publicou como tinha construído um sistema multi-agente que superava o agente único em 90,2%.

Vinte e quatro horas de intervalo, duas empresas sérias, posições opostas. E as duas estão certas. Isso só fica claro quando você olha o que os agentes de cada caso estavam fazendo.

Este post é sobre a regra que reconcilia as duas, e sobre o que a medição de 2026 fez com a discussão. É um capítulo da série sobre engenharia de harness, e o único em que a resposta certa costuma ser "não faça".

As duas publicações mediram coisas diferentes com o mesmo nome.

A Cognition, pela mão de Walden Yan, argumentou que sistemas multi-agente ficam frágeis por dois motivos: o contexto é compartilhado mal entre os agentes, e decisões tomadas em paralelo entram em conflito. A conclusão prática era direta — não construa.

A Anthropic descreveu o caminho oposto. O sistema de pesquisa deles usa um agente líder em Claude Opus 4 que delega a subagentes em Claude Sonnet 4, e essa configuração superou o Opus 4 sozinho em 90,2% na avaliação interna de pesquisa (Anthropic, 13 de junho de 2025).

Quem lê só uma das duas sai convicto. Quem lê as duas fica sem saber o que fazer. A saída não é escolher um lado: é olhar o que estava sendo delegado em cada caso.

Os 90,2% viajaram o mundo. A ressalva, publicada no mesmo texto e a poucos parágrafos de distância, não viajou.

A Anthropic lista explicitamente onde o padrão multi-agente vai mal:

• Tarefas em que todos os agentes precisam do mesmo contexto.
• Domínios com dependências pesadas entre as partes.
• A maior parte das tarefas de programação.
• Situações que exigem coordenação e delegação em tempo real.

O terceiro item é o que importa para quem lê este blog. A empresa que publicou o caso de sucesso mais citado da área diz, no próprio texto, que ele não se aplica a codificar.

Os modos de falha que eles observaram construindo o sistema merecem registro, porque são concretos e reconhecíveis: agentes criando mais de 50 subagentes para consultas simples, busca infinita por fontes que não existem, trabalho duplicado por instrução vaga, preferência por conteúdo de fazenda de SEO em vez de fonte autoritativa, e execução sequencial onde cabia paralela.

Uma distinção antes de seguir. Este post trata do sistema: quando compor vários agentes e quando não. A mecânica de uma peça só, com arquivo de configuração, isolamento de contexto e fork, está em quando delegar a um subagente. São decisões de níveis diferentes, e misturar as duas é parte do problema.

<!-- [UNIQUE INSIGHT] -->

As duas posições param de se contradizer quando você pergunta o que cada agente estava fazendo com o resultado.

Os subagentes da Anthropic liam. Cada um buscava fontes, em paralelo, sem escrever nada que os outros precisassem enxergar, e devolvia um resumo ao líder. Não existe estado compartilhado para entrar em conflito, porque ninguém escreve no mesmo lugar.

Os casos que a Cognition descreve são de agentes que escrevem. Dois agentes editando o mesmo projeto tomam decisões incompatíveis sem saber, e o conflito só aparece depois, montado.

Daí sai a regra:

Isso explica a exclusão que a Anthropic faz sem precisar de nenhuma teoria adicional. Código é escrita em estado compartilhado por definição: dois agentes mexendo no mesmo repositório disputam os mesmos arquivos, as mesmas interfaces e as mesmas decisões de projeto.

O argumento da Cognition, no fundo, é de contexto: o mesmo problema que faz um agente sozinho perder o fio, tratado em por que seu agente esquece. Em multi-agente ele não some: multiplica.

Um trabalho de abril de 2026 testou a pergunta de forma direta: vale a pena colocar um orquestrador externo sobre o modelo, ou basta escrever o procedimento no prompt?

In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks, de Dennis, Diamond, Patil, Shabahang e Guo, comparou as duas abordagens em três fluxos procedurais: reserva de viagem com 14 nós, suporte técnico do Zoom com 14 nós e processamento de sinistro de seguro com 55 nós. Foram 200 conversas por condição, avaliadas por LLM-como-juiz em cinco critérios (arXiv 2604.27891, 30 de abril de 2026).

O prompt em contexto ganhou nos três, com notas de 4,53 a 5,00 contra 4,17 a 4,84. Mas o resultado que interessa é o de falha.

Em todos os três, o orquestrador aumentou a falha, e nos dois primeiros a diferença passa do dobro. A camada que existia para dar confiabilidade tirou confiabilidade.

Uma delimitação honesta: o estudo é de tarefas procedurais, com passos conhecidos de antemão. Ele não diz nada sobre pesquisa aberta, que é justamente onde o caso da Anthropic vive. As duas evidências convivem, e é a regra da seção anterior que separa uma da outra.

A falha de multi-agente já foi mapeada com método, e o resultado contraria o senso comum de que o problema é coordenação.

O trabalho Why Do Multi-Agent LLM Systems Fail?, encabeçado por Mert Cemri e Melissa Pan e com Matei Zaharia, Joseph Gonzalez e Ion Stoica entre os treze autores, anotou 1.642 traços de execução em sete frameworks e derivou uma taxonomia de 14 modos de falha, com concordância entre anotadores de 0,88 (arXiv 2503.13657, março de 2025, revisto em outubro).

A maior fatia não é coordenação: é desenho. Especificação ambígua, papéis mal definidos, fluxo que não fecha. O sistema já nasce errado, e os agentes apenas executam o erro em paralelo.

Duas correções valem aqui, porque o resumo desse paper circula distorcido. Os frameworks estudados foram ChatDev, MetaGPT, HyperAgent, AppWorld, AG2, Magentic-One e OpenManus — CrewAI e LangGraph não estavam no estudo, ao contrário do que vários textos afirmam. E os percentuais que circulam (36,94% e 21,3%) não são os do paper.

O abstract também abre com uma frase que raramente é citada: apesar do entusiasmo, os ganhos desses sistemas nos benchmarks populares são em geral mínimos. E fecha dizendo que as falhas encontradas exigem soluções mais sofisticadas — ou seja, prompt melhor não resolve.

A categoria de verificação, terceira em tamanho, tem tratamento próprio: é o mesmo limite descrito em por que o agente não revisa o próprio trabalho. E descobrir em qual das três categorias você caiu exige rastro, que é o assunto de instrumentar o que não se reproduz.

O debate polarizado de 2025 não terminou com vitória de um lado. Terminou num padrão estreito, que as duas partes hoje praticam.

O formato que se firmou tem três características:

1. Um orquestrador único é dono do contexto contínuo. Não há dois donos.
2. Os subagentes são efêmeros: nascem para uma subtarefa e morrem nela.
3. Eles são somente-leitura e devolvem resumos comprimidos, em vez de escrever no estado principal.

Repare que isso é exatamente a regra da terceira seção, implementada. Leitura em paralelo, escrita concentrada num lugar só. O padrão não foi escolhido por elegância: foi o que sobrou depois que as outras configurações falharam.

O que "efêmero e somente-leitura" quer dizer no código

As três características acima costumam ser lidas como recomendação vaga. Elas têm tradução direta.

Efêmero significa que o subagente não guarda estado entre chamadas. Ele recebe a subtarefa, o contexto mínimo para executá-la e nada mais. Não tem memória da sessão, não sabe o que os outros estão fazendo e não precisa saber. Quando termina, o que sobra dele é o texto que devolveu.

Somente-leitura significa que ele não tem, no conjunto de ferramentas, nada que escreva no estado principal. Não é uma instrução no prompt pedindo cuidado: é a ausência da ferramenta. Se o subagente não pode chamar a função que grava, ele não grava, independentemente do que decida.

Resumo comprimido significa que o retorno é menor que a entrada. Um subagente que devolve tudo que leu não resolveu nada, apenas moveu o problema de contexto para o orquestrador. O ganho está justamente em ele ler muito e devolver pouco.

A verificação de que o padrão está correto é simples: se dois subagentes rodando ao mesmo tempo pudessem produzir um conflito, algum deles escreve em estado compartilhado, e o desenho ainda não está pronto.

Uma confusão de camadas atrapalha aqui. Um sistema com vários agentes precisa de um jeito de eles conversarem, e isso é protocolo — assunto de o mapa dos protocolos de agente. Ter o protocolo resolvido não responde se você deveria ter vários agentes.

Antes de qualquer discussão de arquitetura, existe uma conta que elimina metade dos casos.

Segundo a Anthropic, um agente consome cerca de 4× mais tokens que uma interação de chat. Um sistema multi-agente consome cerca de 15×.

Quinze vezes é um multiplicador que só se paga quando o ganho é grande e mensurável. No caso da Anthropic era: 90,2% numa tarefa que a empresa roda em escala. Num fluxo interno que já funciona com um agente, dificilmente é.

Onde esse custo vaza em produção, e o que fazer com ele, está em onde o dinheiro vaza em produção. Aqui basta o efeito: multi-agente transforma um problema de arquitetura num problema de orçamento.

A Gartner projeta que mais de 40% dos projetos de IA agêntica serão cancelados até o fim de 2027, e lista três causas: custo crescente, valor de negócio pouco claro e controles de risco insuficientes (Gartner, 25 de junho de 2025). A primeira causa é a desta seção.

A mesma análise estima que, entre os milhares de fornecedores que se dizem agênticos, cerca de 130 são de fato. O resto é rebranding de produto que já existia. Convém ter isso em mente ao ler comparativo de framework escrito por quem vende framework.

Três perguntas, nesta ordem. Se a primeira falhar, as outras não importam.

1. A tarefa se divide em partes independentes? Se as partes precisam conversar durante a execução, ou se todas precisam do contexto inteiro, pare aqui. Não é caso de multi-agente.

2. As partes leem ou escrevem? Leitura em paralelo é o caso que funciona. Escrita no mesmo estado é o caso que quebra. Se houver escrita, concentre num agente só e deixe os outros lendo.

3. Você consegue medir se melhorou? Sem uma avaliação da tarefa real, você não vai saber se os 15× compraram alguma coisa. O método está em avaliar agente na tarefa real, e ele precisa existir antes da migração, não depois.

Um alerta sobre a ordem. A maior categoria de falha do MAST é desenho do sistema, e desenho é o que se decide agora, respondendo essas três perguntas. Escolher framework antes disso é decidir a ferramenta antes do problema.

O caminho de volta, se você já migrou

Desmontar um sistema multi-agente inteiro raramente é necessário. O ajuste que costuma resolver é mais barato, e segue a mesma regra.

Comece identificando quem escreve. Liste cada agente e a lista de ferramentas dele, e marque todas as que alteram estado: gravar arquivo, chamar API que modifica, atualizar registro. Se dois agentes ou mais aparecem nessa lista, esse é o ponto de conflito, e é ali que os erros incompreensíveis nascem.

Depois concentre a escrita. Escolha um agente para ser o dono do estado e tire dos demais as ferramentas que alteram. Eles continuam existindo, continuam rodando em paralelo, mas passam a devolver texto em vez de agir.

Por fim meça de novo. Se o acerto subir e o custo cair, o problema era o desenho, e não a quantidade de agentes. Se nada mudar, a tarefa provavelmente não se dividia, e um agente só resolve com menos peça móvel.

<!-- [PERSONAL EXPERIENCE] -->

A produção destes textos usa as duas configurações, e a divisão segue a regra deste post sem que eu tivesse planejado assim.

A etapa de pesquisa é multi-agente por natureza: buscar cinco fontes primárias diferentes são cinco leituras independentes, que não se afetam, e cada uma volta como um resumo verificado. É o caso da Anthropic em miniatura — leitura, paralela, sem estado comum.

A escrita não. O texto é um estado compartilhado, e um post escrito por dois agentes em paralelo produziria exatamente o que a Cognition descreve: duas decisões de estrutura incompatíveis, descobertas na montagem. Aqui há um agente só, do começo ao fim.

O julgamento explícito, então: eu não recomendaria migrar um fluxo de escrita para multi-agente hoje, por mais tentador que o paralelismo pareça. E a parte incômoda é que a tentação é real — a pesquisa fica visivelmente mais rápida com paralelismo, e é fácil concluir daí que a escrita também ficaria. Não fica: são operações de naturezas diferentes, e o ganho de uma não transfere para a outra.

Multi-agente é melhor que um agente só?

Depende do que as partes fazem. Num caso de pesquisa medido pela Anthropic, o sistema multi-agente superou o agente único em 90,2%. Em três fluxos procedurais medidos em 2026, colocar um orquestrador externo quase dobrou a taxa de falha. A regra prática: multi-agente ajuda quando as subtarefas leem em paralelo e atrapalha quando escrevem no mesmo estado.

Vale a pena usar CrewAI ou LangGraph?

A pergunta vem antes do framework. Se a tarefa não se divide em partes independentes de leitura, nenhum framework resolve. A maior categoria de falha catalogada pelo MAST é desenho do sistema, com 43,9%, e não a ferramenta. Vale notar que nem CrewAI nem LangGraph estavam entre os sete frameworks estudados nesse trabalho, ao contrário do que muitos resumos afirmam.

Por que meu sistema multi-agente falha?

O MAST anotou 1.642 traços de execução e agrupou as falhas em três categorias: desenho do sistema (43,9%), desalinhamento entre agentes (31,4%) e verificação de tarefa (23,5%). Comece pela primeira: especificação ambígua e papéis mal definidos respondem por mais falhas do que problemas de coordenação.

Quanto custa a mais rodar multi-agente?

Cerca de 15 vezes um chat, contra cerca de 4 vezes de um agente único, segundo a Anthropic. É um multiplicador que só se justifica com ganho grande e medido. A Gartner projeta mais de 40% de cancelamento em projetos agênticos até o fim de 2027, e custo crescente é a primeira causa que ela lista.

Multi-agente serve para programar?

A própria Anthropic diz que não, na maior parte dos casos. O texto que descreve o sistema multi-agente deles exclui explicitamente tarefas que exigem contexto compartilhado, dependências pesadas e a maior parte das tarefas de programação. Código é escrita em estado compartilhado, que é o caso em que o padrão quebra.

E se eu já construí um?

Antes de desmontar, meça. Rode a mesma tarefa nas duas configurações e compare acerto, tempo e custo. Se o ganho não aparecer, a migração mais barata costuma ser manter um orquestrador dono do contexto e transformar os demais agentes em leitores efêmeros que devolvem um resumo. É o padrão em que a área convergiu.

• Cognition e Anthropic publicaram o oposto com um dia de diferença, e as duas mediram tarefas diferentes.
• Os 90,2% são reais e vieram de pesquisa. O mesmo texto exclui a maior parte da programação.
• Em tarefa procedural, o orquestrador externo piorou a falha nos três fluxos medidos.
• A regra: leitura em paralelo paga, escrita compartilhada cobra.
• A maior causa de falha é desenho do sistema, com 43,9%, não coordenação.
• 15× o custo de um chat. Só se paga com ganho medido.

Antes de escolher entre CrewAI e LangGraph, responda se a sua tarefa se divide em leituras independentes. Se não se divide, a resposta certa é um agente só — e essa decisão vale mais que qualquer framework.