Como trabalhar com vários agentes de IA em paralelo - Cursor e Claude Code

Se você usa agentes de coding no dia a dia, e segue um approach de spec-first development, provavelmente você vive essa cena várias vezes no dia: você trabalhou bastante no plano, revisou os detalhes, alinhou junto ao agente, então você aprova o plano! O handoff aconteceu, agora é com o Opus! Ou GPT, Sonnet, Composer... O importante é que o agente começou a executar seu plano. E agora? Você fica ali? Parado? Esperando e apreciando?

Bom, o humano no loop, que antes passava horas codando, ajustando e testando, agora consegue ter capacidade ociosa neste momento. Então, fazemos o que fazemos melhor: Otimizar nosso output!

Sabe como? Paralelizando o trabalho com múltiplos agentes!

Três formas de paralelizar

Existem várias maneiras, mas vou destacar aqui três abordagens, que são as que eu mais uso no dia a dia:

1. Tarefas independentes: multi-sessão + Git Worktrees

Você trabalha em duas frentes diferentes, como se fossem duas pessoas pegando dois tickets distintos. Cada agente roda em uma sessão própria, dentro de um git worktree isolado (um checkout separado, com sua própria branch, compartilhando o mesmo histórico). Eles não pisam no pé um do outro, e no final cada um envia um PR separado. Uso muito este approach para quando estou trabalhando em uma feature, seguindo spec-first e aparece um bug ou um spike que preciso fazer também. Aqui o humano é o orquestrador principal e os agentes são os executores individuais.

2. Mesma tarefa, partes paralelas: multi-sessão

Vamos a um exemplo:
Temos a demanda de uma feature média que toca em pontos diferentes do código. Exemplo real: adicionar um novo meio de pagamento que afeta três fluxos (adição do meio de pagamento, processamento do checkout e cancelamento). Depois de um TDD bem feito e um plano seguro, você inicia três agentes separados para atacar cada parte da feature, um irá fazer o ajuste na adição do meio de pagamento, outro irá fazer o ajuste no processamento do checkout e outro irá fazer o ajuste no cancelamento do checkout. Neste caso, o humano ainda é o orquestrador principal e os agentes são os executores individuais. Como neste approach estamos falando da mesma feature, o risco é maior de conflitos ou desvios, então é importante um bom planejamento ainda na fase de TDD e planejamento.

3. O agente gerencia o paralelismo: Agent Teams (ou Multi-tasking)

Podemos usar o mesmo exemplo anterior, mas agora vamos usar o agent-teams (ou multi-tasking) do agente. O agente será o orquestrador e os sub-agentes serão os executores. Vamos passar para o agente o TDD completo e deixar a cargo dele o gerenciamento de sub-agentes e a sincronização dos resultados. Este é um approach promissor que está sendo explorado pela comunidade e está sendo aprimorado pelos principais provedores e IDEs.

A discussão e uma talk sobre isso

Este discussão começou na comunidade Craft Code Club, fizemos uma talk sobre isso. A talk foi gravada e está disponível no YouTube: Como rodar VÁRIOS agentes de IA em paralelo | Claude Code, Cursor e VS Code.

Mas bom, trazendo aqui em forma de artigo também para complementar a discussão e pegar mais opiniões e experiências.

O segredo é o planejamento

O consenso: quanto melhor o planejamento do paralelismo antes de disparar os agentes, melhor o resultado. O fluxo que tem funcionado:

1. Fazer o research junto com o agente e identificar o que dá para paralelizar
2. Gerar um plano ou design doc em markdown (um artefato que todos os agentes vão referenciar)
3. Disparar os agentes, cada um apontando para sua parte do plano mas com o contexto da feature como um todo também.
4. Revisar tudo localmente antes de abrir os PRs (o humano continua no loop)

Sem isso, o paralelismo vira uma confusão de context switching: você foca em uma coisa, esquece a outra, e o ganho de produtividade evapora. Nem toda tarefa precisa de paralelismo, e nem todo momento pede multitasking.

Um uso interessante além de features: POCs competindo. Você dispara dois agentes com variações do prompt, modelo ou harness, para o mesmo objetivo (duas versões de um layout, por exemplo) e escolhe a melhor. É capitalizar no não determinismo do agente.

Na prática: Cursor

No Cursor 3, também conhecido como Glass, cada novo chat pode nascer em um worktree novo: basta selecionar a opção ao criar a sessão com worktree. Assim você já pode rodar vároios agents no mesmo projeto, fazendo alterações e sem se tocarem.

O diferencial do cursor são os setup scripts: como o worktree é uma pasta nova (sem node_modules, sem .env), você configura um script que roda npm ci, e no exemplo citador na comunidade e no vídeo, voê pode até mesmo gerar uma porta baseada no hash da branch e assim rodar o projeto em paralelo sem conflitos. Resultado: duas instâncias do mesmo projeto rodando lado a lado em portas diferentes, cada uma com seus testes e até Playwright rodando em paralelo.

Dois cuidados que apareceram no papo: o setup script tem timeout (projetos com onboarding de 10+ minutos vão falhar; nesse caso, considere um esquema de "slots" com pastas pré-configuradas) e VPNs podem atrapalhar o npm ci.

O Cursor também tem o modo multitasking: na mesma sessão, ele dispara subagentes para executar partes da tarefa em paralelo ("faça o post 1 e o post 2 ao mesmo tempo"), protegendo o contexto principal. E os cloud agents permitem rodar a sessão em uma máquina remota enquanto você acompanha do editor, um "worktree" na nuvem.

Na prática: Claude Code

O Claude Code oferece vários caminhos, do mais manual ao mais automático:

claude --worktree (ou -w): inicia a sessão já dentro de um worktree isolado, criado em .claude/worktrees/<nome>/ com uma branch worktree-<nome>. Abra outro terminal, rode de novo com outro nome, e você tem duas sessões paralelas e isoladas. Você também pode simplesmente pedir no meio da conversa ("trabalhe em um worktree") e o agente cria um worktree na hora.

.worktreeinclude: o equivalente aos setup scripts do Cursor para arquivos. Como o worktree é um checkout limpo, arquivos gitignorados como .env não vêm junto. Esse arquivo (com sintaxe de .gitignore) lista o que deve ser copiado automaticamente para cada worktree novo.

Background e agent view: dentro de qualquer sessão do claude code, /background (ou /bg) manda a conversa para segundo plano sem interrompê-la. O comando claude agents abre a agent view: uma tela única com todas as sessões em background, agrupadas por estado (trabalhando, precisando de input, concluídas). Dali você despacha novas sessões, espia o que cada uma está fazendo, responde sem precisar abrir a sessão, ou abre a sessão quando quer a conversa completa.

Detalhe inteligente: sessões despachadas da agent view são bloqueadas de escrever arquivos até se moverem para um worktree isolado, o que o Claude faz automaticamente quando percebe que vai editar. Enquanto é só leitura, nada é criado.

Dá até para começar direto do shell: claude --bg "investigue esse bug: [link do slack]". Um processo supervisor mantém tudo rodando mesmo se você fechar o terminal.

Agent Teams: quando os agentes conversam entre si

Não deu tempo de demonstrar no vídeo, mas merece destaque: o Claude Code tem os Agent Teams (experimental, habilitado via CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS).

A diferença para subagentes é a comunicação. Subagentes só reportam o resultado de volta para o agente principal. Em um agent team, uma sessão atua como team lead (coordena, atribui tarefas e sintetiza resultados) e os teammates são instâncias completas do Claude Code, cada uma com sua própria janela de contexto, que compartilham uma task list e trocam mensagens diretamente entre si. Você também pode falar com qualquer teammate individualmente, sem passar pelo lead.

Os casos de uso mais fortes, segundo a própria documentação:

• Research e review: vários teammates investigam aspectos diferentes do problema e desafiam as descobertas uns dos outros
• Debugging com hipóteses competindo: cada teammate testa uma teoria e eles debatem para chegar à causa raiz (combate o viés de ancoragem de uma investigação sequencial)
• Features cross-layer: frontend, backend e testes, cada um com seu dono
• Módulos novos: cada teammate é dono de uma peça, sem conflito de arquivos

Recursos interessantes: você pode exigir plan approval (o teammate trabalha em modo read-only até o lead aprovar o plano), usar definições de subagentes como papéis reutilizáveis e visualizar tudo em split panes com tmux ou iTerm2. O custo: cada teammate é uma instância separada, então o consumo de tokens escala linearmente. Para tarefas sequenciais ou rotineiras, uma sessão única ou subagentes continuam mais eficientes. A recomendação é começar com 3 a 5 teammates em tarefas de research e review.

Worktree é só para projeto pequeno?

Não. Esse é um mito que apareceu nas conversas. A questão não é o tamanho do projeto, é o setup. Com setup scripts e .worktreeinclude bem configurados, worktrees funcionam até em projetos com mais de vinte anos de código. Worktree não é para projeto pequeno; é para quando você precisa de paralelismo.

O fundamento importa mais que a ferramenta

Cursor e Claude Code convergiram para os mesmos conceitos: worktrees para isolamento de arquivos, subagentes para proteger o contexto, uma visão central para orquestrar sessões. Quem entende o fundamento troca de ferramenta sem dor. Muda o comando, não o conceito.

Compartilhe sua visão e experiência

• Como você tem trabalhado com agentes em paralelo?
• Conta aí nos comentários.

---

Se quiser ver tudo isso acontecendo na prática, o vídeo com as demos completas está aqui: https://youtu.be/Alfy6IakEVU

Tanto o vídeo quanto este artigo nasceram de papos que surgiram naturalmente na comunidade: alguém compartilha uma experiência, outros testam, questionam, e o assunto cresce. Se você curte esse tipo de troca, a Craft Code Club é uma comunidade aberta de estudos: Comunidade no Discord