Explicado

Varios agentes de IA en un mismo repositorio

Varios agentes pueden compartir un repositorio si la escritura está arbitrada: un agente anuncia las rutas que va a tocar, el servidor se las asigna, y se las niega a todos los demás hasta que las libera. Sin ese arbitraje, el segundo agente borra el trabajo del primero sin que nada lo señale.

El caso que lo rompe todo

Dos agentes reciben dos tareas que tocan el mismo archivo. El primero lee el archivo, piensa veinte segundos, escribe. El segundo leyó la misma versión antes de que el primero escribiera, y escribe encima. Nada falló, nada avisó, y el trabajo del primero desapareció.

Este caso no es raro en cuanto hay más de un agente, porque los agentes leen mucho y escriben rápido. Es la razón por la que casi todas las herramientas aíslan: una máquina por agente, una rama por agente.

Lo que hace el resto del mundo: un worktree por agente

La respuesta habitual a este problema es el particionamiento: se le da a cada agente su propio worktree de git, una copia completa de los archivos con su propio índice, y se procura que los perímetros no se solapen. Es lo que hacen Windsurf, Conductor y OpenHands, y es lo que recomiendan la mayoría de las guías.

Funciona, y tiene exactamente un defecto: el particionamiento es una promesa, no una garantía. Nadie comprueba que los perímetros no se solapen, y cuando se solapan se descubre en la fusión, cuando los dos agentes han terminado y ya nadie recuerda el razonamiento.

La reserva, en tres tiempos

Antes de escribir, un agente anuncia las rutas que va a tocar. El tablero se las asigna si están libres, y se las niega si están ocupadas. Un único titular por archivo, en todo momento.

Durante el trabajo, un observador mira las escrituras reales en el disco y atribuye cada una a su autor. Una escritura en una ruta que tiene otro se fotografía antes de aterrizar: se conserva la versión anterior, así que nada se pierde aunque se salte la regla.

Al final, el agente devuelve sus rutas. El archivo vuelve a estar disponible para el siguiente, sin fusión, porque nunca existieron dos versiones vivas al mismo tiempo.

Lo que se ve en pantalla

Cada ventana muestra a su agente trabajando, y el tablero muestra quién tiene qué. Se ve que un agente espera, y por qué. Un agente atascado se ve antes de causar daño, y esa es la diferencia real con una cola invisible.

La gente también cuenta. Varias personas en el mismo canvas manejan sus propios agentes y ven los cursores de los demás, con un nombre en cada uno.

Cuándo no es la forma correcta

Si tus tareas son de verdad independientes y largas, el aislamiento por máquina sigue siendo razonable: nada que arbitrar, nada que esperar. Compartir gana cuando las tareas se tocan, lo que ocurre en cuanto se trabaja en la misma función. Las comparativas detallan la elección herramienta por herramienta.

Respuestas directas

¿Hay que usar git worktree para lanzar varios agentes?

Es la respuesta que dan la mayoría de las guías, y funciona: un worktree por agente, cada uno con su propio índice y sus archivos, así que ninguna colisión es posible. Tiene un coste, y es siempre el mismo: tantas copias como agentes, y una fusión por copia al final. Un único directorio con reserva de archivo elimina las dos cosas, al precio de un agente que a veces espera treinta segundos.

¿Por qué no dar una rama a cada agente?

Es la solución habitual y traslada el coste al final. Tres ramas producen tres fusiones, y los conflictos aparecen cuando los tres agentes han terminado, es decir, en el momento en que ya nadie recuerda el razonamiento. Un directorio compartido resuelve el conflicto en el momento en que ocurre.

¿Qué pasa si un agente ignora la reserva?

No tiene esa opción: la regla la aplica el servidor, no se le sugiere al modelo. Un observador vigila las escrituras y atribuye cada una a su autor, y una escritura en una ruta que tiene otro se fotografía antes de aterrizar, así que las dos versiones siguen existiendo.

¿Cuántos agentes a la vez?

Cinco ventanas de agente en el plan Pro, y más por encima. El límite práctico no es la máquina, es el número de frentes independientes que el proyecto contiene en un momento dado.