Quando vale a pena usar vários agentes no Claude Code em vez de um só?

Fala aí, beleza? Você abre um Claude Code, aí abre outro, aí lembra que dava pra pedir pro próprio Claude quebrar aquilo tudo em cinco agentes e resolver de uma vez

Parece sempre mais rápido

E em boa parte dos casos não é: o trabalho fica mais lento, mais caro e MUITO mais confuso de acompanhar

Hoje o Claude Code tem quatro formas distintas de paralelizar trabalho: subagents, agent view, agent teams e dynamic workflows. A escolha entre elas depende de uma pergunta só: você quer acompanhar cada conversa, delegar e conferir depois, ou deixar o Claude coordenar um grupo de trabalhadores?

Este post não é lista de agente pronto pra copiar e colar. É sobre o critério de decisão: que formato de trabalho realmente ganha com vários agentes no Claude Code, e qual só ganha peso extra 🙂

O formato de trabalho que ganha com paralelismo

Antes de escolher o canal, olha o FORMATO da tarefa. Quando dividir compensa, três características aparecem juntas:

• Autocontida: a subtarefa executa de forma independente, sem ficar pedindo aval
• Pronta para paralelismo: uma não depende do output em tempo real da outra
• Pesada em contexto: sozinha ela inundaria a sessão principal com logs ou resultados de busca verbosos

Se a sua tarefa não bate nas três, provavelmente você está tentando paralelizar algo que é sequencial disfarçado

O limiar prático do isolamento de contexto:

Isolar contexto tem um ponto em que passa a valer a pena. A orientação oficial é bem específica: o isolamento é mais eficaz quando a subtarefa gera alto volume de contexto (mais de 1000 tokens) mas a maior parte da informação é irrelevante para a tarefa principal, quando a subtarefa é bem definida com critério claro do que extrair, e em operações de busca ou consulta que exigem filtragem antes do uso

Uma analogia pra fixar: é como mandar alguém ler o relatório inteiro e te trazer só as três linhas que importam

Se o relatório é curto, ou se você precisa dele INTEIRO na mesa o tempo todo, não faz sentido terceirizar nada

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Exemplos concretos que a documentação cita:

• Despachar uma correção de bug, uma revisão de pull request e uma investigação de teste instável como três linhas de trabalho separadas (esse é o caso oficial do agent view)
• Auditorias de codebase, migrações grandes e pesquisa com verificação cruzada (esse é o caso oficial do dynamic workflow)

Repara no padrão: em todos eles, cada frente produz um resultado próprio e ninguém precisa esperar o vizinho terminar pra começar

Peça o paralelismo de forma explícita:

Dica pequena e que muda o resultado: ser explícito funciona melhor que pedir genericamente

Pedir "use 5 tarefas paralelas" é mais claro pro modelo do que "paralelize esse trabalho"

Bora ver agora o outro lado, que é o lado que quase ninguém escreve?

Quando um agente só entrega mais que vários

A conversa principal continua sendo a escolha certa em MUITA situação. A documentação lista os casos:

• Quando a tarefa exige vaivém frequente com você
• Quando várias fases compartilham contexto pesado (planejar, implementar e testar sobre a mesma imagem em evolução)
• Quando é uma mudança rápida e pontual
• Quando latência importa, porque um subagent começa do zero e gasta tempo juntando um contexto que a thread principal já tem na mão

Acrescenta a isso o que vale pra qualquer sistema multiagente: componentes fortemente acoplados, que exigem vaivém constante entre si, pertencem ao mesmo agente. E agentes que precisariam sincronizar entendimento com frequência devem permanecer juntos

Pra agent teams a orientação é ainda mais direta: em tarefas sequenciais, edições no mesmo arquivo ou trabalho com muitas dependências, uma sessão única ou subagents são mais eficazes

E tem a conta do token, que é onde dói:

Segundo dados da própria Anthropic, agentes usam cerca de 4x mais tokens que interações de chat, e sistemas multiagente usam cerca de 15x mais tokens que chats

No caso dos agent teams o motivo é claro: cada teammate tem a sua própria janela de contexto, e o consumo escala com o número de teammates ativos

Ou seja: multiagente só é economicamente viável em tarefas cujo valor seja alto o bastante pra pagar o ganho de performance

É a mesma conta de decidir se a tarefa vale delegar em primeiro lugar, só que multiplicada pelo número de agentes que você ligou

Subagents, agent view, agent teams e dynamic workflows: qual usar em cada caso

Decidiu que a tarefa tem o formato certo? Agora sim escolhe o canal. Cada um reporta resultado pra um destino diferente, e é isso que mais muda o dia a dia:

Um pouco mais sobre cada um:

O subagent é uma instância isolada do Claude, com system prompt próprio, janela de contexto própria, lista de ferramentas própria e modo de permissão próprio. Isolamento total, e é justamente por isso que ele não sabe nada do que você conversou até agora

Na prática eles são arquivos Markdown com frontmatter YAML, guardados em dois escopos possíveis: ~/.claude/agents/ para o escopo de usuário e .claude/agents/ para o escopo de projeto. Só os campos name e description são obrigatórios no frontmatter

Detalhe massa: o Claude Code observa essas pastas e detecta alterações em poucos segundos, sem exigir reinício da sessão. Você edita o arquivo e a próxima delegação já usa a definição atualizada 😀

Tome cuidado com uma mudança recente aqui: o comando /agents deixou de abrir o assistente interativo de criação. A partir da v2.1.198 ele apenas imprime um lembrete pra você pedir ao Claude ou editar .claude/agents/ direto. Arquivos, campos e localizações seguem exatamente iguais, então nada do que você já tinha quebrou

Se essa parte ainda te confunde, escrevi um post inteiro sobre a diferença entre skills, comandos e subagentes, que é onde a maioria se perde antes mesmo de pensar em paralelizar

E os subagents que já vêm prontos?

Existem três registrados por padrão em sessões interativas, sem você definir nada: Explore, Plan e general-purpose

• Explore: rápido e read-only, com Write e Edit negados
• Plan: para desenhar o caminho antes de mexer
• general-purpose: é pra ele que o Claude delega quando a tarefa exige exploração e modificação juntas, raciocínio complexo para interpretar resultados, ou múltiplos passos dependentes

Um detalhe que pega gente desprevenida: Explore e Plan são de uso único e não podem ser retomados. São one-shot e não retornam agent ID. Pra continuar o trabalho de onde parou, tem que ser general-purpose ou um subagent customizado

Agent teams vem desligado, se liga:

Agent teams é um recurso experimental e desativado por padrão. Pra habilitar, você define CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 no settings.json ou no ambiente

Sem essa variável, nenhum time é montado no início da sessão, nenhum diretório de time é escrito e o Claude nem cria nem propõe teammates. Se você achou que estava usando time e não estava, provavelmente é isso

Outra restrição importante: criar teammates exige sessão interativa. Em modo não interativo com a flag -p, incluindo sessões do Agent SDK, o Claude não cria teammates, e um subagent nomeado roda como subagent comum mesmo com agent teams habilitado

Quando o time existe, a sessão principal atua como lead e o time se forma no momento em que o primeiro teammate é criado. O lead dá nome a cada teammate, e qualquer teammate pode mensagear outro por esse nome

E os worktrees, entram onde?

Worktrees isolam sessões paralelas em checkouts git separados, pra que as mudanças não colidam. Cada sessão no seu worktree significa que as edições de uma nunca tocam os arquivos da outra

A localização padrão dos worktrees criados pelo Claude Code é <project-root>/.claude/worktrees/, e eles exigem repositório git. Pra outros sistemas de controle de versão, é preciso configurar hooks pra substituir a lógica do git

Agora anota isso porque é a pegadinha número um: agent teams NÃO isolam teammates em worktrees

Por que times de agentes ficam lentos e confusos (e como evitar)

Tem três modos de falha que se repetem em quem divide o trabalho errado. Vale reconhecer o sintoma antes de culpar o modelo

1. Mais token gasto coordenando do que executando

Sintoma: a fatura sobe, o relógio anda, e o resultado final chega pior do que sairia numa sessão só. Cada repasse entre agentes perdeu um pedaço do entendimento

Causa: times construíram sistemas multiagente elaborados e descobriram exatamente isso: perda de contexto em cada handoff e mais tokens gastos coordenando do que executando. Acontece quando você divide um trabalho que precisaria sincronizar entendimento o tempo todo

Prevenção: componentes que exigem vaivém constante ficam no MESMO agente. Se dois agentes precisariam conversar a cada cinco minutos pra continuar, eles são um agente só

2. Um agente sobrescrevendo o arquivo do outro

Sintoma: você revisa o diff no fim e falta código que existia. Alguém salvou por cima

Causa: agent teams não isolam teammates em worktrees, então a divisão de arquivos é responsabilidade de quem orquestra, e não do sistema

Prevenção: quebrar o trabalho de forma que cada teammate seja dono de um conjunto DIFERENTE de arquivos. Se você não consegue fazer esse recorte, é sinal claro de que a tarefa não deveria ser dividida

3. Time parado esperando ordem

Sintoma: você habilitou tudo, criou os teammates, e a maioria fica ociosa enquanto um trabalha sozinho

Causa: teammates não se auto-atribuem trabalho. Ninguém pega tarefa por conta própria

Prevenção: o lead precisa atribuir toda tarefa, e deve atribuir todas as tarefas prontas logo no começo, distribuindo de forma equilibrada entre os agentes disponíveis

Uma observação pra fechar: no dynamic workflow o próprio script guarda o loop, a ramificação e os resultados intermediários, e o contexto do Claude fica só com a resposta final. Isso reduz bastante o problema de handoff, porque a memória do processo vive no script e não numa conversa que vai se degradando

E o script ainda permite aplicar padrões de qualidade repetíveis, tipo agentes independentes revisando de forma adversarial os achados uns dos outros, ou rascunhar um plano por vários ângulos e comparar. Isso é bem insano quando você precisa de confiança no resultado

O que aprendi montando uma empresa inteira de agentes

Essa parte é experiência de primeira mão mesmo

Eu montei um mapa mental do conceito antes do setup e depois fiz a instalação passo a passo, usando o Claude Code como um dos agentes contratados dentro de um orquestrador

A analogia que uso pra explicar o modelo é simples: o agente individual é o funcionário, e o orquestrador é a empresa, que distribui os papéis e faz cada um executar a sua parte

Configurei a empresa com um objetivo único e escrevi a primeira tarefa do agente CEO já pedindo que ele definisse a estrutura do time e produzisse o primeiro entregável. O objetivo que escrevi foi bem concreto: 1 artigo de blog por dia, com pelo menos 800 palavras, em português do Brasil

Aí veio a parte que mais me marcou: o CEO parou sozinho e travou o fluxo pedindo autorização pra contratar novos agentes

Foram 3 contratações pedidas logo na primeira tarefa (diretor de marketing, pesquisador e escritor). A solicitação caiu na inbox e eu pude aprovar, rejeitar ou pedir revisão. Depois que aprovei, o time se expandiu pra 4 agentes e o orquestrador seguiu pra etapa seguinte sem precisar de novo comando meu

Pra mim é isso que dá governança: ações críticas que geram custo sobem pro humano decidir

E repara como esse teste bate certinho com o critério do post: papéis com ENTREGAS SEPARADAS (pesquisar, escrever, divulgar) funcionam bem em paralelo. O gargalo nunca apareceu na execução, apareceu na coordenação

Outras escolhas que fiz e o porquê:

• Defendo rodar o orquestrador em VPS em vez do PC pessoal, pro time continuar trabalhando sem depender da minha máquina ligada e pra eu monitorar a distância (instalar no próprio computador funciona, foi o que fiz na demonstração)
• Em vez de liberar a porta pra acessar a dashboard pelo navegador, optei por um túnel SSH com redirecionamento de porta, porque deixar o painel exposto me pareceu arriscado
• O primeiro teste de ambiente do agente FALHOU: o CLI do Claude não estava presente no servidor. Instalei, conferi a versão, fiz login pela conta (dava pra usar API também) e o teste passou

Na dashboard dá pra acompanhar em tempo real: agentes habilitados, tarefa em progresso, gasto do mês, inbox, hierarquia do time, skills usadas e log de atividade. Uma coisa eu não soube responder na hora: se o custo apareceria estimado no painel, porque eu estava usando conta por assinatura e não a API

A dor que me levou pra esse caminho é provavelmente a sua também: quem mantém vários Claude Code abertos acaba fazendo alt+tab violento entre janelas e se perdendo entre os trabalhos haha

Os indícios de que vale dividir, na minha experiência: você já usa mais de um Claude Code ao mesmo tempo, quer coisas acontecendo sem você iniciar o processo, precisa monitorar custos, tem vários objetivos em paralelo e quer auditoria do que foi executado

E os casos em que NÃO vale: trabalhar com um agente por vez num projeto só, tarefas pontuais sem continuidade, situações em que um setup simples já entrega o resultado, e uso casual ou exploratório de IA

No vídeo acima eu mostro o processo inteiro na prática: o mapa mental, a instalação, o teste de ambiente falhando, o CEO pedindo aprovação pras contratações e a dashboard rodando com o time trabalhando

Veredito: o critério de decisão em três perguntas

Na hora de decidir, esquece a lista de agentes prontos e responde três perguntas sobre a tarefa que está na sua frente:

1. As subtarefas rodam sem depender do output em tempo real uma da outra?
2. Cada agente consegue ser dono de um conjunto diferente de arquivos?
3. O contexto gerado é volumoso e majoritariamente descartável pra tarefa principal?

Três sim: divide, e escolhe o canal pela tabela lá de cima

Um não que seja: fica na conversa principal ou usa um subagent só pra aquela parte pesada em contexto

E tem a régua econômica por cima de tudo: o custo extra precisa ser pago pelo valor da tarefa. Com agentes usando cerca de 4x mais tokens que chat e multiagente cerca de 15x, dividir tarefa pequena é queimar dinheiro pra chegar mais devagar

Começar simples e escalar quando doer é MUITO mais barato que montar um time elaborado de saída. Foi assim que os sistemas elaborados demais viraram estudo de caso de perda de contexto em handoff, e não de produtividade

Conclusão

Recapitulando o essencial: vários agentes no Claude Code compensam em trabalho autocontido, paralelizável e pesado em contexto. Um agente só compensa em vaivém frequente, contexto compartilhado entre fases, mudança pontual e quando latência importa

Os quatro canais existem justamente porque o problema não é um só: subagents pra delegar de dentro da conversa, agent view pra acompanhar linhas independentes, agent teams (experimental, desligado por padrão) pra um time coordenado por um lead, e dynamic workflows quando a coisa passa do que uma conversa consegue coordenar

Próximo passo bem concreto: pega a próxima tarefa grande da sua semana, roda as três perguntas nela e testa primeiro com subagents dentro da própria sessão. Só depois disso pensa em time

E se quiser experimentar agent teams, lembra dos dois pré-requisitos: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 no settings.json ou no ambiente, e sessão interativa (com a flag -p não rola)

Vou continuar testando essas configurações por aqui e no canal, então cola junto pra ver os próximos experimentos

até o próximo post! 😀