Capítulo 6 — Estratégias Fundamentais de Orquestração
Sexta postagem do passeio capítulo a capítulo pelo LLM Primer IV: Projetando a Cognição da IA com MCP. Um sistema multi-agente é um sistema distribuído — uma vez aceito esse enquadramento, a maioria das escolhas de design deste capítulo vira familiar, e a maioria das falhas caras de 2024 e 2025 para de ser misteriosa.
Por que este capítulo existe
A linguagem de marketing em volta de sistemas agênticos sugere que mais agentes é inerentemente melhor — mais cavalos cognitivos, mais especialização, mais capacidade emergente. A realidade de engenharia é o oposto disso na maioria dos casos. Cada agente adicional adiciona um round trip, um ponto de serialização, um lugar onde a saída de um agente vira a entrada de outro, e uma nova oportunidade para a conversa derivar para fora do trilho. A pergunta inicial certa não é "como distribuo isso entre agentes?" mas "um único modelo com as ferramentas certas consegue fazer isso numa chamada?"
Este capítulo percorre os dois formatos mais simples de orquestração — sequencial e concorrente — e a pergunta prévia que deveria preceder qualquer um. Muitas das falhas mais caras de produção dos últimos dois anos não foram falhas de orquestração. Foram sistemas construídos como multi-agente quando um único agente bem equipado teria feito o trabalho com um décimo da latência e nenhum dos bugs de coordenação.
6.1 Quando múltiplos agentes de fato ajudam
O argumento por um único agente com ferramentas é mais forte quando a tarefa se decompõe num pequeno número de operações bem definidas contra fontes de dados bem definidas. Um assistente de revisão de código que lê um diff, roda um linter, consulta convenções e escreve um comentário pode ser construído como uma invocação de modelo com quatro tools. Adicionar um segundo agente introduz latência sem adicionar capacidade — o modelo já está fazendo o planejamento; um segundo modelo planejando diferente é custo de coordenação, não melhoria.
Três propriedades fazem múltiplos agentes valerem. Heterogeneidade de contexto — quando duas fases precisam de prompts de sistema, ferramentas ou material de referência dramaticamente diferentes, forçar ambas numa janela só dilui a atenção do modelo. Pesquisar-depois-escrever é o caso canônico: recuperação quer amplitude e ferramentas de busca, escrita quer prosa e nenhuma ferramenta. Refinamento iterativo contra uma checagem externa — se a saída precisa ser revisada e possivelmente reescrita, o produtor e o checador cada um querem seu próprio contexto e prompt. Paralelismo entre subtarefas independentes — cinco fontes de documento para resumir, três perspectivas a coletar, dez arquivos para analisar — rodá-las em série desperdiça tempo de relógio em trabalho sem dependência causal.
Antes de se comprometer com multi-agente, um engenheiro deveria saber nomear a propriedade que motiva. Um retrospectivo de 2025 de uma grande empresa de logística trocou uma orquestração de suporte ao cliente com sete agentes por um único agente Claude mais seis tools MCP; a versão de agente único foi mais rápida, mais barata, e pontuou mais alto na qualidade de resolução. "Conseguimos colapsar isto?" deveria ser pergunta de pé em qualquer revisão de orquestração.
6.2 Orquestração sequencial: pipelines e refinamento progressivo
Orquestração sequencial é o formato multi-agente mais simples. A saída de um agente vira a entrada do próximo. A maioria dos sistemas em produção rotulados como "multi-agente" são pipelines sequenciais disfarçados. A força é legibilidade: o pipeline pode ser desenhado num quadro branco, testado estágio por estágio, e raciocinado como uma série de contratos de entrada-saída. O contrato entre estágios é o artefato chave — cada estágio declara seu schema de entrada, o orquestrador o aplica com código em vez de confiança, e falhas de validação disparam retries ou fallbacks em vez de se propagarem em silêncio.
O caso canônico é pesquisar-depois-escrever. Um agente de pesquisa com busca web e ferramentas de recuperação produz um briefing estruturado; um agente de escrita sem ferramentas e com prompt de prosa transforma o briefing em artigo. O agente de escrita não vê os falsos começos, as fontes descartadas, nem as longas cadeias de raciocínio. Ele vê o briefing. Ambos os estágios podem usar modelos diferentes — raciocínio forte para pesquisa, prosa forte para escrita — e os custos se acumulam só onde cada um é necessário. Refinamento progressivo é primo próximo: rascunhar, editar, checar fatos, reformatar. Operadores especializados batem um generalista tentando fazer tudo numa só passada.
Os custos honestos são três. Latência — um pipeline de N estágios tem chão igual à soma dos runtimes de estágio. Pipelines longos se eliminam de latência conversacional por definição. Amplificação de erro — um pipeline de quatro estágios a 95% por estágio é 81% ponta a ponta; um de oito é 66%. Validação por estágio com retries limitados é o que mantém a matemática operável. Perda de informação entre estágios — cada saída é necessariamente mais estreita que seu contexto de trabalho, e informação que o agente de escrita depois percebe que precisa está perdida a não ser que o schema do briefing fosse mais rico que o estritamente necessário.
6.3 Orquestração concorrente: scatter, gather, multi-perspectiva
Orquestração concorrente roda múltiplos agentes em paralelo e combina suas saídas. A propriedade definidora é nenhuma dependência causal durante o trabalho — dependência apenas no passo de combinação. Às vezes chamado scatter-gather, às vezes map-reduce para agentes; a topologia é a mesma.
Três casos de uso motivam o padrão. Paralelismo entre subtarefas independentes — cinco fontes lidas em paralelo, depois um sintetizador. Tempo de relógio é o leitor mais lento mais o sintetizador, não a soma. Análise multi-perspectiva — a mesma entrada dada a um prompt de analista financeiro, um de revisor jurídico, e um de estrategista de produto, com enquadramentos genuinamente diferentes o suficiente para que as saídas não sejam só variantes cosméticas. Ensemble para confiabilidade — o mesmo prompt entre vários agentes com saídas votadas ou em média, defensável quando respostas erradas custam muito mais que uma conta de tokens 3x.
O passo de combinação é onde esforço de engenharia paga. Sintetizadores ingênuos com entradas longas e contraditórias viram gargalo. Três padrões melhoram isto: saídas intermediárias estruturadas para que o sintetizador funda campos deterministicamente em vez de reler prosa; redução hierárquica para que cada agente combinador veja um número limitado de entradas conforme o fan-out cresce; e destaque de conflito para que o sintetizador rotule discordâncias em vez de silenciosamente escolher um lado.
A pergunta diagnóstica para saber se scatter-gather é certo: se eu contasse a um agente paralelo o que outro está produzindo agora, isso mudaria sua saída? Se sim, o trabalho não era independente e o padrão é errado — você precisa ou de dependências sequenciais ou dos padrões dinâmicos do Capítulo 7.
6.4 A matemática honesta da coordenação
Toda orquestração é, em runtime, um workflow distribuído sobre workers não confiáveis. Taxas de falha por chamada de 1–5% são típicas até em modelos de qualidade — falhas de parse JSON, violações de contrato, nomes de tool alucinados, skips silenciosos. Multiplicado por um pipeline, uma taxa de 2% por estágio em oito estágios é 85% ponta a ponta. As mitigações são estruturais: validação por estágio que dispara retries limitados; observabilidade por estágio que registra entradas, saídas, latência, gasto de token, e quais gates de validação passaram; e fallback limitado para que um orçamento de retry esgotado degrade graciosamente em vez de colapsar o fluxo inteiro.
Orçamentos de latência precisam de teto, não só piso — usuários não ligam para a média, ligam para a cauda longa. Orçamentos de custo precisam de modelo de antemão: um pipeline de dois estágios custa ~1.5x o equivalente de um estágio, scatter-gather entre cinco ramos custa 5–8x, roundtables 10x ou mais. Alguns sistemas não são viáveis em escala porque seu custo por interação excede o valor da interação. Faça a aritmética em tempo de design, não depois da conta chegar.
O que o Capítulo 6 prepara
Sequencial e concorrente são os blocos de construção. Eles cuidam da maioria dos casos de uso multi-agente quando a topologia da tarefa é conhecida de antemão e os papéis dos workers são fixos. Eles compartilham uma suposição: alguém em tempo de design decidiu o que são os agentes e como se conectam. A orquestração é estática; o pipeline é desenhado antes que qualquer requisição de usuário chegue. O Capítulo 7 retira essa suposição.
Próximo — Capítulo 7: Padrões Avançados Colaborativos e Dinâmicos. Roundtables, roteamento por handoff, e orquestração magentic — o que acontece quando a topologia tem que ser construída por requisição em vez de por design, e os modos de falha (não-terminação, mis-routing, planejamento desbocado) que os padrões mais simples evitam.
