Eu vou ser direto com você.
Em fevereiro de 2026, todos os grandes players de AI coding lançaram multi-agente na mesma quinzena. Grok Build com 8 agentes. Windsurf com 5 paralelos. Codex CLI com Agents SDK. Devin com sessões paralelas. E o Claude Code com Agent Teams.
Não foi coincidência. Foi a indústria inteira reconhecendo que rodar 1 agente por vez é o novo “digitar código na mão”. É funcional, mas é lento demais para quem compete de verdade.
E aí eu olho para as software houses que mentoro e vejo a mesma cena: vinte devs, cada um com sua licença de Claude Code, cada um rodando 1 sessão por vez, em sequência. O dev pede para o Claude fazer o backend. Espera. Depois pede o frontend. Espera. Depois os testes. Espera. É como ter uma fábrica com 20 linhas de montagem e usar só 1 por vez.
Na v2.1.97, o Claude Code adicionou um indicador simples no /agents: ● N running — um badge que mostra quantos agentes estão rodando em paralelo. Parece pouco. Mas esse badge só existe porque agora o Claude Code tem uma feature que muda completamente como times de desenvolvimento operam: Agent Teams.
O que são Agent Teams
Agent Teams é a capacidade de rodar múltiplas instâncias do Claude Code trabalhando juntas, em paralelo, no mesmo codebase. Não é subagent — que é um worker que faz uma tarefa e reporta de volta. É um time coordenado onde cada agente tem seu próprio contexto, suas próprias ferramentas, e pode se comunicar diretamente com os outros.
A arquitetura é simples:
| Componente | Função |
|---|---|
| Team Lead | A sessão principal que cria o time, distribui tarefas e sintetiza resultados |
| Teammates | Instâncias independentes do Claude Code, cada uma com seu contexto |
| Task List | Lista compartilhada de tarefas que teammates reclamam e completam |
| Mailbox | Sistema de mensagens para comunicação direta entre agentes |
Você fala com o lead em linguagem natural. Ele cria teammates, distribui tarefas, e orquestra tudo. Os teammates trabalham de forma independente — cada um no seu contexto, com seus arquivos, suas ferramentas. E quando um termina, reclama a próxima task da lista automaticamente.
Crie um agent team para refatorar o módulo de autenticação.
Spawn 3 teammates:
- Um focado em segurança (token handling, session management)
- Um refatorando a camada de dados (queries, migrations)
- Um cobrindo testes (unit + integration)O lead cria os três. Cada um trabalha no seu domínio. Eles se comunicam entre si quando precisam — “ei, mudei a interface do UserRepository, atualiza seus testes” — sem passar pelo lead. Isso não existe em subagents. Subagents fazem e reportam. Teammates colaboram.
A diferença que importa: subagents vs Agent Teams
Eu sei que muita SH já usa subagents. E subagents são ótimos — para tarefas focadas onde só o resultado importa. Pesquisar algo, verificar um arquivo, rodar um script.
Mas subagents têm uma limitação fundamental: eles não conversam entre si. O subagent A não sabe o que o subagent B está fazendo. Cada um reporta de volta ao agente principal, e o principal precisa orquestrar tudo.
Agent Teams inverteu isso:
| Subagents | Agent Teams | |
|---|---|---|
| Comunicação | Só reportam ao agente principal | Teammates conversam diretamente |
| Coordenação | Agente principal gerencia tudo | Task list compartilhada, auto-coordenação |
| Contexto | Resultados resumidos voltam ao contexto do caller | Cada teammate mantém contexto completo |
| Ideal para | Tarefas focadas onde só o resultado importa | Trabalho complexo com discussão e colaboração |
Na prática: use subagents para “vai lá e me traz a resposta”. Use Agent Teams para “investiguem isso juntos, discordam entre si, e cheguem numa conclusão”.
Como funciona na prática
1. Code review paralelo com 3 lentes
Uma das coisas que mais me incomoda em code review de SH é que um único reviewer tende a focar em um tipo de problema por vez. Ou ele olha segurança, ou performance, ou cobertura de testes. Raramente os três ao mesmo tempo com a mesma profundidade.
Crie um agent team para revisar a PR #142. Spawn 3 reviewers:
- Um focado em implicações de segurança
- Um verificando impacto de performance
- Um validando cobertura de testes
Peça que cada um revise e reporte os achados.Três agentes, três lentes, simultâneo. O lead sintetiza os achados no final. Isso é 4x mais tokens que uma review single-agent — mas quanto custa um bug de segurança em produção? O custo médio de um breach em sistemas com IA é de US$4.88 milhões (IBM, 2025). Eu prefiro gastar US$5 a mais em tokens.
2. Debugging com hipóteses concorrentes
Essa é a que mais me impressiona. Quando o bug não é óbvio — e na minha experiência com 300+ SHs, os bugs que realmente machucam nunca são óbvios — um único agente tende a encontrar uma explicação plausível e parar. Confirma a primeira hipótese e ignora as alternativas.
Agent Teams resolve isso com adversarialidade:
Usuários reportam que o app fecha após uma mensagem em vez de manter
a conexão. Spawn 5 teammates para investigar hipóteses diferentes.
Peça que conversem entre si para tentar REFUTAR as teorias uns dos
outros, como um debate científico. Atualizem o doc de findings com
o consenso que emergir.Cinco agentes, cinco hipóteses, debatendo entre si. A teoria que sobrevive é muito mais provável de ser a causa raiz real. Investigação sequencial sofre de ancoragem — uma vez que você explora uma teoria, tudo depois é enviesado para confirmá-la. Multi-agente adversarial elimina isso.
3. Feature cross-layer
Backend, frontend, testes — tudo ao mesmo tempo. Cada teammate dono de uma camada, comunicando mudanças de interface em tempo real:
Crie um agent team para implementar o novo endpoint de pagamentos.
- Teammate 1: backend (API endpoint, validação, integração gateway)
- Teammate 2: frontend (formulário, estado, chamadas API)
- Teammate 3: testes (unit backend, integration, e2e frontend)
Exija aprovação de plano antes de implementar.Note o "Exija aprovação de plano". Isso ativa plan approval — o teammate trabalha em modo read-only planejando a abordagem, envia o plano para o lead, e só implementa após aprovação. Para tarefas críticas em SH, isso é essencial.
O custo real e como gerenciar
Vou ser honesto: Agent Teams gasta mais. Um time de 3 teammates usa 3-4x os tokens de uma sessão single fazendo o mesmo trabalho sequencialmente. Se seu dev gasta US$15/dia normalmente, com Agent Teams pode ir a US$50-60/dia em tarefas complexas.
Mas o cálculo que importa não é token por token. É custo por entrega.
Dados de 2026:
- 171% ROI médio em deployments de agentes IA, 192% em enterprises nos EUA (OneReach AI)
- 3.6 horas/semana economizadas por dev com AI coding tools (Panto/Index.dev)
- Multi-agent outperforma single-agent em 90.2% em benchmarks internos
- 66.4% do mercado já foca em arquiteturas multi-agent (Master of Code)
Um debug que levaria 4 horas sequenciais pode ser resolvido em 1 hora com 5 agentes paralelos. Custou 4x em tokens? Sim. Mas o dev ficou livre 3 horas antes. E em SH, hora de dev é o recurso mais caro que existe.
Como controlar custos
O Claude Code já tem ferramentas para isso:
/cost— breakdown por modelo e cache hits (cobrimos no artigo sobre FinOps de tokens)- OTEL observability — métricas de custo por sessão, por dev, por modelo em tempo real (cobrimos no artigo sobre OTEL e TRACEPARENT)
- Effort levels por teammate — você pode rodar teammates com Sonnet (mais barato) e o lead com Opus (mais capaz)
- 3-5 teammates — é o sweet spot. Mais que 5 e o overhead de coordenação começa a anular os ganhos
Crie um time com 4 teammates para refatorar esses módulos em paralelo.
Use Sonnet para cada teammate.O lead continua usando o modelo padrão (Opus, se disponível), mas os teammates rodam com Sonnet — que é 5x mais barato. Para tarefas de implementação paralela, Sonnet resolve perfeitamente. Reserve Opus para o lead que precisa sintetizar e decidir.
A peça que faltava: visibilidade
Até a v2.1.97, você criava um agent team e… não sabia exatamente o que estava rodando sem verificar manualmente. O novo indicador ● N running no /agents mostra em tempo real quantos agentes estão ativos. Parece trivial. Mas na prática é a diferença entre orquestrar um time e largar no escuro.
Combinado com:
- Shift+Down para navegar entre teammates (modo in-process)
- Split panes via tmux/iTerm2 para ver todos ao mesmo tempo
- Task list compartilhada (Ctrl+T) para ver status de cada tarefa
- Hooks de qualidade:
TeammateIdle(feedback quando teammate para),TaskCreated,TaskCompleted
Você tem um painel de controle de um time de agentes. Não é diferente de um tech lead acompanhando o board do Jira — exceto que os “devs” são agentes IA que não tomam café, não têm reunião de daily, e não pedem férias.
O que os concorrentes estão fazendo
Eu acompanho todos os AI coding tools do mercado. Fevereiro de 2026 foi o mês que multi-agent virou commodity. Em uma janela de duas semanas:
- Grok Build: 8 agentes paralelos
- Windsurf: 5 agentes paralelos
- OpenAI Codex CLI: Agents SDK com orquestração
- Devin: sessões paralelas com coordenação
- Claude Code: Agent Teams com task list compartilhada e comunicação direta
O diferencial do Claude Code? Comunicação direta entre teammates e task list com auto-coordination. Os outros fazem paralelo, mas cada agente trabalha isolado e reporta ao orchestrator. No Claude Code, os teammates discutem, discordam, e chegam a consensos sozinhos. É a diferença entre paralelismo e colaboração.
Addy Osmani (Google Chrome team) colocou bem: o futuro do coding é orquestração, não digitação. E a Anthropic demonstrou construindo um compilador C inteiro com um time de Claudes paralelos. Não como prova de conceito — como workflow de produção.
Configuração em 2 minutos
Agent Teams é experimental e desabilitado por padrão. Para ativar:
// settings.json
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}Ou direto no terminal:
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1Depois é linguagem natural. Descreva a tarefa, diga quantos teammates quer, e o Claude faz o resto.
Modo de display:
- In-process (padrão): todos no mesmo terminal, Shift+Down para navegar
- Split panes: cada teammate no seu painel (requer tmux ou iTerm2)
Para split panes:
// ~/.claude.json
{
"teammateMode": "tmux"
}Dica de ouro: comece com tasks de research e review antes de colocar Agent Teams para implementar código. Os resultados são mais previsíveis e você aprende a orquestrar sem risco.
O que eu penso
Eu mentoro mais de 300 software houses desde 2016. E o padrão que mais vejo é SH que compra ferramenta e usa 20% da capacidade. Claude Code não é exceção — a maioria dos times usa como um autocomplete glorificado.
Agent Teams é a feature que transforma o Claude Code de “assistente do dev” para “time virtual”. Um dev orquestrando 5 agentes paralelos entrega como um time de 3. E não é exagero — os dados mostram que multi-agent supera single-agent em 90.2% em tarefas complexas.
O melhor dev de 2026 não é o que digita mais rápido. É o que orquestra melhor. É quem sabe decompor um problema em tarefas paralelas, configurar teammates com as lentes certas, e sintetizar os resultados. Isso é uma skill nova que nem existia há 6 meses.
As SHs que vão dominar os próximos 2 anos não são as que têm mais devs. São as que têm devs que sabem operar times de agentes. E Agent Teams é a ferramenta que faz isso acontecer — hoje, não num futuro hipotético.
Se você quer implementar esse nível de capacidade na sua software house, precisa de dois movimentos: primeiro, ativar a variável. Segundo, treinar seu time a pensar em tarefas paralelas em vez de sequenciais. Essa mudança de mentalidade é mais difícil que configurar a ferramenta.
Sou Thulio, mentoro 300+ SHs desde 2016. E nunca vi uma mudança de paradigma tão rápida quanto a transição de single-agent para multi-agent. Quem não fizer nos próximos 6 meses vai competir com metade da capacidade.
Quer se aprofundar? Leia também:
