Lição 4: Orquestrador-workers: tornar a própria decomposição dinâmica

Objetivos de aprendizado:

• Definir orquestrador-workers e articular a diferença essencial em relação à paralelização: topograficamente parecidos, mas as subtarefas não são predefinidas — o orquestrador as decide com base na entrada específica
• Equipar todo despacho com os quatro elementos (objetivo, formato de saída, orientação sobre ferramentas e fontes, limites da tarefa) e escrever no prompt as regras de escala (“quantos disparar, quanto cada um pode gastar”)
• Ler o balanço completo de um sistema real em produção: onde aparece a melhoria de 90,2%, por que a conta 15× é a outra metade do mesmo mecanismo, o que a execução síncrona bloqueia e quais três novos custos a assincronia obriga você a carregar

Pré-requisitos: Lições 1–3 concluídas (esta lição retoma a pergunta deixada em aberto no fim da Lição 3) | Anterior: << Lição 3 | Próxima: Lição 5 >>

O buraco que a Lição 3 deixou aberto

Na Lição 3 você escreveu seccionamento: dividir uma tarefa em subtarefas independentes, executá-las simultaneamente e depois agregar os resultados com código. Volte àquele código — onde mora a lógica da divisão? Está no array que você fixou no código: SECTIONS = ['security', 'performance', 'readability']. Os três ramos foram decididos quando você escreveu o código; o tempo de execução apenas os executa.

Essa abordagem funciona sob uma suposição rígida: você já sabe, no momento de escrever, como dividir a tarefa. Revisão de código se encaixa nessa suposição porque as dimensões de revisão são estáveis — troque o repositório e você ainda revisa os mesmos aspectos.

Agora considere uma tarefa diferente:

“Investigue os problemas de desempenho nesta base de código.”

Quantas partes? Quais partes? Você não consegue fixar isso no código. Talvez o gargalo esteja nas consultas ao banco de dados, então você despacharia alguém para varrer os pontos de chamada do ORM. Talvez esteja num loop de caminho quente, então você mandaria alguém ler a saída do profiler. Talvez seja o tamanho do artefato de build, sem relação com o tempo de execução. Quais arquivos mudar, quais direções investigar — você tem de olhar este repositório específico, esta descrição específica do problema, antes de saber.

Em outras palavras: a própria decomposição precisa ser calculada em tempo de execução. Seu código não guarda mais a decisão de “dividir em quais partes”; guarda apenas o mecanismo de “como despachar, como coletar, como sintetizar”. Quem toma essa decisão? Um LLM.

Esse é o quarto padrão.

Definição, e como ela difere da paralelização

A fonte oficial dá uma definição de uma frase: no fluxo de trabalho orquestrador-workers, um LLM central decompõe tarefas dinamicamente, delega-as a LLMs workers e sintetiza seus resultados¹.

Três ações: decompor, delegar, sintetizar. Você já escreveu a do meio — a delegação — na Lição 3; o código de fan-out é quase idêntico. O que é de fato novo é a primeira ação: a decomposição sai do código e vai para as mãos do modelo.

O enunciado de uso é mais preciso: este fluxo de trabalho serve bem a tarefas complexas nas quais você não consegue prever as subtarefas necessárias; o exemplo oficial é programação — o número de arquivos que precisam mudar e a natureza de cada mudança provavelmente dependem da própria tarefa¹.

Depois vem a comparação que você precisa memorizar. A fonte diz: embora seja topograficamente parecido com a paralelização, a diferença essencial é a flexibilidade — as subtarefas não são predefinidas, mas determinadas pelo orquestrador com base na entrada específica¹.

O termo usado é "topographically similar" (parecido topograficamente, isto é, parecido em forma). Vale parar um instante nessa formulação. Se você desenhar o seccionamento da Lição 3 e o orquestrador-workers desta lição, vai traçar formas quase idênticas: um nó se abre em três, que depois se dobram de volta em um. A forma engana. A diferença não está no diagrama; está em quando aquela decisão é tomada:

Essa última linha é onde mora a dor de engenharia. Com seccionamento, o prompt de cada ramo é feito à mão; você pode iterar e ajustar, acrescentar exemplos para cada dimensão. Orquestrador-workers não permite isso — os prompts de despacho são gerados na hora pelo orquestrador, e você só controla as regras que ele segue ao gerá-los. As duas próximas seções explicam o que essas regras devem conter.

Primeiro, vamos escrever o mecanismo como um esqueleto. O código abaixo é ilustração própria desta lição; não existe script de orquestração oficial nos materiais primários, então não trate isto como implementação padrão:

Compare isto linha a linha com o código de fan-out da Lição 3; você vai ver que só a etapa 1 foi acrescentada. Essa etapa acrescentada substitui a previsibilidade do sistema inteiro — que é também por que a contabilidade das seções seguintes precisa ser detalhada item por item.

Como é um sistema real em produção

Dá para decorar definições de padrões sem saber como eles se parecem em produção. Esta lição tem uma vantagem: a Anthropic publicou uma retrospectiva de engenharia sobre seu recurso de Pesquisa, que é um sistema orquestrador-worker rodando em produção. Esta seção e as próximas se baseiam nesse balanço.

Citação sobre a arquitetura: o sistema de Pesquisa deles usa uma arquitetura multiagente com um padrão orquestrador-worker, no qual um agente líder coordena o processo enquanto delega a subagentes especializados que operam em paralelo².

Como isso se parece em execução: quando um usuário envia uma consulta, o agente líder a analisa, desenvolve uma estratégia e dispara subagentes para explorar aspectos diferentes simultaneamente².

Note o “analisa, desenvolve uma estratégia” — essa é a decisão em tempo de execução mencionada na seção anterior. O usuário pergunta algo; o agente líder descobre na hora quantas direções perseguir e o que cada uma deve investigar.

Vale extrair mais uma citação definicional: um sistema multiagente consiste em múltiplos agentes (LLMs usando ferramentas autonomamente em um loop) trabalhando juntos².

Esse parêntese deve soar familiar. Um worker não é nada de novo — é o loop do harness que você escreveu no Curso 7 desta série. Orquestrador-workers não introduz uma nova unidade de execução; introduz “um loop iniciando outra leva de loops”. Você já sabe escrever esse loop. Esta lição ensina a conectá-los.

A mesma retrospectiva explica por que o fan-out ajuda: a essência da busca é compressão — destilar percepções de um corpus vasto. Subagentes facilitam a compressão operando em paralelo com suas próprias janelas de contexto, explorando aspectos diferentes da questão simultaneamente antes de condensar os tokens mais importantes para o agente líder de pesquisa. Cada subagente também fornece separação de responsabilidades — ferramentas, prompts e trajetórias de exploração distintas — o que reduz a dependência de caminho e permite investigações completas e independentes².

“Janelas de contexto independentes” — você já fez essas contas na Lição 3. Aqui elas reaparecem em outro papel: não apenas capacidade, mas isolamento. Três investigações não conseguem ver os passos intermediários umas das outras, então não serão desviadas pelos erros umas das outras.

A frente do balanço: 90,2% e aqueles 80%

O número mais famoso dessa retrospectiva é também o mais citado errado. Eis a citação completa: as avaliações internas deles mostram que sistemas multiagente de pesquisa se destacam especialmente em consultas em largura (breadth-first) que envolvem perseguir múltiplas direções independentes simultaneamente. Eles descobriram que um sistema multiagente com Claude Opus 4 como agente líder e subagentes Claude Sonnet 4 superou o Claude Opus 4 de agente único em 90,2% na avaliação interna de pesquisa deles².

Você não pode citar esse número sem cada uma destas condições:

• Na avaliação interna de pesquisa deles — não é um benchmark público, você não consegue reproduzi-lo e não sabe se ele se parece com a sua distribuição de tarefas.
• Opus 4 como líder + subagentes Sonnet 4 — é o resultado daquele pareamento específico. Uma combinação diferente de modelos não promete nada.
• Destaca-se especialmente em consultas em largura — aquelas que exigem múltiplas direções independentes simultaneamente. Tarefas com dependências profundas (cada etapa espera a conclusão do anterior) não estão no escopo dessa afirmação.

Mais uma disciplina crítica: esse número compara multiagente contra agente único, não “orquestração estruturada contra loops”. Você não pode usá-lo para argumentar “mover o fluxo de controle para o código é melhor do que deixar o modelo rodar um loop” — essa é outra afirmação, e nenhum dos materiais primários desta lição os compara. Esta lição usa repetidamente o eixo “quem guarda o plano”, mas não há dado de benchmark primário nesse eixo, apenas compromissos de engenharia.

Por que multiagente é eficaz em geral? A retrospectiva oferece uma explicação menos romântica — note que a análise de apoio vem de outra avaliação, não daquela que produziu os 90,2%: sistemas multiagente funcionam principalmente porque ajudam a gastar tokens suficientes para resolver o problema. Na análise deles da avaliação BrowseComp (que testa a capacidade de agentes de navegação de localizar informações difíceis de achar), três fatores explicaram 95% da variância de desempenho, e o uso de tokens sozinho explica 80%, com o número de chamadas de ferramenta e a escolha do modelo como os outros dois fatores explicativos². Eles dizem que essa descoberta valida a arquitetura deles, que distribui trabalho entre agentes com janelas de contexto separadas para adicionar mais capacidade de raciocínio paralelo².

Os números de 95% e 80% valem apenas para a análise do BrowseComp; não os transporte para outro lugar como conclusões gerais.

Mas essa explicação de mecanismo tem uso prático: se a sua tarefa não exige tantos tokens para ser resolvida, a base dos ganhos do orquestrador-workers desaparece. (Este é um juízo de engenharia inferido da afirmação sobre o mecanismo, não uma consequência direta dos números 95%/80%.) Uma pergunta respondível com uma consulta a um documento não vai ficar mais correta despachando três workers; vai só ficar mais cara.

O verso do balanço: 4× e 15×

Estes dois números apareceram na Lição 1; eis a citação completa. A mesma retrospectiva segue imediatamente: há uma desvantagem — na prática, essas arquiteturas queimam tokens rapidamente. Nos dados deles, agentes usam tipicamente cerca de 4× mais tokens do que interações de chat, e sistemas multiagente usam cerca de 15× mais tokens do que chats. Para viabilidade econômica, sistemas multiagente exigem tarefas em que o valor da tarefa seja alto o bastante para pagar pelo desempenho adicional².

Coloque os números das duas seções lado a lado: de um lado, 90,2% (sob condições específicas); do outro, 15×. A seção anterior deixou claro que o ganho de desempenho vem principalmente de gastar tokens, então a conta mais alta não é um efeito colateral — é a outra metade do mesmo mecanismo.

Como você operacionaliza “o valor da tarefa precisa corresponder”? Na verdade, isso pede que você responda uma pergunta de negócio antes de uma técnica: se esta investigação der certo, quanto ela vale? Se a resposta for “economiza meia hora de um engenheiro”, a conta 15× provavelmente não se paga. Se a resposta for “evita um incidente em produção”, aí é outra história.

A retrospectiva também traça uma fronteira mais dura: alguns domínios que exigem que todos os agentes compartilhem o mesmo contexto, ou que envolvem muitas dependências entre agentes, não são um bom encaixe para sistemas multiagente hoje. Por exemplo, a maioria das tarefas de programação envolve menos tarefas verdadeiramente paralelizáveis do que pesquisa, e agentes LLM ainda não são muito bons em coordenar e delegar a outros agentes em tempo real². Por outro lado, eles descobriram que sistemas multiagente se destacam em tarefas valiosas que envolvem paralelização pesada, informação que excede janelas de contexto individuais e interação com numerosas ferramentas complexas².

Duas frases aqui precisam ser lidas juntas, ou você vai entendê-las errado: a fonte oficial dos padrões usa programação como exemplo de “subtarefas não podem ser previstas”¹, enquanto a retrospectiva multiagente diz que a maioria das tarefas de programação envolve menos tarefas verdadeiramente paralelizáveis do que pesquisa². Elas não se contradizem — estão falando de duas coisas diferentes. A primeira diz que a decomposição precisa ser calculada dinamicamente; a segunda diz que as subtarefas calculadas podem não rodar todas simultaneamente. Decomposição dinâmica não implica paralelismo inevitável. Um orquestrador pode perfeitamente calcular cinco subtarefas e depois rodar três em sequência e duas em paralelo.

Os quatro elementos dos prompts de delegação

Esta é a disciplina de engenharia que você deve guardar desta lição acima de tudo; a citação original é breve:

"Teach the orchestrator how to delegate. In our system, the lead agent decomposes queries into subtasks and describes them to subagents. Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries. Without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information"².

(Ensine o orquestrador a delegar. No sistema deles, o agente líder decompõe consultas em subtarefas e as descreve aos subagentes. Cada subagente precisa de um objetivo, um formato de saída, orientação sobre as ferramentas e fontes a usar e limites claros da tarefa. Sem descrições detalhadas de tarefa, agentes duplicam trabalho, deixam lacunas ou não encontram a informação necessária.)

Quatro elementos, nenhum opcional:

Objetivo — que conclusão este worker deve produzir. Não “investigue desempenho”, mas “encontre os 3 pontos quentes de CPU em tempo de execução com maior tempo próprio”. O objetivo precisa ser estreito o bastante para se julgar se foi alcançado.

Formato de saída — como é o artefato retornado. Campos, teto de quantidade de itens, ordenação. Este item determina diretamente quão fácil é escrever o estágio de síntese do orquestrador: se três workers devolvem três parágrafos de prosa, a síntese só pode contar com o modelo lendo tudo de novo. Se devolverem JSON conforme o mesmo schema, metade da síntese pode ser feita em código.

Orientação sobre ferramentas e fontes — quais ferramentas ele pode usar, onde olhar. Este item é ao mesmo tempo controle de custo e prevenção de desvio: se você não der uma ferramenta de busca na web, ele não pode sair buscando algo que não existe.

Limites da tarefa — explicitamente o que ele não deve fazer. Este item é o mais fácil de omitir e o que mais diretamente determina se os workers vão colidir. “Não olhe em src/server/; esse é o território de outro worker” — uma única frase assim é mais eficaz do que qualquer desduplicação posterior.

O caso de falha da retrospectiva é quase de manual: por exemplo, um subagente explorou a crise automotiva de chips de 2021 enquanto outros 2 duplicaram trabalho investigando as cadeias de suprimentos atuais de 2025, sem uma divisão de trabalho eficaz².

Três workers, dois duplicando e um correndo para um ano irrelevante — é exatamente assim que “duplicam trabalho, deixam lacunas” se parece em termos concretos.

Fazendo a ponte com o que você já aprendeu: o Curso 6 desta série, ao ensinar colaboração multiagente, já separou esses quatro itens (chamando-os de objetivo, escopo, fontes e formato de saída); a Lição 2 também os mencionou. Esta lição faz o que aqueles dois lugares não fizeram: recolocar os quatro elementos na posição de despachos gerados na hora pelo orquestrador — você não controla mais o conteúdo de cada despacho, apenas as regras que o orquestrador segue ao gerá-los. Os quatro elementos continuam funcionando como checklist: depois de escrever um despacho, conte-os um a um para confirmar que os quatro estão presentes.

Escalar o esforço conforme a complexidade: escrever regras de alocação no prompt

Os quatro elementos resolvem “o que cada worker faz”; resta uma pergunta: quantos disparar, quanto cada um pode gastar.

Esse conjunto de números apareceu na abertura do Curso 6; aqui ele é usado de outro jeito — não para julgar se vale usar multiagente, mas para escrevê-lo no prompt do orquestrador de modo que ele mesmo aloque as cotas. O diagnóstico da retrospectiva é direto: agentes têm dificuldade de julgar o esforço apropriado para tarefas diferentes, então eles embutiram regras de escala nos prompts. Levantamento simples de fatos exige apenas 1 agente com 3-10 chamadas de ferramenta, comparações diretas podem precisar de 2-4 subagentes com 10-15 chamadas cada, e pesquisa complexa pode usar mais de 10 subagentes com responsabilidades claramente divididas².

Uma disciplina de citação sobre esses números: a identidade deles é “regras que eles embutiram nos próprios prompts”, não padrões da indústria, e não escalas que você deva copiar literalmente. Sua distribuição de tarefas, a velocidade das suas ferramentas e seus modelos são todos diferentes dos deles. O que é de fato transportável é a prática em si — escrever regras de alocação explicitamente no prompt do orquestrador, em vez de esperar que o orquestrador se autorregule.

O que acontece se você não as escrever? A retrospectiva fornece a cena: sistemas multiagente têm diferenças-chave em relação a sistemas de agente único, incluindo um crescimento rápido da complexidade de coordenação. Agentes iniciais cometeram erros como disparar 50 subagentes para consultas simples, vasculhar a web sem fim atrás de fontes inexistentes e distrair uns aos outros com atualizações excessivas².

“Disparar 50 subagentes para consultas simples” — converta isso usando o balanço da seção anterior e você entende: pelos dados deles, multiagente é cerca de 15× os tokens de um chat², então esse tipo de fan-out descontrolado empurra esse multiplicador muito mais alto. Regras de cota não são mesquinharia; são o meio de manter custo e valor da tarefa na mesma ordem de grandeza.

Como você escreve essa regra no seu próprio prompt de orquestrador? Siga a forma deles e preencha com a sua escala: separe suas tarefas em alguns níveis, especifique para cada nível o teto de número de subagentes e o teto de chamadas de ferramenta por subagente, e depois acrescente uma cláusula como “se ultrapassar o teto, devolva os achados atuais; não continue”. Isso pode reduzir a probabilidade de descontrole, mas ainda é só um prompt — para modelos não determinísticos, um teto escrito no prompt é sempre apenas conselho. O portão de verdade fica do lado do código: o LIMIT no pool do esqueleto. A camada de prompt cuida da “autoconsciência do modelo”; a camada de código cuida do “fallback”. Você precisa das duas.

Gargalos síncronos, e o preço da assincronia

Esta seção discute problemas que a arquitetura não resolveu até hoje. O texto original vem em dois parágrafos.

Primeiro parágrafo, estado atual: a execução síncrona cria gargalos. Atualmente, os agentes líderes deles executam subagentes de forma síncrona, esperando cada conjunto de subagentes concluir antes de prosseguir. Isso simplifica a coordenação, mas cria gargalos no fluxo de informação entre agentes. Por exemplo, o agente líder não consegue guiar os subagentes, os subagentes não conseguem se coordenar, e o sistema inteiro pode ficar bloqueado esperando um único subagente terminar de buscar².

Três itens de “não consegue”, cada um correspondendo a uma perda real:

• O agente líder não consegue redirecionar em pleno voo — no minuto 2 ele já percebe que a direção do worker C está errada, mas tem de esperar o lote terminar para fazer qualquer coisa.
• Subagentes não conseguem se coordenar — o worker A já achou algo, o worker B não sabe e pode estar rebuscando isso agora mesmo.
• O lote inteiro é bloqueado pelo mais lento — dois workers que terminam em 3 minutos vão esperar junto com um que estoura o tempo aos 25 minutos, até o minuto 25.

Segundo parágrafo, o custo do outro caminho: a execução assíncrona permitiria paralelismo adicional — agentes trabalhando concorrentemente e criando novos subagentes quando necessário. Mas essa assincronia acrescenta desafios em coordenação de resultados, consistência de estado e propagação de erros entre os subagentes².

Note o tom dessa frase: o material primário lista esses três itens como desafios, não como problemas resolvidos. Então esta lição não vai lhe dar “o esquema de orquestração assíncrona oficialmente recomendado” — ele não existe. Se você for para o assíncrono por conta própria, esses três itens são seus para carregar:

• Coordenação de resultados: os workers voltam aos poucos; “quando já terminamos o suficiente para começar a síntese” é um juízo que você precisa definir.
• Consistência de estado: o agente líder mudou o escopo da investigação em pleno voo; os workers em execução ainda usam o escopo antigo; as premissas dos dois lados se bifurcaram.
• Propagação de erros: um worker falhou, mas a saída intermediária dele já tinha sido usada para disparar novos workers. Quem nessa cadeia deve reexecutar, quais resultados ficam anulados — isso exige regras explícitas.

O exercício de Nível 2 desta lição vai pedir que você dê uma instância concreta de cada um numa linha do tempo específica.

Comportamento emergente, e a última milha

Mais algumas lições de engenharia da mesma retrospectiva; cada uma é curta, mas cada uma vale um incidente em produção.

Sistemas multiagente têm comportamentos emergentes, que surgem sem programação específica. Por exemplo, pequenas mudanças no agente líder podem mudar de forma imprevisível como os subagentes se comportam. O sucesso exige entender padrões de interação, não apenas o comportamento de agentes individuais². A mesma retrospectiva acrescenta uma frase mais dura: em software tradicional, um bug pode quebrar uma funcionalidade, degradar desempenho ou causar indisponibilidade. Em sistemas agênticos, mudanças pequenas cascateiam em grandes mudanças de comportamento, o que torna notavelmente difícil escrever código para agentes complexos que precisam manter estado em um processo de longa duração².

Impacto no seu dia a dia: mude o prompt do orquestrador e você precisa rodar a suíte de avaliações inteira de novo; não dá para conferir só a saída do próprio orquestrador. A pista de avaliação do Curso 10 entra em cena aqui — é o único instrumento que você tem para ver se uma mudança pequena tirou os subagentes do rumo.

A última milha frequentemente vira a maior parte da jornada: ao construir agentes de IA, a última milha frequentemente vira a maior parte da jornada. Bases de código que funcionam na máquina do desenvolvedor exigem engenharia significativa para virar sistemas confiáveis em produção. A natureza composta dos erros em sistemas agênticos significa que problemas menores para software tradicional podem descarrilar agentes por completo².

Duas práticas que acompanham: eles combinam a adaptabilidade de agentes de IA construídos sobre o Claude com salvaguardas determinísticas como lógica de retentativa e checkpoints regulares²; eles usam rainbow deployments para evitar perturbar agentes em execução, deslocando gradualmente o tráfego das versões antigas para as novas enquanto mantêm ambas rodando simultaneamente².

Rainbow deployments — isso se liga a um problema mencionado na abertura do Curso 9 ao usar atualizações de implantação como cenário de queda: um serviço web normal reinicia, os usuários tentam de novo uma vez e está tudo bem. Um agente que vinha rodando há 20 minutos é interrompido por um reinício, e você perdeu 20 minutos de trabalho mais os tokens já gastos. Implantar tarefas de longa duração não é o mesmo que implantar serviços sem estado.

Calibragem: este é o mais caro dos cinco padrões

A esta altura você viu quatro dos cinco padrões. Classificado por custo, orquestrador-workers é o mais caro até aqui: além da sobrecarga da paralelização, ele acrescenta mais uma invocação de “fazer o modelo calcular a divisão”, mais o risco de “a divisão pode ser calculada errado”.

Então, antes de começar, faça três perguntas nesta ordem:

Primeira: a divisão pode ser fixada no código? Se sim, volte à Lição 3 e use seccionamento. No seccionamento, o prompt de cada ramo é polido à mão; no orquestrador-workers, os despachos são gerados na hora pelo modelo — o primeiro tem teto de qualidade mais alto e é mais fácil de depurar. Se você consegue predefinir, não torne dinâmico.

Segunda: esta tarefa vale todo esse dinheiro? Pelos dados deles, multiagente é cerca de 15× os tokens de um chat², e, para viabilidade econômica, o valor da tarefa precisa ser alto o bastante para pagar pelo aumento². Este é um juízo de negócio, não técnico, mas precisa ser feito antes de escrever código.

Terceira: se estiver incerto, meça primeiro. A posição de encerramento da fonte oficial sobre todo o conjunto de padrões é: estes blocos de construção não são prescritivos. A chave para o sucesso é medir desempenho e iterar sobre as implementações; você deveria considerar adicionar complexidade apenas quando isso comprovadamente melhorar os resultados¹. O Curso 10 lhe deu essa pista — primeiro rode seu conjunto real de tarefas com um único loop, obtenha uma linha de base, e só então julgue se orquestrador-workers a eleva. Sem linha de base, “parece melhor” e “gastei 15× para obter o mesmo resultado” são indistinguíveis para você.

Esta lição cobriu apenas “despachar para fora, coletar de volta”. E se o trabalho devolvido for de baixa qualidade — outro agente deveria revisá-lo, e como você combina esses quatro padrões — isso é conteúdo da Lição 5.

💻 Exercícios

Recapitulação

• Orquestrador-workers é um fluxo de trabalho no qual um LLM central decompõe tarefas dinamicamente, delega-as a LLMs workers e sintetiza seus resultados; serve bem a tarefas complexas nas quais você não consegue prever as subtarefas necessárias¹
• Embora topograficamente parecido com a paralelização, a diferença essencial é a flexibilidade: as subtarefas não são predefinidas, mas determinadas pelo orquestrador com base na entrada específica¹ — mesma forma, momento diferente da decisão
• Um worker não é nada de novo: um sistema multiagente é a reunião de múltiplos “LLMs usando ferramentas autonomamente em um loop”, com um agente líder coordenando o processo e delegando a subagentes especializados que operam em paralelo²
• Os 90,2% só valem em seu contexto completo: a avaliação interna de pesquisa deles, Claude Opus 4 como líder + subagentes Claude Sonnet 4, destacando-se especialmente em consultas em largura²; a explicação do mecanismo é que multiagente ajuda principalmente a gastar tokens suficientes — na análise do BrowseComp, três fatores explicam 95% da variância, com o uso de tokens sozinho respondendo por 80%²
• A conta é o outro lado do mesmo balanço: pelos dados deles, agentes são cerca de 4× os tokens de um chat, multiagente cerca de 15×, e, para viabilidade econômica, o valor da tarefa precisa ser alto o bastante para pagar por isso²
• Cada subagente precisa de um objetivo, um formato de saída, orientação sobre as ferramentas e fontes a usar e limites claros da tarefa; sem descrições detalhadas de tarefa, agentes duplicam trabalho, deixam lacunas ou não encontram a informação necessária² — os “prompts de delegação autossuficientes” do Curso 6 se expandem nesses quatro itens
• Agentes têm dificuldade de julgar o esforço apropriado, então escreva regras de alocação no prompt: a escala deles é levantamento simples de fatos 1 agente 3-10 chamadas, comparações diretas 2-4 subagentes 10-15 chamadas cada, pesquisa complexa mais de 10 subagentes com divisão clara²; sem regras escritas eles já viram as consequências — disparar 50 subagentes para consultas simples, vasculhar a web sem fim atrás de fontes inexistentes, distrair uns aos outros com atualizações excessivas²
• A execução síncrona simplifica a coordenação mas bloqueia o fluxo de informação: o agente líder não consegue redirecionar em pleno voo, os subagentes não conseguem se coordenar, o sistema inteiro pode ser bloqueado por um subagente²; o assíncrono permite mais paralelismo, ao custo de coordenação de resultados, consistência de estado e propagação de erros entre subagentes — esses três são desafios nos materiais primários, não soluções resolvidas²
• Sistemas multiagente têm comportamentos emergentes; pequenas mudanças no agente líder podem mudar de forma imprevisível o comportamento dos subagentes; entender padrões de interação importa, não apenas agentes individuais²; a última milha frequentemente vira a maior parte da jornada; bases de código que funcionam na máquina do desenvolvedor exigem engenharia significativa para virar sistemas confiáveis em produção²; as práticas que acompanham são salvaguardas determinísticas (lógica de retentativa, checkpoints regulares)² e rainbow deployments — deslocar tráfego gradualmente mantendo as duas versões rodando, evitando perturbar agentes em execução²
• Este é o mais caro dos quatro padrões aprendidos até agora: antes de começar, confirme que a decomposição de fato não pode ser predefinida (se puder, volte ao seccionamento da Lição 3), depois confirme que o valor da tarefa suporta 15×; se estiver incerto, use a pista do Curso 10 para medir uma linha de base primeiro — só adicione complexidade quando isso comprovadamente melhorar os resultados¹

>> Lição 5: O loop de revisão, e compor padrões em um grafo

Footnotes

1. Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

2. How we built our multi-agent research system — Anthropic Engineering — https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶ ↩²⁷ ↩²⁸ ↩²⁹ ↩³⁰ ↩³¹ ↩³² ↩³³ ↩³⁴ ↩³⁵ ↩³⁶ ↩³⁷ ↩³⁸