O problema
Um engenheiro propõe usar quatro subagentes especializados pra resolver uma tarefa de análise que consiste em ler dois arquivos e comparar dois números. A justificativa é "multiagente é mais robusto". Na prática, o resultado é quatro sessões de contexto separado, mais latência, mais custo, e nenhum ganho de qualidade — porque a tarefa nunca precisou de múltiplos pontos de vista independentes. Ela precisava de uma checagem determinística.
Orquestração multiagente não é uma escala de "melhor" conforme você adiciona agentes. É uma ferramenta específica pra um problema específico: quando uma tarefa se beneficia de isolamento de contexto, especialização, ou paralelismo genuíno. Fora disso, ela é só complexidade.
O conceito central
A primeira pergunta antes de qualquer decisão de topologia é: essa tarefa cabe confortavelmente em um único contexto, com um número pequeno de ferramentas, sem precisar de raciocínio isolado? Se cabe, um coordenador único resolve com menos partes móveis. Multiagente entra quando pelo menos uma destas condições é verdadeira:
- A tarefa se beneficia de pesquisa paralela independente — múltiplas fontes ou abordagens exploradas ao mesmo tempo, sem que uma contamine o raciocínio da outra.
- A tarefa exige revisão isolada — um revisor que não viu o processo de geração, só o resultado, pra evitar viés de confirmação.
- A tarefa tem sub-domínios genuinamente especializados — cada subagente carrega só o contexto relevante ao seu domínio, em vez de um único contexto acumulando tudo.
Uma checagem determinística — como comparar dois números ou calcular um checksum — nunca justifica um subagente. Ela deve ser código ou uma ferramenta com escopo estreito, porque não ganha nada de um loop de raciocínio autônomo. Esse é o distrator mais comum em cenário: propor multiagente pra uma operação que já tem procedimento exato e não se beneficia de julgamento.
O segundo eixo de decisão é a topologia. Um coordenador que delega pra subagentes especializados funciona bem quando as sub-tarefas são conhecidas de antemão e têm fronteiras claras — cada subagente recebe um escopo definido e devolve um resultado estruturado. Paralelismo genuíno (múltiplos subagentes rodando ao mesmo tempo) só faz sentido quando as sub-tarefas são independentes entre si — se uma precisa do resultado da outra, paralelizar não economiza tempo, só adiciona coordenação.
O terceiro eixo é decomposição sequencial vs. adaptativa. Decomposição sequencial funciona quando os passos são conhecidos com antecedência — um pipeline fixo de "extrair, validar, formatar". Decomposição adaptativa é necessária quando o próximo passo depende do resultado do anterior de um jeito que não dá pra prever — o coordenador precisa decidir dinamicamente se delega, pra quem, e com que escopo, conforme a tarefa se revela.
O erro mais caro em orquestração multiagente não é usar poucos agentes — é usar agentes demais pra uma tarefa que cabia em um único contexto, multiplicando latência e custo sem multiplicar qualidade.
Coloque em prática
No laboratório desta lição você vai implementar uma função de decisão que, dado um conjunto de sinais sobre uma tarefa (precisa de paralelismo genuíno? precisa de revisão isolada? é uma operação determinística?), recomenda a topologia certa — incluindo reconhecer quando a resposta certa é "nenhum subagente, isso é código".