Explicado

Vários agentes de IA em um mesmo repositório

Vários agentes podem compartilhar um repositório se a escrita for arbitrada: um agente anuncia os caminhos que vai tocar, o servidor os atribui a ele, e os nega a todos os outros até que ele os libere. Sem essa arbitragem, o segundo agente apaga o trabalho do primeiro sem que nada sinalize.

O caso que quebra tudo

Dois agentes recebem duas tarefas que tocam o mesmo arquivo. O primeiro lê o arquivo, pensa por vinte segundos, escreve. O segundo leu a mesma versão antes de o primeiro escrever, e escreve por cima. Nada travou, nada avisou, e o trabalho do primeiro desapareceu.

Esse caso não é raro assim que há mais de um agente, porque os agentes leem amplo e escrevem rápido. É por isso que quase todas as ferramentas isolam: uma máquina por agente, uma branch por agente.

O que o resto do mundo faz: um worktree por agente

A resposta comum a esse problema é o particionamento: dá-se a cada agente seu próprio worktree git, uma cópia completa dos arquivos com seu próprio índice, e organiza-se para que os perímetros não se sobreponham. É o que fazem Windsurf, Conductor e OpenHands, e é o que a maioria dos guias recomenda.

Funciona, e tem exatamente um defeito: o particionamento é uma promessa, não uma garantia. Ninguém verifica se os perímetros não se sobrepõem, e quando se sobrepõem isso só se descobre na fusão, quando os dois agentes já terminaram e ninguém mais se lembra do raciocínio.

A reserva, em três tempos

Antes de escrever, um agente anuncia os caminhos que vai tocar. O painel os atribui a ele se estiverem livres, e os nega se estiverem ocupados. Um único titular por arquivo, a qualquer momento.

Durante o trabalho, um observador acompanha as escritas reais no disco e atribui cada uma ao seu autor. Uma escrita em um caminho detido por outro agente é fotografada antes de ser gravada: a versão anterior é preservada, então nada se perde mesmo quando a regra é contornada.

No final, o agente libera seus caminhos. O arquivo volta a ficar disponível para o próximo, sem fusão, porque nunca existiram duas versões vivas ao mesmo tempo.

Como isso aparece na tela

Cada janela mostra seu agente trabalhando, e o painel mostra quem detém o quê. Dá para ver que um agente está esperando, e por quê. Um agente bloqueado fica visível antes de causar estrago, que é a real diferença em relação a uma fila de espera invisível.

As pessoas também contam. Várias pessoas no mesmo canvas pilotam seus próprios agentes e veem os cursores dos outros, cada um com um nome.

Quando essa não é a forma certa

Se suas tarefas são realmente independentes e longas, o isolamento por máquina continua sendo razoável: nada para arbitrar, nada para esperar. O compartilhamento ganha quando as tarefas se tocam, o que acontece assim que se trabalha na mesma funcionalidade. As comparações detalham a escolha ferramenta por ferramenta.

Respostas diretas

É preciso usar git worktree para rodar vários agentes?

É a resposta que a maioria dos guias dá, e funciona: um worktree por agente, cada um com seu próprio índice e seus arquivos, então nenhuma colisão é possível. Tem um custo, e é sempre o mesmo: tantas cópias quanto agentes, e uma fusão por cópia no final. Um único diretório com uma reserva de arquivo elimina os dois, ao preço de um agente que às vezes espera trinta segundos.

Por que não dar uma branch para cada agente?

É a solução comum e ela empurra o custo para o final. Três branches produzem três fusões, e os conflitos aparecem quando os três agentes terminaram, ou seja, no momento em que ninguém mais se lembra do raciocínio. Um diretório compartilhado resolve o conflito no momento em que ele acontece.

O que acontece se um agente ignorar a reserva?

Ele não tem escolha: a regra é aplicada pelo servidor, não sugerida ao modelo. Um observador monitora as escritas e atribui cada uma ao seu autor, e uma escrita em um caminho detido por outro agente é fotografada antes de ser gravada, então as duas versões continuam existindo.

Quantos agentes ao mesmo tempo?

Cinco janelas de agente no plano Pro, e mais nos planos acima. O limite prático não é a máquina, é o número de frentes independentes que o projeto tem em um dado momento.