No capítulo anterior, tratamos de conectar ferramentas externas por MCP a um único agente. Até aqui, você já tem um agente autônomo funcionando, com "cabeça, ferramentas, memória e laço". Só que, quando o trabalho cresce, o desenho de enfiar tudo em um único agente em algum ponto desmorona. Neste capítulo, organizamos — em nível conceitual, sem depender de framework — o "desenho multiagente", que resolve dividindo papéis entre vários agentes, e a forma de pensar essa coordenação (A2A: Agent-to-Agent).
A meta é saber julgar "quando e como dividir para ficar mais forte"
Quando um agente já não basta
Um único agente é simples, tem visão clara e é fácil de acompanhar — por isso, começar com um agente é o certo. O problema surge quando você vai empilhando papéis nele. Ao enfiar responsabilidades em um só prompt — "investigue, escreva, revise, traduza e ainda publique…" —, a partir de certo ponto a precisão começa a cair de repente.
As causas são principalmente 3. ① As instruções ficam longas e vagas (quanto mais "isto e aquilo" você escreve, mais o modelo hesita sobre o que priorizar). ② O contexto incha (ele carrega até informação irrelevante, e a instrução essencial se dilui). ③ Há ferramentas demais (quanto mais opções, mais fácil escolher a ferramenta errada). Um agente sobrecarregado é como "um escritório em que uma pessoa acumula vários papéis e vira o caos".
💡 A virada de mentalidade. Em vez de continuar deixando um agente mais esperto, mude para a ideia de "fazer vários agentes pequenos, cada um focado em um papel, cooperarem". Esse é o ponto de partida do desenho multiagente. Pela mesma lógica da divisão de trabalho numa organização humana, quanto mais estreita e clara a responsabilidade de cada um, mais estável fica o todo.
Contudo — dividir não melhora sempre. A divisão de trabalho traz consigo um custo de coordenação. Por isso, o tema central deste capítulo não é só "como dividir", mas discernir "se se deve, afinal, dividir". Vejamos primeiro as 3 formas representativas e depois passemos ao critério de decisão.
Os 3 padrões básicos
As configurações multiagente são infinitas no papel, mas o esqueleto que aparece repetidamente na prática se resume a 3. Combinando esses 3, dá para explicar quase qualquer configuração. Vamos captar um a um, com papel e adequação.
O pai (orquestrador) faz o plano geral, distribui tarefas aos filhos (trabalhadores) para executarem e reúne e integra os resultados. Os filhos não se conhecem entre si; olham só para o pai. A força é ser centralizado e fácil de controlar.
Quando usar: a tarefa dá para dividir e você quer rodar em paralelo.
Enfileira etapas e passa a saída do agente anterior como entrada do próximo, em ordem. Por exemplo, "pesquisa → redação → revisão". Como cada estágio cuida de uma só etapa, a responsabilidade é nítida e a verificação, fácil.
Quando usar: o procedimento é linear e os estágios estão definidos.
Como "responsável por pesquisa", "por código", "por revisão", prepara agentes especialistas, cada um com sua área forte, e os aciona conforme a situação. Como dá para restringir a instrução e as ferramentas de cada um, a especialização sobe.
Quando usar: as capacidades exigidas diferem muito de domínio para domínio.
Esses 3 não são excludentes. Um sistema real costuma virar uma estrutura aninhada, como "um orquestrador conduz trabalhadores do tipo especialista, e um deles é um pipeline". A forma mais gerenciável de montar é decidir primeiro um único esqueleto na camada mais externa e usar outro padrão por dentro só nos pontos necessários.
📊 Na dúvida, comece pelo ①. O mais versátil dos 3 é o orquestrador + trabalhadores. Como o pai concentra planejamento e integração no centro, é fácil de controlar e vira a forma básica de muitas configurações multiagente. Para uma visão geral dos padrões, veja também O que é multiagente; para captá-lo como sistema, O que é um sistema multiagente.
Quando dividir e quando não
Conhecendo os padrões, dá vontade de dividir tudo. Mas a divisão de trabalho sempre custa "coordenação" — o esforço de passar informação, encaixar e sincronizar entre agentes. Só quando o ganho da divisão supera esse custo de coordenação é que o multiagente é a resposta certa. Vejamos primeiro os dois lados lado a lado.
- Dá para paralelizar: rodar subtarefas independentes ao mesmo tempo e encurtar o tempo
- Exige especialização: restringir instrução e ferramentas por domínio eleva a precisão
- A exploração é ampla: quer procurar vários pontos de vista ou candidatos em paralelo
- Quer separar contextos: cortar o contexto por papel e evitar a mistura
- É simples por natureza: complica sem necessidade um processamento que um agente resolve
- O custo aumenta: quanto mais agentes, mais se acumulam chamadas de LLM e tokens
- A coordenação pesa: o esforço de repasse e sincronização devora o ganho da divisão
- Forte dependência sequencial: depende muito do resultado anterior e quase não há espaço para paralelismo
⚠️ Pergunte primeiro "um agente basta?". O multiagente é poderoso, mas não é o que se escolhe de primeira. A regra de ouro é subir os degraus: um agente → refinar o prompt → adicionar ferramentas → se ainda faltar, dividir. Só adicione complexidade depois de confirmar "se o agente atual está realmente no limite". A divisão dá para fazer depois.
Como critério prático, imagine "se, ao explicar aquele papel a um colega humano, ele caberia naturalmente na descrição de cargo de uma única pessoa". Se dá para escrever com um só cargo, um agente ainda basta. O momento em que você quer transformar em pessoas diferentes — "este é o da pesquisa, este é o da redação" — é a hora de considerar a divisão. Para a visão completa da decisão, veja também Como construir um sistema multiagente.
Cooperação entre agentes (A2A)
Decidido dividir, o próximo desafio de desenho é "como os agentes trocam informação entre si". Numa equipe humana, equivale a definir o formato do documento de passagem e as regras de reporte. Se isso for vago, por melhores que sejam os indivíduos, o todo não engrena. Há basicamente 2 pontos a fixar na cooperação.
Defina o que passar e em que formato. Transformar em acordo explícito "a instrução da tarefa, a entrada necessária e o formato de saída esperado" evita que o receptor se perca. Um repasse estruturado é mais estável do que jogar texto livre.
A etapa de reunir várias saídas em uma. Decida de antemão quem tem a responsabilidade final pela integração. Inclua no desenho a prioridade quando os resultados se contradizem e o modo de reunir (resumo, cotejo, voto majoritário).
O movimento de tratar essa ideia de "agentes dividirem papéis e cooperarem" de forma mais padronizada é o A2A (Agent-to-Agent). Enquanto o MCP do capítulo anterior era o acordo que conecta "agente ↔ ferramentas/dados", o A2A é o acordo que conecta "agente ↔ agente" — entenda-o como a etiqueta comum para saber o que o outro agente sabe fazer, delegar-lhe uma tarefa e receber o resultado.
💡 Memorize MCP e A2A em contraste. Em resumo, MCP = conectar "mãos" ao agente; A2A = "conectar" agentes entre si. O primeiro é conexão de ferramentas e dados; o segundo, a etiqueta da cooperação. Basta fixá-los como conceito por ora, e os protocolos concretos serão retomados nos próximos capítulos. Para mais detalhes, consulte O que é o protocolo A2A. Ler em paralelo com MCP e conexão de ferramentas do capítulo anterior deixa a diferença clara.
O importante não é decorar o nome do protocolo, mas a postura de desenho de que "a cooperação exige acordos explícitos". Quem detém qual tarefa, com que entrada começa, o que devolve e, se falhar, para quem volta — decidir esses acordos de antemão é o alicerce de um sistema que não desmorona à medida que a escala cresce.
Gestão de contexto e de custo
O maior risco prático do multiagente é a explosão de contexto e de custo. Quanto mais agentes e quanto mais trocam informação entre si, mais o contexto que cada um carrega engorda e mais se acumulam o número de chamadas de LLM e o volume de tokens. Sem cuidado, o sistema tende a ficar lento, caro e instável. Segure as rédeas já na fase de desenho.
Ao filho, passe só o necessário para aquela tarefa. Não despeje o histórico inteiro. Contexto irrelevante também derruba a precisão.
Passe adiante resumindo ao essencial os resultados longos. A ideia é entregar "conclusão e evidências", não o log bruto.
Imponha um teto ao número de filhos rodando ao mesmo tempo. Aumentar sem limite desmorona por custo e rate limit.
Use modelos de porte diferente para o pai de raciocínio pesado e os filhos de trabalho simples. Não coloque o modelo de topo em tudo.
Restringir o que passa é, em especial, uma decisão de desenho de grande efeito. No tipo orquestrador + trabalhadores, o pai tem o panorama, mas ao filho só se passa a tarefa recortada e a entrada mínima. Quanto menor o contexto que o filho carrega, mais sobe a precisão e mais cai o custo. Entenda isso como a ideia de context engineering, vista nos capítulos anteriores, estendida a vários agentes.
⚠️ O custo age como "nº de agentes × nº de passos". Adicionar um agente empilha chamadas na medida do número de voltas do laço. Atenção ao ponto de que quanto mais agentes, mais o desperdício por agente se multiplica no todo. Decida desde o início o teto de paralelismo e o teto de passos de cada agente (a hora de parar). Essa questão de medir "o quanto se está usando" leva à observabilidade do próximo capítulo.
Tropeços e como evitá-los pelo desenho
O multiagente tem falhas próprias que não aconteciam com um agente só. Em todas, o básico é preveni-las de antemão pelo desenho, não confiar na sorte em tempo de execução. Fixemos as 3 representativas e suas contramedidas.
Vários agentes fazem o mesmo trabalho em duplicidade, ou "de quem é a responsabilidade" fica vago e ninguém faz.
Como evitar: reparta a responsabilidade de cada agente sem sobreposição e sem lacuna, de modo que a fronteira caiba em uma frase.
A empurra para B, B para A… ficam se jogando o trabalho e nunca termina, repetindo a mesma troca.
Como evitar: imponha sempre condição de término e teto de idas e voltas / passos. Fazer o centro (pai) deter a decisão final reduz o descontrole.
A falha ou a saída errada de um agente flui direto para o próximo e trava o todo ou constrói um resultado equivocado.
Como evitar: valide a saída antes do repasse e defina o fallback em caso de falha (retry, alternativa, escalonamento a um humano).
A lição comum às 3 é decidir "fronteira, condição de término e validação" antes de escrever código. Quem cuida de quê (fronteira), quando para (condição de término) e o que se confere antes de passar (validação). Tecendo esses 3 pontos no desenho, a maioria dos problemas próprios do multiagente é evitada de antemão.
📊 "O que não se vê, não se conserta". Essas falhas só ficam perceptíveis quando "qual agente fez o quê" está em um estado rastreável a posteriori. Com vários agentes envolvidos, "onde e o que aconteceu" fica ainda menos visível do que com um só — e é por isso que a avaliação e a observabilidade do próximo capítulo ganham uma importância ainda maior no multiagente.
- Enfiar demais em um agente derruba a precisão. Resolva com a cooperação de agentes pequenos, com papéis estreitos.
- São 3 os padrões básicos — orquestrador + trabalhadores, pipeline e divisão de papéis. Podem ser aninhados.
- Divida quando exigir paralelismo, especialização ou exploração ampla. Se for simples, siga com um agente. Pergunte antes "um basta?".
- A cooperação se faz por acordos explícitos (A2A = a etiqueta que conecta agentes entre si). Contexto e custo, gira restringindo.
- As armadilhas próprias (sobreposição, empurra-empurra, cascata) se previnem decidindo antes, no desenho, fronteira, condição de término e validação.
Quando vários agentes começam a rodar, o que se torna necessário em seguida é "medir se está de fato funcionando bem e tornar o comportamento visível". No próximo Capítulo 5 "Avaliação e observabilidade", avançamos para como medir a qualidade do agente e deixar o funcionamento interno rastreável.