A orquestra de agentes: por que 3 especialistas vencem 1 generalista em produção

TL;DR Pareamento com um único agente é o que a maioria pratica — e é onde a maioria empaca. Times produtivos hoje coordenam 3 a 5 agentes especializados, cada um com contexto próprio, rodando em worktrees isolados, sincronizando por uma task list compartilhada, com portões de qualidade automatizados. O gargalo deixou de ser geração de código — virou verificação. E a alavanca não é mais o prompt: é a especificação.

O teto do agente único

Quem trabalha com agentes há mais de seis meses já sentiu: existe um patamar onde adicionar mais prompts não acelera mais nada. Três restrições explicam o teto:

Restrição 1

📚 Sobrecarga de contexto

Bases reais de cliente passam de qualquer janela. Quando o agente precisa "lembrar" de tudo ao mesmo tempo, ele esquece o essencial.

Restrição 2

🎯 Sem especialização

Um agente que faz banco, API, UI e testes vira um "pau-pra-toda-obra" — competente em nada. O agente que só conhece a camada de dados escreve melhor SQL.

Restrição 3

🚦 Sem coordenação

Vários agentes sem primitivos de coordenação (lock de arquivo, dependências de tarefa) viram caos. Conflitos de merge consomem o ganho de paralelismo.

Maestro vs orquestrador

A metáfora que melhor descreve a virada (devemos a Addy Osmani): você sai de maestro — guiando um músico em tempo real — para orquestrador — coordenando uma orquestra inteira de forma assíncrona. A conversa de chat deixa de ser o ambiente; o repositório (e o quadro de tarefas) passa a ser.

Dimensão	Maestro (1 agente)	Orquestrador (time)
Modo	Síncrono — você espera cada resposta	Assíncrono — você planeja e revisa
Contexto	Sua janela é o teto	N janelas independentes, uma por especialista
Throughput	1× — sequencial	~3× com 3 agentes em paralelo
Workspace	Thread de chat	Repositório + worktrees + task list
Sua função	Digitador de prompts	Engenheiro de processo: spec, gates, retro

Três padrões de orquestração

Em produção, usamos três padrões — escolhidos pelo escopo da tarefa, não pela moda:

Padrão 1

🌿 Subagents

Pai decompõe, delega a filhos focados, gerencia o grafo de dependência manualmente. Zero setup — começa hoje. Custo neutro em tokens.

Setup: Nenhum
Sweet spot: 2–4 filhos

Padrão 2

👥 Agent Teams

Time Lead + task list compartilhada com lock de arquivo + mensageria peer-to-peer. Auto-desbloqueio de tarefas quando dependências caem.

Sweet spot: 3–5 agentes
Coordenação: Task list + locks

Padrão 3

☁️ Cloud Async

Atribui a tarefa, fecha o laptop, volta no PR. Roda em VMs gerenciadas — no nosso caso, sobre Agent Runtime do Gemini Enterprise Agent Platform.

Modo: Fire-and-forget
Sessão: Dias contínuos

O gargalo deixou de ser geração. Virou verificação. Revisão humana não é overhead opcional — é o sistema de segurança.

Os números que importam

~3×

Throughput
3 agentes em paralelo

3–5

Sweet spot do time
acima disso, dispersão

−3%

Quando IA escreve o AGENTS.md
+20% de custo (ETH Zurich)

O número da direita é importante: pesquisa de Gloaguen et al. (ETH Zurich) mostra que deixar agentes escreverem o próprio AGENTS.md piora o desempenho em ~3% e aumenta o custo em mais de 20%. O AGENTS.md precisa ser curado por humano — é o que codifica o conhecimento institucional do time.

AGENTS.md: o cérebro compartilhado

Quatro seções bastam:

## STYLE
- Functional components com hooks; named exports
- Erros sempre tipados; nunca `throw "string"`

## GOTCHAS
- SQLite exige WAL para leituras concorrentes
- Ordem dos middlewares Express importa para auth

## ARCH_DECISIONS
- Estado em SQLite, sem cache em memória
- Um Express router por feature module

## TEST_STRATEGY
- Integration > unit para rotas HTTP
- supertest para asserções de request

Toda sessão lê. Nenhum agente escreve direto — o lead aprova cada linha que entra.

5 práticas para começar amanhã

Comece com subagents

Decomponha a tarefa em 2–3 filhos com escopo cirúrgico. Sem setup. É o jeito mais barato de provar a tese internamente.

Isole com worktrees

Cada agente em seu próprio worktree git. Zero conflito de merge — e diff por feature trivial de revisar.

Plan approval antes de codar

Teammate escreve o plano; lead aprova ou rejeita. Corrigir arquitetura na fase de plano custa 1/10 do que corrigir em código.

Hooks rodando lint + test

No TaskCompleted, valide automaticamente. Se falhar, o agente continua. Lead só vê código verde — funciona como CI embutido.

Compound learning via AGENTS.md

Toda sessão lê, lead atualiza. Padrões e gotchas viram memória de longo prazo do time — não precisam ser redescobertos a cada sprint.

⚠️ Armadilha clássica Subir 10 agentes em paralelo só porque dá. WIP limit é virtude: rode no máximo o número que você consegue revisar de fato. Acima de 5 agentes, geralmente significa "estou gerando dívida que outro humano vai pagar".

O que muda na Autenticare

Esse modelo só fecha em produção quando há infraestrutura para sustentar. É exatamente o que o Gemini Enterprise Agent Platform (anunciado em 22/04 — análise completa aqui) entregou:

Agent Runtime dá os “VMs gerenciadas” do padrão Cloud Async — cold start <1s, sessões de dias.
Memory Bank + Memory Profiles é o AGENTS.md elevado a primitivo de plataforma — memória de longo prazo entre sessões.
Agent Sandbox é o worktree isolado em produção — código gerado roda sem risco para o sistema real.

Não é coincidência. O caminho da indústria é o mesmo: da execução pontual de prompt para a fábrica de agentes.

Você não está mais escrevendo software. Está construindo a fábrica que escreve o software.

Engenharia agêntica em produção

Quer migrar do agente único para uma orquestra?

Estruturamos times de 3 a 5 agentes sobre Gemini Enterprise Agent Platform — com worktrees, AGENTS.md curado, hooks de qualidade e plan approval. Auditável, repetível e mensurável.

Falar com a Autenticare → Ver Fábrica de Agentes

Inspirado em "The Code Agent Orchestra" de Addy Osmani (Google Chrome). Adaptado para o stack que operamos na Autenticare sobre Gemini Enterprise Agent Platform.