Orquestração de agentes de IA: sequencial, paralelo ou supervisor, qual usar em cada caso?

Quase todo conteúdo do nicho mostra UM fluxo funcionando e chama aquilo de orquestração

Aí você copia o arranjo, joga na sua tarefa e o negócio fica lento, caro ou simplesmente errado

O problema não é a ferramenta, é o arranjo: fila sequencial, fan out paralelo e supervisor resolvem coisas diferentes, e escolher o errado custa token e custa resultado

Neste post a ideia não é listar framework, é te dar o critério de escolha: o que cada arranjo resolve, onde cada um quebra e qual sinal na sua tarefa aponta pra cada um deles

Bora? 🙂

Antes de escolher o arranjo: workflow não é agente

Essa confusão estraga metade das discussões sobre o tema, então vale parar aqui

A Anthropic separa as duas coisas em Building Effective Agents: workflows são sistemas em que LLMs e ferramentas são orquestrados por caminhos de código predefinidos, e agentes são sistemas em que o LLM dirige dinamicamente o próprio processo e o uso de ferramentas

Traduzindo pro prático: no workflow, QUEM decide o caminho é você, escrevendo código antes de rodar

No agente, quem decide é o modelo, em tempo de execução

Os cinco padrões catalogados:

A mesma referência cataloga cinco padrões de workflow pra agentes:

• prompt chaining (encadeamento de prompts)
• routing (roteamento)
• parallelization (paralelização)
• orchestrator-workers (orquestrador-trabalhadores)
• evaluator-optimizer (avaliador-otimizador)

Os três arranjos deste post caem direto nesse mapa: a fila sequencial é o prompt chaining, o fan out paralelo é a parallelization e o supervisor é o orchestrator-workers

E tem uma recomendação da própria Anthropic que quase ninguém repete: comece usando as APIs de LLM diretamente, porque muitos desses padrões podem ser implementados em poucas linhas de código

Ou seja, antes de instalar um framework de orquestração de agentes pra resolver um encadeamento de três passos, se liga que talvez o encadeamento de três passos seja… três chamadas 😀

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

Orquestração sequencial: quando um passo depende do anterior

No encadeamento de prompts a tarefa é quebrada em uma sequência de passos, e a saída de cada chamada de LLM vira a entrada da chamada seguinte

Saída do passo N = entrada do passo N+1

Se você já montou um pipeline de build (lint, teste, deploy), é bem semelhante: cada etapa só faz sentido depois que a anterior entregou algo

O que isso resolve:

Cada passo fica pequeno e checável

Em vez de um mega prompt tentando extrair, resumir, traduzir e formatar tudo de uma vez, você tem quatro chamadas simples, e dá pra olhar a saída de cada uma antes de seguir

Quando dá ruim, você sabe EXATAMENTE em qual passo deu

Onde ele quebra:

Latência somada

Nada roda em paralelo, então o tempo total é a soma de todos os passos, sem atalho

E tem o efeito dominó: um erro no passo 2 não fica no passo 2, ele vira entrada do passo 3 e segue viajando o pipeline inteiro como se fosse verdade

Tome cuidado com isso em cadeias longas, porque o texto final chega bonitinho e confiante mesmo quando a premissa lá do começo estava torta

Sinal de que é o arranjo certo: existe dependência real entre as etapas, o passo seguinte precisa do resultado do anterior pra existir

Fan out paralelo: quando as subtarefas são independentes

A paralelização é o oposto do encadeamento: em vez de uma fila, você dispara várias chamadas ao mesmo tempo

E ela aparece em duas variações documentadas:

• seccionamento (sectioning): quebra a tarefa em subtarefas independentes que rodam em paralelo
• votação (voting): roda a MESMA tarefa várias vezes pra obter saídas diversas

Nos dois casos, os resultados são agregados programaticamente, ou seja, quem junta o material no fim é código, não um modelo decidindo no impulso

O que isso resolve:

Tempo de parede, no seccionamento

Dez análises independentes de dez arquivos não têm por que esperar uma pela outra

E diversidade de opinião, na votação: rodar a mesma checagem várias vezes te dá saídas diferentes pra comparar, o que ajuda quando a resposta única é frágil demais pra confiar

Onde ele quebra:

As subtarefas são definidas no código, ANTES de rodar

Então o arranjo não se adapta a uma entrada que ele não previa: se a tarefa real precisava de sete recortes e você escreveu quatro, os outros três simplesmente não existem

Tem outro ponto, mais sutil e mais chato: agentes rodando em paralelo tomam decisões implícitas o tempo todo, e essas decisões podem conflitar entre si

Dois agentes trabalhando no mesmo objetivo sem enxergar um ao outro podem entregar duas metades que não encaixam

E tem o custo: fan out também é sistema multiagente, então ele cai na mesma conta de token que o supervisor, aquela de cerca de 15x mais tokens que uma conversa comum de chat

Sinal de que é o arranjo certo: dá pra listar as subtarefas antes de rodar e elas não conversam entre si

Supervisor: quando só dá pra dividir a tarefa em tempo de execução

Aqui entra o orquestrador-trabalhadores

Um LLM central quebra a tarefa dinamicamente, delega pra LLMs trabalhadores e sintetiza os resultados

A diferença-chave em relação ao paralelo é essa, e é ela que define o arranjo: as subtarefas não são predefinidas, elas são determinadas pelo orquestrador conforme a entrada

No fan out, você escreveu os recortes

No supervisor, o modelo olha o pedido e decide quantos recortes existem

Como isso aparece nos SDKs:

O SDK de Agentes da OpenAI documenta dois padrões amplamente aplicáveis de orquestração:

• manager (agents as tools): um agente central chama especialistas como ferramentas e mantém o controle da conversa
• handoffs: um agente transfere o controle pra outro, de forma descentralizada

Repara na diferença de poder: no manager, o central nunca larga o volante

No handoff, ele passa o volante

No lado do LangGraph existe o pacote langgraph-supervisor, mantido pela LangChain, pra criar um agente supervisor que orquestra agentes especializados, com mecanismo de handoff baseado em ferramentas

A função central é create_supervisor e a instalação é via pip:

pip install langgraph-supervisor

E aqui vai o detalhe honesto que economiza dependência: a própria referência do langgraph-supervisor recomenda, pra maioria dos casos, implementar o padrão supervisor diretamente via ferramentas em vez de usar a biblioteca

Bate certinho com a recomendação da Anthropic lá do começo, né?

Se você está montando isso dentro de uma stack de automação da empresa, vale ver também como esses arranjos aparecem em orquestração de agentes no n8n, que é o mesmo problema com outra roupa

Sequencial x paralelo x supervisor: comparação lado a lado

Um aviso sobre a coluna de custo, porque é fácil ler errado: a conta de cerca de 15x mais tokens que uma conversa comum de chat é sobre sistema multiagente como categoria, não é imposto exclusivo do supervisor

Fan out paralelo paga o mesmo pedágio, já que ele também dispara várias chamadas

O sequencial é o único dos três que não multiplica assim: ele soma um passo por vez

Qual usar em cada caso

Agora o que interessa: como olhar pra SUA tarefa e decidir

Tarefa valiosa, paralelizável e com muita informação: multiagente

A Anthropic afirma que sistemas multiagente se destacam em tarefas valiosas com forte paralelização, com informação que estoura uma única janela de contexto e com muitas ferramentas complexas

O exemplo que ela dá é ótimo porque é concreto: identificar todos os membros de conselho das empresas de TI do S&P 500

O sistema multiagente acertou, decompondo em subtarefas pra subagentes

O sistema de agente único falhou, com buscas sequenciais lentas

Repara que ninguém conseguia listar as subtarefas antes: quantas empresas, quantos conselhos, quantas buscas por empresa, isso só aparece quando a coisa já está rodando

É supervisor, não fan out

Tarefa fortemente interdependente: sequencial

A mesma referência diz que sistemas multiagente são menos eficazes em tarefas fortemente interdependentes, como programar

Faz todo sentido: em código, a decisão do arquivo A muda o que é certo fazer no arquivo B

Quando cada peça precisa saber o que a outra decidiu, a fila sequencial ganha justamente pelo que parecia defeito: tudo passa pelo mesmo fio

Gerador contra revisor: dois papéis, uma linha de escrita

Esse caso é meio à parte e é muito massa

A Cognition faz o Devin e o Devin Review iterarem nativamente um contra o outro, de modo que a maior parte dos bugs já esteja resolvida quando um humano abre o PR

Segundo a empresa, o Devin Review encontra uma média de 2 bugs por PR, com cerca de 58% classificados como severos: erros de lógica, casos de borda faltando, vulnerabilidades de segurança

Não é fan out de gente fazendo a mesma coisa, é papel contra papel

O veredito honesto: mais agentes nem sempre é melhor

Os dois lados existem e os dois têm material sério, então vamos aos dois

A favor:

O sistema multiagente de pesquisa da Anthropic, com Claude Opus 4 como agente líder e subagentes Claude Sonnet 4, superou o Claude Opus 4 sozinho na avaliação interna de pesquisa da empresa, com 90,2% de superioridade

E tem um dado que explica bastante coisa: na análise sobre a avaliação BrowseComp, o consumo de tokens sozinho explica 80% da variação de desempenho, e três fatores juntos explicam 95%

Parte do ganho do multiagente é isso, gente: é mais token trabalhando no problema

Contra:

Sistemas multiagente consomem cerca de 15x mais tokens do que uma conversa comum de chat

Quinze vezes

E a Cognition publicou o ensaio Don’t Build Multi-Agents, assinado por Walden Yan, com dois princípios que valem tatuar:

1. Agentes precisam compartilhar contexto completo, inclusive o rastro de ações, não só mensagens isoladas
2. Toda ação carrega decisões implícitas, e essas decisões podem conflitar entre agentes paralelos

É o mesmo buraco do fan out que citei lá em cima, só que dito por quem se queimou construindo

A atualização que fecha o raciocínio:

Em um post posterior, a Cognition diz ter encontrado uma classe mais estreita de padrões multiagente que funcionam: vários agentes contribuem com inteligência pra tarefa, mas as ESCRITAS permanecem em uma única linha (single-threaded)

Ou seja: pode ter muita cabeça pensando, desde que só uma mão escreva

Veredito prático: escolha pelo formato da tarefa, não pelo número de agentes

Mais agente não é mais inteligência, é mais token e mais superfície de conflito

Como esses três arranjos aparecem no Claude Code

Bom, teoria é legal, mas você provavelmente veio aqui porque usa Claude Code no dia a dia

Então bora aterrissar, e já adianto o mapa: subagente é o trabalhador, agent teams é o time com líder e dynamic workflow é o arranjo escrito em código

Subagente: o trabalhador

No Claude Code, um subagente é um arquivo Markdown com frontmatter YAML

Ele roda na própria janela de contexto, com prompt de sistema próprio, acesso a ferramentas específico e permissões independentes

Os arquivos ficam em duas localizações:

• .claude/agents/ no projeto (específicos daquele repositório)
• ~/.claude/agents/ no diretório do usuário (pessoais, disponíveis em todos os projetos)

O Claude Code varre as duas pastas recursivamente, então dá pra organizar em subpastas sem medo

Pra chamar um deles direto, você menciona @agent-<nome>, e no caso de subagente vindo de plugin o nome vem escopado (ex.: @agent-my-plugin:code-reviewer)

Se a diferença entre subagente, skill e comando ainda te embola, vale a leitura sobre subagentes e skills no Claude Code antes de seguir

As quatro formas de tocar várias coisas ao mesmo tempo:

A documentação lista quatro, e cada uma paraleliza de um jeito:

• subagentes
• agent view
• agent teams
• dynamic workflows

O agent view é aberto pelo comando claude agents e mostra em uma tela só todas as sessões em background: o que está rodando, o que precisa de resposta e o que terminou

Já o /tasks lista o que está rodando em segundo plano na sessão atual e permite acompanhar, anexar ou parar cada item, incluindo subagentes que já terminaram

E um dynamic workflow é um script JavaScript que orquestra subagentes em escala: o Claude escreve o script pra tarefa que você descreveu e um runtime executa em segundo plano enquanto a sessão segue respondendo

Olha onde isso cai no mapa do post: dynamic workflow é o caminho definido em código, igual ao sequencial e ao fan out, só que quem escreve o código é o Claude, não você

A diferença que mapeia direto no post:

Subagentes rodam dentro de uma única sessão e só reportam de volta ao agente principal

Isso é supervisor clássico: o central delega e sintetiza, e os trabalhadores não falam com você

Já nos agent teams, uma sessão age como líder do time, coordenando o trabalho, atribuindo tarefas e sintetizando resultados, e os teammates trabalham de forma independente, cada um na própria janela de contexto, compartilhando uma lista de tarefas e se comunicando diretamente entre si

E tem o detalhe que muda tudo na prática: com agent teams dá pra interagir diretamente com cada teammate, sem passar pelo líder

Duas observações importantes antes de sair montando time:

1. Agent teams é experimental e vem DESLIGADO por padrão: a habilitação é feita definindo CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 no settings.json ou no ambiente
2. Ao criar um teammate, dá pra referenciar um tipo de subagente de qualquer escopo (projeto, usuário, plugin ou definido via CLI), então o mesmo arquivo serve como papel de subagente delegado E como papel de teammate

Esse ponto 2 é ótimo: você escreve o papel uma vez e reaproveita nos dois arranjos 😀

Vídeo: vários agentes rodando ao mesmo tempo na prática

Pra começar do zero com a ideia de vários agentes trabalhando em paralelo, este vídeo do canal mostra o assunto em visão geral:

Conclusão

A régua de decisão cabe em três frases

Sequencial: use quando as etapas dependem umas das outras e a saída de uma alimenta a próxima

Fan out paralelo: use quando você consegue listar as subtarefas ANTES de rodar e elas não precisam conversar entre si

Supervisor: use quando a divisão da tarefa só aparece depois de olhar a entrada, e alguém precisa sintetizar o resultado no fim

O próximo passo é concreto: pega uma tarefa real que você automatizaria hoje e faz duas perguntas

As etapas dependem umas das outras?

Dá pra listar as subtarefas antes de rodar?

As respostas te entregam o arranjo sem precisar de framework nenhum

E aí comece pelo mais simples que resolve, porque muitos desses padrões cabem em poucas linhas de código, e vale MUITO mais um sequencial de três passos que funciona do que um time de agentes queimando 15x token pra brigar entre si

Até o próximo post! =)