O que é orquestração de agentes de IA para programar?

É a camada que coordena vários agentes de programação numa mesma tarefa: algo divide o trabalho, os agentes compartilham estado por resultados devolvidos, uma lista de tarefas ou mensagens, e as mudanças se juntam por merge ou revisão, em vez de colidirem numa única pasta.

Por qual padrão de orquestração começar?

Comece com orquestrador e workers, como os subagentes do Claude Code, para pesquisa e revisão dentro de uma sessão. Passe para fan-out em git worktrees quando vários agentes precisarem escrever código ao mesmo tempo, e adicione no fim um passo de merge que roda os testes.

As equipes de agentes do Claude Code estão prontas para produção?

Em outubro de 2026 elas são experimentais e vêm desativadas. Você ativa com a configuração CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS, e a documentação lista limitações, como não poder retomar sessões de colegas in-process e só haver uma equipe por sessão.

Por que a orquestração multiagente custa tão mais?

Cada agente tem sua própria janela de contexto e relê o código de que precisa. As mensagens de coordenação também custam tokens. Segundo a documentação da Anthropic, equipes de agentes usam bem mais tokens que uma sessão única, então mantenha equipes pequenas e limite o gasto por agente.

Como evitar que dois agentes editem o mesmo arquivo?

Dê a cada agente que escreve seu próprio git worktree e branch, divida o trabalho por pasta e faça merge de um branch por vez, rodando os testes no resultado combinado. Regras de posse de arquivos podem ainda recusar edições fora dos caminhos de um agente.

Orquestração de agentes de IA: 5 padrões e ferramentas

Orquestração de agentes de IA para programar é como você faz vários agentes de código trabalharem numa mesma tarefa sem atrapalhar uns aos outros. Todo arranjo responde a três perguntas: quem divide o trabalho (você, um agente líder ou um planejador), como os agentes compartilham estado (resultados devolvidos a quem chamou, uma lista de tarefas compartilhada ou mensagens diretas) e como as mudanças se juntam (num contexto só, por git merge ou por revisão). Respondeu às três, escolheu um padrão; a ferramenta vem depois.

Este artigo apresenta os cinco padrões de orquestração que importam para agentes de programação, o que dá errado em cada um e quais ferramentas os implementam em outubro de 2026: subagentes e equipes de agentes do Claude Code, Codex cloud, Conductor, Claude Squad, Vibe Kanban e AgentVera. O AgentVera mantém este blog, então dizemos claramente onde outras ferramentas se saem melhor. As informações sobre ferramentas de terceiros foram verificadas na documentação ou nos repositórios delas.

Se você quer uma comparação de ferramentas, leia as melhores ferramentas para agentes de IA em paralelo. Aqui o foco é a arquitetura por baixo delas.

As três decisões por trás de todo arranjo

Antes dos padrões, vale nomear as partes móveis:

Decomposição: quem transforma “adicionar cobrança” em tarefas. Uma pessoa dividindo à mão é lenta mas previsível; um agente planejador é rápido mas pode cortar no lugar errado.
Estado compartilhado: como o agente B sabe o que o agente A fez. Do mais rígido ao mais solto: um resultado devolvido a quem chamou, uma lista de tarefas compartilhada com dependências e mensagens livres entre agentes.
Integração: como o código chega ao lugar. Trabalho só de leitura devolve texto. Agentes que escrevem ou dividem uma pasta (arriscado) ou trabalham em git worktrees separados cujos branches são unidos depois.

A maioria dos erros de orquestração vem de deixar um desses pontos implícito: por exemplo, dois agentes que acham que o arquivo de rotas é deles.

Cinco padrões de orquestração

1. Orquestrador e workers

Um agente conduz a conversa e entrega aos workers tarefas estreitas. Cada worker começa com contexto limpo, faz uma coisa e devolve um resumo. Quem chamou não vê a transcrição do worker, só o resultado.

Bom para: pesquisa, busca no código, revisão, triagem de testes que falharam. Qualquer coisa em que o worker lê muito e reporta pouco.
Fraco em: escrita em paralelo. Os workers normalmente editam a mesma cópia de trabalho de quem chamou.
Exemplo: subagentes do Claude Code.

2. Líder e colegas com lista de tarefas compartilhada

Um agente líder cria tarefas com dependências; os colegas pegam tarefas, concluem e mandam mensagens diretamente uns aos outros. O estado vive na lista de tarefas, não na cabeça de um agente, então um colega pode pegar uma tarefa desbloqueada há um minuto.

Bom para: trabalho que muda conforme avança, em que um testador devolve um bug a quem implementou sem você no meio.
Fraco em: custo e segurança dos arquivos. Colegas numa mesma pasta podem sobrescrever uns aos outros.
Exemplo: equipes de agentes do Claude Code; mensagens entre agentes e lista de tarefas do AgentVera.

3. Fan-out em worktrees, depois merge

Um planejador divide uma mudança em partes independentes. Cada parte roda no próprio worktree e branch, e os branches prontos entram um por vez num branch de integração, com os testes rodando no fim.

Bom para: mudanças grandes com partes separáveis: API, interface, migração.
Fraco em: partes que dependem umas das outras sem que ninguém perceba. O conflito aparece no merge, não na edição.
Exemplo: Conductor, Claude Squad e Vibe Kanban oferecem worktrees; a equipe paralela do AgentVera acrescenta o planejador e o merge. Mais em git worktree para agentes em paralelo.

4. Cadeia de handoffs

Um planejador passa para um implementador, que passa para um revisor. Cada etapa recebe a saída da anterior e nada mais. É o arranjo “planejador, implementador, revisor” que a maioria tenta primeiro.

Bom para: tarefas repetitivas em que você quer ler o plano antes que exista código.
Fraco em: velocidade. Nada roda em paralelo, e um handoff vago estraga todas as etapas seguintes.
Exemplo: tratado em detalhe em fluxos de trabalho de agentes de IA e equipe de agentes de IA.

5. Best-of-N

A mesma tarefa vai para várias tentativas, e você ou um agente revisor fica com a melhor. Nenhuma coordenação, e essa é a ideia.

Bom para: bugs difíceis e trabalho de interface pouco definido, em que a primeira resposta raramente é a melhor.
Fraco em: custo, cerca de N vezes os tokens, mais o tempo de revisão.
Exemplo: codex cloud exec --attempts ou dois CLIs diferentes com o mesmo prompt em worktrees separados.

Os padrões lado a lado

Padrão	Quem divide	Estado compartilhado	Como o código entra	Principal risco
Orquestrador e workers	O agente que chama	Resultados a quem chamou	Cópia de trabalho de quem chamou	Workers editam os arquivos dele
Líder e lista de tarefas	Agente líder	Lista de tarefas e mensagens	Em geral uma só pasta	Sobrescrita, gasto de tokens
Fan-out e merge	Planejador ou você	Plano escrito antes	Branches unidos com verificação	Conflitos de merge tardios
Cadeia de handoffs	Você, ao projetar	Saída da etapa anterior	Branch da última etapa	Lento, handoffs vagos
Best-of-N	Ninguém	Nenhum	Você escolhe um diff	Custo N vezes maior

O que dá errado e como resolver

Conflitos

Dois agentes numa mesma pasta acabam editando o mesmo arquivo. As defesas se somam: um worktree por agente que escreve, divisão por pasta e não por funcionalidade, posse explícita de arquivos e merge de um branch por vez sobre a ponta mais recente, para que o segundo merge veja o primeiro. Uma fila de merge é esse último passo feito direito.

Custo

Cada agente relê o código de que precisa, e cada mensagem entre agentes são tokens. A documentação da Anthropic diz que equipes de agentes usam bem mais tokens que uma sessão única e sugere começar com 3 a 5 colegas. Mantenha poucos agentes, dê aos workers um modelo mais barato onde a documentação permitir e limite o gasto por agente, para que um loop não queime o orçamento do dia.

Desvio e loops

Um agente pode se afastar do plano, repetir o mesmo comando com falha por vinte minutos, ou dois agentes podem fazer a mesma pergunta um ao outro sem parar. Critérios de aceitação claros para cada tarefa, um sinal explícito de “pronto” ou “travado”, limites de mensagens e um observador que nota comandos repetidos pegam a maior parte disso.

Confiança entre agentes

Se os agentes podem mandar mensagens uns aos outros, uma mensagem de outro agente não é uma mensagem sua. Trate-a como entrada, não como permissão: um agente não deve apagar um branch nem dar push na main só porque outro agente pediu.

Ferramentas por padrão

Subagentes do Claude Code (orquestrador e workers)

Subagentes são arquivos Markdown com frontmatter YAML em .claude/agents/ (projeto) ou ~/.claude/agents/ (usuário). Cada um roda na própria janela de contexto e devolve o resultado a quem chamou; o uso conta nos mesmos limites. Você restringe um subagente com tools ou disallowedTools e escolhe o modelo com model. Em outubro de 2026, subagentes podem por padrão abrir seus próprios subagentes até três níveis de profundidade, controlado por CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH (o valor 1 desliga o aninhamento).

---
name: test-triager
description: Roda os testes que falharam e informa a causa raiz. Usar depois de um CI vermelho.
tools: Read, Grep, Glob, Bash
model: sonnet
---
Rode os testes que falharam, encontre o primeiro erro real e informe arquivo, linha e causa em no máximo 15 linhas. Não edite arquivos.

Equipes de agentes do Claude Code (líder e lista de tarefas)

As equipes de agentes são experimentais em outubro de 2026 e vêm desativadas. Uma sessão vira líder; cada colega é uma instância separada do Claude Code com seu próprio contexto. Os colegas compartilham uma lista de tarefas com os estados pendente, em andamento e concluída e com dependências, pegam tarefas sozinhos e mandam mensagens diretamente uns aos outros. Ative em settings.json:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

Por padrão os colegas aparecem in-process, ou em painéis divididos via tmux ou iTerm2. A documentação lista limitações reais: não dá para retomar sessões de colegas in-process, o status das tarefas pode atrasar, uma equipe por sessão, sem equipes aninhadas e o líder é fixo. Ela também avisa que dois colegas no mesmo arquivo vão sobrescrever um ao outro, então divida o trabalho por arquivo. Os hooks TeammateIdle, TaskCreated e TaskCompleted permitem impor regras; o código de saída 2 bloqueia a ação.

Codex cloud (fan-out e best-of-N, remoto)

O Codex cloud executa tarefas num ambiente de nuvem que você configura, cada uma no próprio espaço de trabalho, e continua trabalhando enquanto o notebook dorme. Você revisa o diff, pede ajustes e então abre um PR ou aplica as mudanças localmente. O comando codex cloud está marcado como experimental em outubro de 2026:

codex cloud exec --env ENV_ID --attempts 3 "Corrija o teste de datas instável em billing/"
codex cloud list --env ENV_ID
codex apply TASK_ID   # aplica o diff localmente; sai com código diferente de zero se o git apply falhar

--attempts aceita de 1 a 4, o best-of-N mais simples possível. O Codex cloud é a melhor escolha quando o trabalho precisa sair da sua máquina; ele só roda o Codex.

Conductor (fan-out, Mac)

O Conductor roda Claude Code, Codex, Cursor e OpenCode em paralelo, cada tarefa num espaço de trabalho separado com branch, terminal e diff próprios, seguidos de revisão, PR, merge e arquivamento. Funciona só no Mac. Os planos em outubro de 2026: Free, Pro a US$ 50 por mês e Teams a US$ 60 por usuário por mês. Se a equipe toda usa macOS e quer uma interface caprichada para fan-out, é uma opção forte.

Claude Squad (fan-out, terminal)

O Claude Squad é uma interface de terminal que roda Claude Code, Codex, Gemini, Aider, OpenCode ou Amp em worktrees separados dentro do tmux. Tem licença AGPL-3.0 e precisa de tmux e do GitHub CLI; no Windows roda via WSL.

brew install claude-squad
cs              # Claude Code por padrão
cs -p "codex"   # outro agente

n abre uma sessão, Enter conecta, Ctrl-q desconecta e s faz commit e push. Se você vive no terminal, é a opção mais leve.

Vibe Kanban (fan-out, quadro)

O Vibe Kanban transforma tarefas em cartões, e cada cartão ganha um espaço de trabalho com branch, terminal e servidor de desenvolvimento próprios; comentários no diff vão para o agente, que pode abrir PRs. Suporta Claude Code, Codex, Gemini CLI, Copilot, Amp, Cursor, OpenCode, Droid, CCR e Qwen Code. O README agora diz que o projeto está sendo descontinuado, então em outubro de 2026 trate-o como mantido pela comunidade (Apache-2.0, npx vibe-kanban).

AgentVera (os cinco, local)

O AgentVera é um app de desktop para macOS, Windows e Linux que roda muitos CLIs de programação lado a lado, então você pode montar qualquer um dos padrões, e não só um:

Orquestrador e workers: o recurso “agentes que abrem agentes” (ativado por padrão) deixa um agente abrir ajudantes com as ferramentas spawn_agent, wait_agent, agent_status, message_agent e stop_agent. Um ajudante pode ser qualquer CLI instalado; pode trabalhar no próprio worktree num branch oto/… e aparece embaixo do agente pai. Por padrão cada agente abre até 3 ajudantes e no total rodam até 6 ao mesmo tempo; ajudantes não podem abrir agentes.
Líder e lista de tarefas: as mensagens entre agentes dão a cada agente send_message, reply_message, wait_reply e uma lista de tarefas compartilhada (task_add com responsável e dependências, task_claim, task_done, task_release). Quando as dependências de uma tarefa terminam, ela fica pronta e o responsável é avisado. Isso funciona entre CLIs diferentes, então o Claude Code pode passar uma tarefa ao Codex.
Fan-out e merge: a equipe paralela (planos Pro e Team) divide o trabalho em até 8 partes, cada uma com critérios de aceitação e arquivos esperados, roda cada parte no próprio worktree, 3 de cada vez por padrão e no máximo 6, e une tudo num branch de integração. A verificação é o comando de testes do projeto; um agente de integração corrige conflitos e falhas, e se a verificação continua vermelha depois de duas rodadas de correção, a equipe para.
Proteções para as falhas comuns: a posse de arquivos recusa, por um hook, edições do Claude Code fora dos caminhos do dono; a fila de merge une um branch por vez sobre a ponta mais recente; os orçamentos de tokens (desativados por padrão) limitam um agente por turno e por dia; o supervisor sinaliza um agente que repete o mesmo comando 5 vezes em 15 minutos, recebe o mesmo erro 3 turnos seguidos ou passa 20 minutos sem mudar nenhum arquivo.

Esses recursos são só locais: ajudantes abertos por agentes e mensagens não se estendem a agentes SSH. Se as tarefas precisam rodar na nuvem com o notebook fechado, o Codex cloud serve melhor.

Como escolher um padrão

O trabalho é principalmente leitura? Orquestrador e workers. Subagentes bastam.
Vários agentes precisam escrever código ao mesmo tempo? Fan-out em worktrees com um passo de merge. Nada de pastas compartilhadas.
As tarefas mudam conforme você descobre mais? Um líder com lista de tarefas compartilhada e 3 a 5 agentes.
Você roda a mesma tarefa toda semana? Uma cadeia de handoffs com aprovação antes da etapa de código.
A tarefa é difícil e a resposta não é óbvia? Best-of-N, e pague por isso de propósito.

Depois escolha a ferramenta pela plataforma: Conductor só no Mac, Claude Squad para o terminal, Codex cloud se o trabalho deve rodar remotamente, AgentVera se você quer vários CLIs e padrões num só app de desktop em qualquer sistema.

Uma pequena orquestração para testar hoje

O menor fan-out útil só precisa de git e dois CLIs:

git worktree add ../app-api -b feat/api
git worktree add ../app-ui -b feat/ui
(cd ../app-api && claude "Adicione o endpoint /invoices. Mexa só em src/api/.")
(cd ../app-ui && codex "Crie a página de faturas seguindo o contrato /invoices. Mexa só em src/ui/.")
git checkout -b integrate/invoices
git merge feat/api && npm test
git merge feat/ui && npm test

As regras que fazem isso funcionar estão escritas nos prompts: uma pasta por agente, um contrato combinado entre eles e os testes depois de cada merge. Tudo o que uma ferramenta acrescenta por cima (planejamento, listas de tarefas, supervisor, fila) automatiza uma dessas linhas. Para rodar Claude Code e Codex lado a lado em detalhe, veja agentes de programação em paralelo.

Conclusão

A orquestração de agentes de IA para programar depende menos da ferramenta e mais de três decisões: quem divide o trabalho, onde fica o estado compartilhado e como o código entra. Orquestrador e workers servem para leitura, uma lista de tarefas para trabalho que muda, fan-out com merge para mudanças grandes e separáveis, cadeias de handoffs para tarefas repetitivas e best-of-N para as difíceis. Seja qual for a escolha, coloque proteções contra conflitos, custo e desvio desde o primeiro dia.

Se quiser testar vários padrões num só lugar, baixe o AgentVera e comece com dois agentes e uma lista de tarefas compartilhada antes de ativar a equipe paralela.