Multi-agent é a feature mais demonstrada e menos compreendida da onda agêntica. Demos impressionam: agentes "discutindo", "votando", "revisando uns aos outros". A maior parte dos casos corporativos resolveria mais barato com um agente único e sub-agentes especializados. O que decide se multi-agent agrega valor ou só agrega complexidade é uma pergunta única: existe paralelismo real entre os papéis, ou estou só fragmentando trabalho que cabia num lugar só?
O que é uma equipe de agentes
Sistema multi-agent é uma arquitetura com vários agentes autônomos coordenando pra atingir um objetivo comum. Cada agente tem identidade própria (papel, skills carregadas, ferramentas), executa decisões com autonomia, e se comunica com os outros por protocolo de mensagem estruturada. A coordenação pode ser hierárquica (um coordenador central distribui trabalho) ou peer-to-peer (agentes negociam entre si).
A analogia humana é a de time multi-disciplinar com protocolo de reunião definido. Um time bom não é o que junta gente inteligente; é o que junta gente certa, com papéis estáveis e regra clara de comunicação. Um time ruim é o oposto: gente sobreposta, sem fronteira de responsabilidade, conversando sem critério de parada. Multi-agent reproduz a mesma dinâmica.
A pesquisa pública da Anthropic sobre construir sistemas multi-agente reportou que sistemas bem desenhados podem superar agente único em tarefas que envolvem paralelismo verdadeiro, mas que o ganho exige investimento desproporcional em prompt engineering, orquestração e debugging. O ganho não é gratuito.
Sub-agente e multi-agent não são a mesma coisa
A confusão mais comum é tratar os dois como sinônimo. Eles resolvem problemas relacionados, mas têm estrutura e custo diferentes.
| Critério | Sub-agente | Multi-agent |
|---|---|---|
| Hierarquia | Hierárquico (filho do principal) | Peer-to-peer ou orquestrado por coordenador |
| Ciclo de vida | Curto, tarefa-bound | Pode ser longo, sessão-bound |
| Comunicação | Briefing inicial + retorno consolidado | Múltiplas trocas estruturadas durante a execução |
| Custo de orquestração | Baixo (delegação simples) | Alto (protocolo, resolução de conflito, sincronização) |
| Quando usar | Tarefa atomic e independente | Tarefa que exige especialização interativa entre papéis |
A regra prática: comece com agente único. Se gargalar em contexto, paralelismo ou especialização, adicione sub-agente. Se mesmo com sub-agente o problema persiste e os papéis precisam negociar continuamente entre si, considere multi-agent. Pular direto pra multi-agent é a fonte mais comum de over-engineering em sistema agêntico.
Quando vale: três critérios
Multi-agent agrega valor quando os três critérios abaixo estão presentes simultaneamente. Faltar um costuma ser sinal de que arquitetura mais simples resolveria.
Paralelismo real, não disfarçado. Os papéis precisam fazer trabalho independente que pode rodar simultâneo. Se um papel sempre espera o resultado do outro pra continuar, não é paralelismo, é sequência com protocolo extra. Exemplo de paralelismo real: pesquisa em três fontes diferentes que serão agregadas só no final. Exemplo de sequência disfarçada: revisor que precisa ler cada parágrafo do redator antes de continuar.
Papéis claros e estáveis. Cada agente precisa ter responsabilidade que não se sobrepõe à dos outros, e essa responsabilidade não muda no meio da execução. Papel ambíguo gera retrabalho ("eu pensei que isso era contigo"). Papel mutável gera arquitetura instável que precisa ser repensada a cada novo caso.
Protocolo de comunicação simples. Quanto menor o número de mensagens trocadas pra resolver uma tarefa, melhor. Sistema bom converge em poucas trocas. Sistema ruim entra em loop conversacional, com agentes refinando indefinidamente, sem critério de parada. Protocolo simples tem formato fixo de mensagem, número máximo de turnos, e regra clara de quando parar.
Quando vira teatro: quatro anti-padrões
Sistema multi-agent vira teatro quando otimiza a aparência de inteligência distribuída em vez do resultado. Quatro padrões que sinalizam que a arquitetura está errada.
Agentes que "discutem" sem critério de parada. Demo clássica: três agentes "debatem" um problema. Sem critério explícito de quando parar, podem debater pra sempre. Critério de parada precisa ser tão sério quanto o critério de partida.
Papéis sobrepostos. Se dois agentes têm responsabilidade quase igual, eles vão fazer o mesmo trabalho, ou pior, vão discutir quem faz qual parte. Sobreposição de papel é o equivalente de duas pessoas com o mesmo cargo no mesmo time, sem fronteira clara.
Protocolos chatty. Quando resolver uma tarefa simples exige 30, 50, 100 turnos de conversa entre agentes, o sistema está ineficiente. Custo dispara, latência explode, e o resultado raramente é melhor que um agente único bem desenhado. Protocolo chatty é o cheiro mais forte de multi-agent mal especificado.
Multi-agent usado pra impressionar, não pra resolver. Esse é o anti-padrão executivo: arquitetura escolhida porque vende bem em apresentação, não porque resolve problema concreto. Sintoma: a justificativa começa com "isso é o que está em alta" e não com "isso resolve X que agente único não resolve".
Frameworks de orquestração
O ecossistema de multi-agent maduro tem três frameworks principais, cada um com filosofia diferente. A escolha depende do estilo de orquestração que faz sentido pro caso.
| Framework | Filosofia | Onde brilha |
|---|---|---|
| CrewAI | Papéis explícitos, processo sequencial ou hierárquico | Equipes pequenas com papéis bem definidos (pesquisador, redator, revisor) |
| AutoGen | Conversação livre entre agentes, com supervisor opcional | Cenários exploratórios e negociação peer-to-peer |
| LangGraph | Grafo de estado explícito, orquestração determinística | Fluxos de produção que precisam de controle e auditoria |
A diferença principal entre eles está no nível de explicitação do controle. CrewAI assume papéis e processo. AutoGen permite conversa aberta. LangGraph exige grafo desenhado. Pra produção corporativa, controle explícito quase sempre vale mais que flexibilidade. Pra prototipagem, o oposto.
A pergunta única antes de aprovar piloto multi-agent
Antes de aprovar arquitetura multi-agent, vale fazer uma pergunta única: esse problema seria pior, igual ou melhor com um agente único e sub-agentes?
Se a resposta é "claramente pior sem multi-agent", a arquitetura se justifica. Se a resposta é "igual" ou "talvez um pouco melhor", quase sempre o agente único é a escolha certa. A complexidade adicional do multi-agent só compensa quando ele é a única forma de resolver o problema com qualidade aceitável.
Esta pergunta é complementar ao framework de avaliação de proposta de IA e às limitações da IA generativa na empresa que são herdadas e amplificadas em sistema multi-agent. Cada agente carrega as limitações do modelo subjacente. Quando você tem cinco agentes, você tem cinco janelas de alucinação possíveis, cinco fontes de drift, cinco pontos onde a tarefa pode descarrilhar.
A escolha sensata é começar simples e adicionar complexidade só quando o problema empurrar. Quem começa com multi-agent pra "estar preparado" geralmente termina com sistema que ninguém entende, ninguém debuga, e ninguém audita.
O que vem depois
Subcluster "Anatomia do agente" completo:
- O que é agent harness — a infraestrutura onde a equipe de agentes roda.
- O que são skills em agentes de IA — o que cada agente da equipe carrega como capacidade.
- O que são sub-agentes — pré-requisito conceitual; entender quando sub-agente já resolve evita multi-agent desnecessário.