A Orquestra de Agentes de Código — como fazer a codificação multiagente funcionar de verdade

• A transição do modelo de colaboração com um único assistente de IA em loop síncrono para um modelo de orquestrador, no qual vários agentes operam de forma assíncrona com suas próprias janelas de contexto e escopos de arquivos, está em andamento em 2026
• Três padrões centrais — Subagents, Agent Teams e delegação hierárquica — formam a estrutura básica da codificação multiagente, oferecendo respectivamente paralelismo, especialização, isolamento e aprendizado composto
• Lista de tarefas compartilhada e mensagens peer-to-peer são os principais mecanismos de coordenação de Agent Teams, permitindo liberação automática de dependências e evitando gargalos
• Em 2026, o ecossistema de ferramentas se divide em três camadas: subagentes in-process (Tier 1), orquestradores locais (Tier 2) e agentes assíncronos em nuvem (Tier 3); a maioria dos desenvolvedores usa uma combinação das três conforme o caso
• O gargalo deixou de estar na geração de código e passou para a verificação (Verification), e gates de qualidade via aprovação de plano, hooks, AGENTS.md e revisão humana são os fatores centrais que determinam a confiabilidade de sistemas multiagente

---

A transição atual: do maestro ao orquestrador

• Até 6 meses atrás, a maioria dos desenvolvedores trabalhava de forma síncrona com um único assistente de IA, e uma única janela de contexto era o limite superior do trabalho
• Hoje, os desenvolvedores mais produtivos estão migrando para uma forma de trabalho em que coordenam de modo assíncrono vários agentes, cada um com sua própria janela de contexto, escopo de arquivos e área de responsabilidade
• Modelo Conductor: guia um único agente em tempo real de forma síncrona; Claude Code CLI e o modo agente no editor Cursor são ferramentas representativas
• Modelo Orchestrator: coordena de forma assíncrona vários agentes, cada um com sua própria janela de contexto; Agent Teams, Conductor, Codex e Copilot Coding Agent são ferramentas representativas
• Como orquestrador, passam a ser necessárias novas habilidades: escrever especificações claras, decompor trabalho e validar entregas

Os 8 níveis da codificação com suporte de IA

• [Orquestração]
  • L8 — Construir seu próprio orquestrador: implementar por conta própria uma camada de coordenação, escrevendo em código a criação, o roteamento e o gerenciamento de agentes
  • L7 — 10+ agentes, gerenciamento manual: “Nossa, virou uma bagunça.” Contexto errado é passado para o agente errado, e começa a surgir a pergunta “e se o Claude Code rodar o Claude Code?”
  • L6 — Multiplexação de agentes: cansado de esperar, você vai executando mais um agente aqui e ali, alternando entre vários fluxos até não conseguir mais parar
• [Agente em primeiro lugar]
  • L5 — Agente primeiro, IDE depois: a conversa com o agente vira o espaço principal de trabalho, e a IDE fica para conferir o código
  • L4 — O diff desaparece e a conversa passa a liderar: em vez de revisar o diff toda vez, você observa o comportamento do agente e se concentra em orientar a direção
• [Era da IDE]
  • L3 — Modo YOLO: o agente executa livremente na IDE, com confiança crescente
  • L2 — Agente na IDE, aprovação manual de permissões: toda alteração de arquivo é autorizada manualmente, com controle totalmente manual
  • L1 — Sem IA: workflow tradicional de desenvolvimento
• Segundo o framework de 8 níveis de uso de ferramentas de IA organizado por Steve Yegge, a maioria dos desenvolvedores permanece nos níveis 3–4
• A camada de orquestração começa no nível 6 e exige um conjunto de habilidades fundamentalmente diferente daquele necessário para chegar até o nível 5
• Este conteúdo cobre os níveis 5 a 8

Limites do agente único

• Sobrecarga de contexto: um único agente tem limite na quantidade de informação que consegue manter, e codebases grandes excedem uma única janela de contexto
• Falta de especialização: um agente que lida com camada de dados, API, UI e testes continua sendo apenas um generalista; um agente dedicado só à camada de dados escreve código de banco muito melhor
• Falta de coordenação: mesmo adicionando agentes auxiliares, eles não conseguem se comunicar, compartilhar tarefas nem resolver dependências entre si; sem primitivas de coordenação, quanto mais agentes se adiciona, mais difícil fica gerenciar
• Subagentes resolvem os dois primeiros problemas, e Agent Teams resolve os três

Por que multiagente

• Paralelismo (3x de throughput): agentes de frontend, backend e testes trabalham ao mesmo tempo
• Especialização (contexto focado): cada agente conhece apenas os arquivos sob sua responsabilidade; um agente que conhece só db.js escreve código de banco melhor do que um agente que lida com a codebase inteira
• Isolamento (execução segura): Git worktrees oferecem um diretório de trabalho independente para cada agente, sem conflitos de merge
• Aprendizado composto: arquivos AGENTS.md acumulam padrões e cuidados entre sessões, fazendo cada sessão melhorar a seguinte
• Três agentes focados superam de forma consistente um único agente generalista trabalhando três vezes mais tempo

Padrão 1: Subagentes — delegação focada

• Use a ferramenta Task para criar agentes-filhos especializados a partir do orquestrador pai; é o padrão multiagente mais simples e o primeiro a ser testado
• Exemplo concreto: ao dar ao Claude Code o prompt “construa o gerenciador de favoritos Link Shelf com Express e SQLite”, o orquestrador pai decompõe isso em três briefs para subagentes
  • Subagente da camada de dados: constrói db.js e depois escreve o relatório DATA.md
  • Subagente de lógica de negócio: constrói validation.js e depois escreve o relatório LOGIC.md
  • Subagente de rotas de API: lê DATA.md e LOGIC.md e depois constrói server.js
• Os dois primeiros subagentes rodam em paralelo de forma independente, e o terceiro começa após a conclusão dos dois relatórios; o pai gerencia manualmente o grafo de dependências
• Limites dos subagentes: o pai precisa gerenciar manualmente o grafo de dependências, não há mensagens peer-to-peer nem lista de tarefas compartilhada entre agentes; se o controle de escopo de arquivos for frouxo, podem ocorrer conflitos
• Custo total em torno de 220 mil tokens, em um nível praticamente neutro em custo

• Subagentes hierárquicos (equipes de equipes)

  • Em vez de o orquestrador criar diretamente 6 subagentes, a estrutura cria 2 feature leads, e cada feature lead cria por conta própria 2–3 especialistas
  • O orquestrador pai gerencia apenas dois agentes, mantendo o contexto limpo; o feature lead A recebe o brief “construir funcionalidade de busca” e faz sua própria decomposição
  • O princípio é o mesmo de uma organização de engenharia real: um VP não distribui tarefas diretamente a engenheiros individuais, mas as repassa por meio de tech leads

Padrão 2: equipe de agentes — paralelismo de verdade

• Recurso experimental do Claude Code, ativado com o comando export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
• Arquitetura em 3 camadas:
  • Team Lead: decomposição do trabalho, criação da lista de tarefas, consolidação dos resultados
  • Lista de tarefas compartilhada: rastreamento de status (pending, in_progress, completed, blocked), dependências e bloqueio de arquivos
  • Membros da equipe: instâncias independentes do Claude Code, cada uma com sua própria janela de contexto, executadas em painéis divididos do tmux
• Os membros escolhem autonomamente tarefas da lista compartilhada e se comunicam diretamente por mensagens peer-to-peer (sem passar pelo líder)
• Quando um membro marca uma tarefa como concluída, as tarefas bloqueadas que dependiam dela são automaticamente desbloqueadas
• É possível alternar a sobreposição visual da lista de tarefas com Ctrl+T

• Mecanismos centrais da equipe de agentes

  • Lista de tarefas compartilhada: quando o agente de backend marca a API de busca como concluída, a tarefa bloqueada de escrever testes muda automaticamente para pending; o bloqueio de arquivos evita edição simultânea
  • Mensageria peer-to-peer: o agente de backend entrega diretamente o contrato da API ao agente de frontend — "GET /search?q= returns [{id,title,url}]"; isso evita que o líder vire um gargalo de coordenação
  • Quando um membro fica ocioso, o líder é notificado automaticamente

• Recomendações centrais para equipes de agentes

  • 3 a 5 membros é o ponto ideal; o custo em tokens cresce linearmente com o tamanho da equipe
  • Aprovação do plano: se um membro escrever um plano antes de implementar, o líder pode revisar e aprovar ou rejeitar; detectar problemas de arquitetura antes de o código existir sai muito mais barato
  • 3 membros focados têm desempenho consistentemente melhor do que 5 membros dispersos

• Dicas de confiabilidade para equipes de agentes

  • Guardrails de loop + etapa de reflexão: defina o limite MAX_ITERATIONS=8 para todos os membros; antes de cada nova tentativa, force o prompt de reflexão "O que falhou? Que mudança concreta pode corrigir isso? Estou repetindo a mesma abordagem?" → grande redução de agentes travados
  • Membro dedicado @reviewer: definir o Claude Opus 4.6 (somente leitura) como reviewer, usando apenas ferramentas de lint, teste e varredura de segurança, com acionamento automático a cada evento TaskCompleted; proporção de 1 reviewer para cada 3–4 builders; o líder sempre recebe apenas código já revisado

Padrão 3: orquestração em escala

• Ao gerenciar 5, 10, 20 ou mais agentes em vários repositórios e features, é necessário ter uma ferramenta de orquestração dedicada
• Tier 1 — subagentes e equipes in-process: subagentes e equipes de agentes do Claude Code; sessão única de terminal, sem necessidade de ferramentas adicionais; comece por aqui
• Tier 2 — orquestrador local: executa vários agentes em worktrees independentes, mantendo dashboard, revisão de diff e controle de merge; ideal para 3 a 10 agentes em bases de código conhecidas; Conductor, Vibe Kanban, Gastown, OpenClaw + Antfarm, Claude Squad, Antigravity, Cursor Background Agents
• Tier 3 — agentes assíncronos na nuvem: você delega a tarefa, fecha o notebook e espera o PR; execução em VM na nuvem; Claude Code Web, GitHub Copilot Coding Agent, Jules by Google, Codex Web by OpenAI
• Em 2026, a maioria dos desenvolvedores usará as três camadas: Tier 1 (trabalho interativo), Tier 2 (sprints paralelos), Tier 3 (processamento noturno do backlog)

Destaque de ferramentas

• Conductor by Melty Labs

  • A forma mais rápida de começar com orquestração multiagente no Mac; executa vários agentes Claude Code e Codex em paralelo em worktrees git independentes
  • Oferece dashboard visual e UI de revisão com foco em diff; cobra apenas o custo de API (gratuito); exclusivo para macOS (Apple Silicon e Intel)
  • Ideal quando é preciso tocar 3 a 8 features em paralelo no mesmo repositório com supervisão visual

• Claude Code Web

  • Acessível em claude.ai/code; totalmente baseado no navegador, sem necessidade de terminal; conecte um repositório do GitHub e insira a descrição da tarefa → execução em uma VM em nuvem gerenciada pela Anthropic
  • Suporta direcionamento intermediário, criação automática de PR e acesso pelo app iOS
  • Teams (terminal) é para trabalhar junto com o agente, enquanto Web (navegador) é para delegar e se afastar

• GitHub Copilot Coding Agent

  • Diferente do modo agente do Copilot na IDE (síncrono e interativo); o Copilot Coding Agent do GitHub é totalmente assíncrono
  • Basta atribuir qualquer issue do GitHub a @copilot ou iniciar pelo painel Agents → gera um draft PR no ambiente GitHub Actions
  • Executa um próprio loop de revisão antes de marcar; agentes de terceiros como Claude Code e Codex também podem ser acessados no mesmo painel; pode ser acionado via Slack, Jira, Linear e Azure Boards

• Jules by Google

  • Agente assíncrono de codificação em nuvem do Google, baseado em Gemini; conecte um repositório do GitHub → descreva a tarefa → o Jules gera um plano → após aprovação, executa em uma VM na nuvem → devolve um PR com todo o processo de raciocínio e logs de terminal
  • Oferece changelog em áudio, interrupção de tarefas em andamento e Jules Tools CLI para encaminhar issues do GitHub diretamente
  • Lê automaticamente o AGENTS.md do repositório sem configuração adicional

• OpenAI Codex Web

  • Cada tarefa é executada em um contêiner sandbox independente com o repositório do GitHub pré-carregado
  • Tem um ecossistema de superfícies que conecta Web, CLI (open source), app para macOS, extensão de IDE e integração com GitHub à conta do ChatGPT
  • Recurso de Verifiable Evidence: para cada tarefa, retorna citações de logs de terminal e saída de testes, permitindo auditar o histórico de execução

• Cursor Cloud Agents + Glass

  • É possível iniciar agentes via web, app de desktop, Slack, Linear, GitHub, API e PWA (instalação em cursor.com/agents)
  • Glass: nova interface do Cursor que transforma o gerenciamento de agentes na tela principal, enquanto o editor antigo vira uma ferramenta auxiliar acessada quando necessário
  • Reflete o padrão em que o control plane se torna a experiência principal em todo o ecossistema, e o editor passa a ser apenas um instrumento subordinado

• Vibe Kanban

  • Resolve o "doomscrolling gap" (o intervalo de 2 a 5 minutos enquanto o agente trabalha); ao criar cartões de tarefa e arrastá-los para "In Progress", cada um ganha sua própria worktree e branch
  • Permite revisar diffs dentro do board e enviar feedback a agentes em execução; suporta Claude Code, Codex, Gemini CLI, Amp, Cursor Agent CLI etc.; multiplataforma (Mac, Windows, Linux), gratuito, BYOK

Dicas para escalar

• Roteamento multimodelo

  • Nem toda tarefa precisa do modelo mais caro; crie um arquivo MODEL_ROUTING.md para fazer o roteamento por função:
    • Plano·arquitetura → modelos Gemini/Claude/OpenAI mais baratos
    • Implementação → Sonnet, Opus ou Codex
    • Revisão → modelo de segurança dedicado

• Scripts de ciclo de vida de worktree

  • Automatize o trabalho repetitivo com três aliases de shell:
    • agent-spin <feature>: cria worktree + branch + inicia o agente
    • agent-merge <feature>: rebase + revisão + criação de PR
    • agent-clean: remove worktrees concluídas
  • Cerca de 12 linhas de bash; o Conductor lida com isso visualmente

• Permita apenas AGENTS.md escrito por humanos

  • A pesquisa de Gloaguen et al. da ETH Zurich confirmou que arquivos AGENTS.md gerados por LLM não trazem benefício, e causam em média ~3% de queda na taxa de sucesso e mais de 20% de aumento no custo de inferência
  • Arquivos de contexto escritos por desenvolvedores oferecem ~4% de ganho de desempenho
  • Nunca permita que agentes escrevam diretamente em AGENTS.md; o líder deve aprovar cada linha
  • Mantenha-o conciso com seções claras: STYLE, GOTCHAS, ARCH_DECISIONS, TEST_STRATEGY

Portões de qualidade: confie, mas verifique

• Três portões de qualidade

  • Aprovação do plano: o membro da equipe escreve um plano antes de começar a codar → o líder revisa, aprova ou rejeita → implementação; corrigir um plano ruim custa muito menos do que corrigir código ruim
  • Hooks: verificações automatizadas em eventos do ciclo de vida; o hook TeammateIdle confirma se todos os testes passaram antes de o agente parar o trabalho; o hook TaskCompleted executa lint e testes antes de marcar como concluído; se o hook falhar, o agente continua trabalhando até passar
  • Aprendizado composto via AGENTS.md: captura padrões descobertos, cuidados e preferências de estilo; todos os agentes leem isso no início da sessão e ele é ampliado a cada sessão

• O gargalo se desloca para a verificação

  • Agentes conseguem gerar resultados impressionantes em velocidade surpreendente; a parte difícil é ter certeza de que esses resultados estão corretos
  • Testes que passavam antes da mudança não garantem que vão detectar regressões causadas pela mudança
  • Agentes podem escrever testes tecnicamente válidos, mas que deixam passar casos importantes
  • Devido aos limites da janela de contexto, agentes trabalhando em grandes codebases podem deixar passar restrições importantes fora da visão atual
  • Um ambiente instável que é apenas um caso extremo irritante para um único desenvolvedor vira um bloqueio sistêmico quando 40 agentes encontram o mesmo teste instável ao mesmo tempo
  • Até que a infraestrutura de verificação acompanhe a capacidade de geração, a revisão humana é um sistema de segurança, não um custo opcional adicional

Ralph Loop e agentes de autoaperfeiçoamento

• Padrão Ralph Loop

  • Popularizado por Geoffrey Huntley e Ryan Carson; o padrão por trás de “entregar enquanto você dorme”; a ferramenta independente de Carson, ralph (snarktank/ralph), implementa o loop central, enquanto o projeto Antfarm adiciona orquestração multiagente sobre o OpenClaw
  • Ciclo de 5 etapas: Pick (seleciona a próxima tarefa em tasks.json) → Implement (faz as mudanças) → Validate (executa testes·tipos·lint) → Commit (faz commit e atualiza o status da tarefa se as verificações passarem) → Reset (reinicializa o contexto do agente antes de seguir para a próxima tarefa)
  • Insight central: resetar a cada iteração evita o acúmulo de confusão; tarefas pequenas e bem delimitadas geram menos alucinações e código mais limpo do que um único prompt gigantesco
  • Proteções: retornar erros como feedback para permitir retry automático, mas encerrar e reatribuir se travar mais de 3 vezes; sempre trabalhar em feature branch; definir limites de iteração, tempo e tokens; o agente cria o PR → revisão humana antes do merge
  • Mantenha 4 canais de memória entre resets de contexto: histórico de commits do git, log de progresso, arquivo de status de tarefas (tasks.json) e AGENTS.md como memória semântica de longo prazo

• Tornando os agentes mais inteligentes com o tempo

  • Autorreflexão via REFLECTION.md: após cada tarefa, obrigue o registro de “o que foi surpreendente, um padrão para adicionar ao AGENTS.md, uma melhoria de prompt”; o líder revisa e incorpora os aprendizados aprovados
  • Orçamento de tokens e critérios de encerramento: defina limites por agente (ex.: frontend 180 mil tokens, backend 280 mil tokens); pausa automática em 85% do orçamento e alerta ao líder; se travar 3 vezes ou mais no mesmo erro, encerre e reatribua a um novo agente
  • Beads / memória persistente: o padrão “beads” da Gastown — registro imutável e baseado em git de todas as decisões e resultados com procedência completa; agentes consultam beads anteriores por meio de um grafo de tarefas e um data plane endereçável por SQL; memória institucional estruturada e consultável, não um RAG vetorial simples

A disciplina que faz tudo isso funcionar

• O gargalo humano era um recurso, não um bug

  • Quando você escreve código na velocidade humana, sente a dor cedo; falhas de teste, apontamentos de code review, descoberta de duplicação — a dor é imediata, então você corrige enquanto avança
  • Com um exército de agentes orquestrados, não existe gargalo natural; pequenos erros (code smell, duplicação, abstração desnecessária) se amplificam de forma composta numa velocidade impossível de acompanhar
  • Como você está fora do loop, não sente a dor até que a arquitetura deixe de permitir novas funcionalidades
  • É por isso que todos os portões de qualidade (aprovação de plano, hooks, orçamento de tokens, revisão humana) existem: sem eles, a codificação com agentes leva você a um beco sem saída

• Delegue tarefas, mas retenha o julgamento

  • O que delegar aos agentes: tarefas bem delimitadas com critérios claros de aprovação/reprovação, boilerplate, migrações, scaffolding de testes, exploração de abordagens para as quais você não teria tempo de experimentar diretamente
  • O que manter com você: arquitetura e design de API (agentes aprenderam muitas arquiteturas ruins nos dados de treinamento e podem aplicar padrões enterprise a startups sem critério), decidir o que não construir (dizer não é uma habilidade que agentes não têm), revisar a saída dos agentes com o contexto do sistema inteiro
  • Se você perder o entendimento do próprio sistema, perde a capacidade de corrigir, expandir e detectar mau funcionamento

• A especificação é a alavanca

  • Ao orquestrar 50 agentes em paralelo, pensamento ambíguo não apenas reduz a velocidade — ele é amplificado por dezenas de execuções paralelas
  • A diferença entre um resultado mediano e um resultado excelente depende quase inteiramente da qualidade da especificação
  • Uma especificação ambígua amplifica erros por toda a frota; uma especificação precisa, com arquitetura clara, fronteiras de integração, casos extremos e invariantes, amplifica implementação precisa em toda a operação
  • O trabalho mecânico de digitar código está sendo automatizado; o trabalho cognitivo de entender o sistema é amplificado por toda uma frota de trabalhadores autônomos

O modelo de fábrica

• Já não se trata apenas de escrever código, mas de construir uma fábrica que produz software
• Linha de produção em 6 etapas: Plan (escrever especificações com critérios de aceitação) → Spawn (criar equipe e atribuir agentes) → Monitor (verificar o progresso a cada 5–10 minutos·resolver bloqueios, sem ficar pairando) → Verify (executar testes·revisar código; a verificação é o gargalo) → Integrate (mesclar branches·resolver conflitos) → Retro (atualizar AGENTS.md com novos padrões; aprendizado composto)
• Dicas práticas:
  • Defina limite de WIP: não execute mais agentes do que você consegue revisar com sentido; 3–5 é o ponto ideal
  • Defina critérios de encerramento: se travar 3 vezes ou mais no mesmo erro, pare e reatribua
  • Check-ins assíncronos: verifique o progresso a cada 5–10 minutos; deixe os agentes trabalharem de forma autônoma
  • Um dono por arquivo: não deixe dois agentes editarem o mesmo arquivo; conflitos destroem a velocidade

5 padrões para começar hoje

1. Decomposição em subagentes: crie agentes-filhos focados com a ferramenta Task, com briefing específico e propriedade de arquivos; sem necessidade de configuração; comece hoje
2. Paralelismo com uma equipe de agentes: ative CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1; crie um líder + 3 membros da equipe; coordene com uma lista de tarefas compartilhada
3. Isolamento com Git worktree: dê a cada agente seu próprio worktree; sem conflitos de merge; o Conductor cuida disso automaticamente
4. Portas de qualidade para confiança: exija aprovação de plano para mudanças arriscadas; adicione hooks que executem testes quando a tarefa terminar; não confie na saída do agente sem validação
5. Aprendizado composto com AGENTS.md: documente padrões, cuidados e preferências de estilo; leia e atualize a cada sessão; o conhecimento é ampliado de forma composta

[kurthong]

Não sei se é uma característica dos engenheiros, mas não entendo por que ficam se alongando com um discurso aparentemente plausível, porém sem profundidade. Também é um tema que me interessa, então li com atenção, mas no fim não há conteúdo de fato.

[stroke33]

O motivo definitivo para usar o Claude Code com afinco — fazer minha própria orquestração com múltiplos agentes funcionando de verdade

Estou rodando 5 agentes agora, mas os tokens somem rápido pra caramba, dá até vontade de chorar.