Para executar agentes de codificação em paralelo, forneça a cada agente seu próprio git worktree e branch, alimente-os a partir de uma fila de planos previamente revisados por um humano, execute testes e linters dentro de cada worktree antes que qualquer pessoa examine o diff, e registre detalhadamente o custo de cada plano. A maioria das equipes atinge essa arquitetura passando por três padrões preliminares: um único agente em uma janela de chat, um agente por branch iniciado manualmente e uma fila de tarefas com agentes workers. Cada padrão resolve um gargalo imediato e expõe o próximo desafio. Este guia aborda esses quatro padrões, os pontos de ruptura em cada etapa e as seis responsabilidades que um orquestrador precisa assumir.

Os quatro padrões

Os "8 Níveis de Desenvolvimento Assistido por IA" de Steve Yegge (2025) fornecem uma estrutura conceitual bastante útil. O loop iterativo fundamental — raciocinar sobre a etapa, agir, observar o resultado, repetir — é o mesmo formalizado em Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, e cada padrão apresentado a seguir representa uma resposta distinta sobre quem supervisiona esse ciclo. No momento em que este artigo é escrito, a maioria das equipes está nos níveis 2 e 3: um desenvolvedor envia um prompt para o agente, revisa o código gerado e faz o commit. A orquestração com agentes paralelos, memória contínua e filtros de revisão representa o nível 8.

Padrão 1: Um único agente na janela de chat

Um desenvolvedor abre o terminal ou um painel da IDE, descreve uma tarefa e assiste ao agente editando arquivos no diretório de trabalho local. O rendimento é estritamente limitado a uma tarefa por desenvolvedor por vez, já que humano e agente compartilham o mesmo checkout. Se uma segunda tarefa for iniciada antes do término da primeira, as duas alterações se misturarão na mesma árvore de arquivos, e o diff resultante perderá todo o sentido.

Padrão 2: Um agente por branch, iniciado manualmente

O passo seguinte consiste em fornecer a cada tarefa seu próprio branch e seu próprio diretório de trabalho. Os git worktrees tornam essa abordagem extremamente leve: um único armazenamento de objetos compartilhado com múltiplos diretórios de trabalho isolados.

# A partir do diretório principal:
git worktree add ../feature-search-button -b feature/search-button
cd ../feature-search-button
claude "Add a search button to the sidebar. Run the tests when done."

Um desenvolvedor agora pode executar dois ou três agentes simultaneamente, cada um em sua própria pasta. O que quebra aqui é o gerenciamento operacional: ninguém registra qual worktree corresponde a qual tarefa, e os prompts ficam perdidos no histórico de rolagem do terminal. Para piorar, se dois agentes alterarem os mesmos arquivos, conflitos de merge graves surgirão no momento da integração final.

Padrão 3: Uma fila com agentes worker em worktrees isolados

Quando a equipe passa a rodar mais do que um punhado de agentes, a etapa de inicialização manual torna-se o principal gargalo do processo. A solução imediata é uma fila: tarefas são enfileiradas, processos worker as capturam, criam um worktree, executam o agente, realizam o push do branch e abrem um pull request. Frameworks de pesquisa multiagente como AutoGen formalizam exatamente essa dinâmica de workers e filas.

No entanto, eliminar o julgamento humano do início de cada tarefa expõe uma nova falha crítica. Nada avalia a especificação da tarefa antes que o agente comece a codificar; como resultado, tarefas mal definidas queimam tokens caros em pull requests indesejados. Além disso, nada valida o código antes da abertura do PR, transformando os revisores humanos em um gargalo sobrecarregado. E como a fila roda sem supervisão ativa, os custos acumulam-se silenciosamente.

Padrão 4: Ciclo de vida de planos com checkpoints de revisão

O padrão definitivo adiciona dois checkpoints humanos e uma etapa de verificação automatizada. A tarefa é formalizada em um plano escrito. Um humano lê e valida o plano antes que qualquer linha de código seja gerada. Os agentes são executados em worktrees estritamente isolados. Testes, linters e o resumo do diff rodam dentro do worktree — seguindo o mesmo princípio da integração contínua, aplicada por agente em vez de por desenvolvedor. Um humano analisa o diff. Somente após essa dupla aprovação o pull request é aberto.

O Ivy define esse padrão como uma fábrica de software (software factory): um fluxo de trabalho estruturado e repetível no qual qualquer modificação percorre rigorosamente os mesmos estágios e supera as mesmas duas validações humanas. Veja O que é uma software factory para a definição aprofundada.

O que falha em cada estágio

Padrão	O que resolve	Qual o próximo problema
Agente individual em chat	Nada ainda; é a referência inicial	Uma tarefa por dev; diretório compartilhado e instável
Um agente por branch, manual	Tarefas simultâneas sem conflito de pastas	Perda de contexto, prompts não versionados, conflitos no merge
Fila com workers desatendidos	Fim da inicialização manual de tarefas	Tarefas e códigos sem validação prévia, custos descontrolados
Ciclo de vida com checkpoints	Elimina desperdício e código não verificado	Exige ferramental para fila, isolamento, testes, custo e memória

As seis responsabilidades indispensáveis de um orquestrador

Um orquestrador é a camada de software responsável por executar com consistência o padrão 4. Ele deve cobrir com excelência seis atribuições essenciais; a ausência de qualquer uma delas forçará uma intervenção manual recorrente, restabelecendo o gargalo no fluxo:

Fila de tarefas (Queue): Os planos aguardam em ordem determinada com status claros: rascunho (draft), aprovado (approved), em execução (executing), em verificação (verifying), em revisão (in review), integrado (merged). O progresso deve ser transparente sem a necessidade de abrir um terminal.
Isolamento: Cada plano ativo recebe seu próprio worktree e branch independentes. O branch principal jamais recebe gravações diretas de agentes. Git worktrees para agentes de IA paralelos demonstra por que os worktrees superam checkouts compartilhados e contêineres pesados.
Verificação automatizada: Testes, linters, checagem de tipos e resumo do diff são executados dentro do worktree assim que o agente conclui o trabalho, antes que qualquer pessoa veja a alteração. Falhas retornam automaticamente para o agente com os logs de erro anexados.
Revisão humana (Review): Exatamente dois checkpoints — no plano e no diff —, cada um com comandos explícitos de aprovação ou rejeição. Rejeitar na fase de plano tem custo zero de tokens de código. Rejeitar na fase de diff custa apenas uma iteração de execução.
Contabilidade de custos: Tokens e orçamento financeiro auditados por plano e por tarefa, permitindo identificar o custo real de cada pull request integrado e os valores alocados em planos descartados.
Memória persistente: O aprendizado acumulado por um agente em um plano deve estar disponível para os planos seguintes; caso contrário, cada agente recomeça do zero e repete indefinidamente os mesmos erros.

Como o Ivy Tendril implementa essa arquitetura

O Ivy Tendril é um aplicativo desktop local-first para macOS, Windows e Linux que opera o padrão 4 com qualquer agente de codificação baseado em linha de comando (CLI). Também pode ser operado em modo headless via tendril --web.

Fila de tarefas: O painel Plans centraliza todos os planos com seus respectivos status. As seções Drafts, Icebox e Recommendations organizam os itens antes da aprovação. Planos podem ser gerados via webhooks a partir de issues do GitHub e relatórios de bugs do jam.dev, ou pelo servidor MCP, API REST e CLI.
Isolamento: Ao disparar a execução, o Tendril provisiona um git worktree e um branch específicos para aquele plano. Múltiplos planos rodam simultaneamente em paralelo. Concluído o merge, o Tendril remove o worktree de forma limpa. Veja Git worktrees para agentes de IA paralelos.
Verificação: O aplicativo de Review organiza os testes, o lint e o diff em abas dedicadas para cada plano. Nos planos Pro, os resultados de verificação podem ser importados diretamente do seu pipeline de CI.
Revisão humana: No checkpoint do plano, o revisor pode executar ações como Expand, Split ou Update sobre o rascunho, ou adicionar comentários pontuais para que o plano seja reformulado. O checkpoint do diff ocorre logo após a verificação automática. Nenhuma pull request é gerada sem ambas as aprovações.
Contabilidade de custos: Tokens e gastos são medidos por plano e por job, com um painel Dashboard que exibe métricas-chave e tendências de custo.
Memória com Promptware: Cada etapa do ciclo de vida é executada por uma unidade de promptware, composta por um arquivo Program.md com diretrizes que evoluem, uma pasta Memory/ com aprendizados permanentes do repositório, Tools/ com permissões delimitadas e Logs/ de auditoria. Unidades nativas incluem CreatePlan, ExpandPlan, ExecutePlan, UpdatePlan, SplitPlan, CreatePr e CreateIssue. Veja promptware.

O Tendril é totalmente agnóstico em relação aos agentes. Ele suporta Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode e qualquer outro agente de terminal, permitindo alternar o agente ou o modelo conforme a necessidade de cada plano. O código-fonte permanece seguro em sua máquina; as únicas chamadas externas são para a API do modelo configurado e para o GitHub.

A própria equipe de engenharia do Ivy relata que saltou de cerca de 10 para mais de 100 pull requests por dia após adotar esse fluxo de trabalho.

Como começar

Instale o Tendril: execute curl -sSf https://cdn.ivy.app/install-tendril.sh | sh no macOS ou Linux, ou irm https://cdn.ivy.app/install-tendril.ps1 | iex no Windows. Instruções completas na página de instalação.
Abra um repositório na aplicação e adicione a chave de API do provedor de modelos que você já utiliza.
Crie um plano a partir de uma issue existente, revise o rascunho, dispare a execução e inspecione o diff no aplicativo Review.
Assim que o primeiro plano for integrado, dispare três planos ao mesmo tempo e acompanhe a execução concorrente.

O Tendril é gratuito e tem código disponível sob a Functional Source License; recursos para times, SSO corporativo, implantação on-premise e sincronização de verificações de CI fazem parte dos planos Pro (US$ 59 por usuário/mês) e Enterprise.

Perguntas frequentes

Preciso de contêineres para rodar agentes em paralelo?

Não. Os git worktrees fornecem a cada agente seu próprio diretório de trabalho e branch compartilhando a mesma base de objetos. Contêineres adicionam isolamento de runtime, o que só é essencial se os agentes precisarem instalar pacotes no sistema operacional ou vincular portas de rede; a grande maioria das tarefas de desenvolvimento de software não requer isso.

Quantos agentes podem rodar simultaneamente?

O limite prático geralmente decorre dos rate limits da API do provedor de modelos e da capacidade de processamento da sua máquina para rodar testes, não do orquestrador. Comece com três a cinco planos paralelos e expanda a carga conforme as verificações continuem sendo concluídas rapidamente.

O que acontece quando dois planos alteram o mesmo arquivo?

O segundo plano que tentar fazer merge enfrentará um conflito de integração no seu branch. A forma ideal de mitigar isso ocorre na fase de planejamento: divida ou ordene sequencialmente os planos que tocam nos mesmos módulos antes da execução, funcionalidade viabilizada pela ação Split no Tendril.

Primeiros passos com o Ivy Tendril

Pronto para a orquestração paralela de agentes em nível de engenharia?

Explore o código: Confira o Ivy Tendril no GitHub (Código aberto).
Consulte a documentação: Encontre guias de integração em tendril.ivy.app.
Agende uma sessão técnica: Entre em contato pelo e-mail renco@ivy.app para uma consultoria de arquitetura de 30 minutos.

Padrões de orquestração de agentes: como rodar agentes de código em paralelo