Cómo repartir trabajo entre agentes en paralelo sin que se pisen
Paralelizar agentes de IA solo ahorra tiempo si las tareas son independientes. Cómo repartir el trabajo por archivos y contratos, y cómo integrar en orden.
Esta página trata de una pregunta concreta: cómo partir el trabajo para que dos agentes no se pisen. Las herramientas que lo hacen posible se explican aparte: el aislamiento de carpetas en git worktrees para agentes, el agente que reparte y junta en orquestador-trabajador, las formas de organizar varias llamadas en patrones multi-agente y los agentes que siguen solos mientras haces otra cosa en agentes en segundo plano.
¿Cuándo tiene sentido paralelizar?
La prueba es simple: ¿puedes escribir los encargos de modo que dos agentes no necesiten el resultado del otro para empezar? Si la respuesta es sí, hay paralelismo real. Si uno necesita la decisión del otro, son pasos en fila, y lanzarlos a la vez solo produce trabajo que hay que tirar.
Anthropic lo dice sobre su sistema de investigación: la mayoría de las tareas de código tienen menos partes realmente paralelizables que una investigación, y los dominios donde todos los agentes necesitan el mismo contexto, o donde hay muchas dependencias entre ellos, no encajan bien hoy con sistemas multi-agente. La documentación de agent teams de Claude Code llega a la misma conclusión: para tareas secuenciales, ediciones del mismo archivo o trabajo con muchas dependencias, es más eficaz una sola sesión o subagentes.
Suelen funcionar bien en paralelo:
- Investigación: leer varias fuentes o revisar varios módulos sin modificarlos.
- Módulos separados: un agente ajusta el formulario de registro y otro la página de precios.
- Revisión y verificación: un agente corre las pruebas mientras otro revisa accesibilidad sobre la misma versión.
Suelen salir mal: refactorizar una pieza compartida, cambiar esquemas de datos, o editar el mismo archivo de rutas o configuración desde varios frentes.
¿Cómo se reparte el trabajo sin pisarse?
Antes de lanzar agentes, dibuja un mapa de propiedad. Tiene tres capas:
- Por archivo o módulo. Cada agente tiene una lista de carpetas que puede modificar. Lo que queda fuera de su lista lo lee, pero no lo escribe. La documentación de agent teams de Claude Code lo resume así: dos agentes editando el mismo archivo se sobrescriben, así que cada uno debe poseer un conjunto distinto de archivos.
- Por contrato. Si dos agentes deben coincidir en algo (el nombre de un campo, la forma de la respuesta de un endpoint), escribe ese contrato primero y entrégaselo a ambos. Augment Code pide que cada tarea declare sus límites de archivos e interfaces y sus puntos de integración.
- Por archivos calientes. Augment llama así a las tablas de rutas, los archivos de configuración y los registros de componentes, porque muchas funciones interactúan con ellos. Su recomendación es una regla de un solo escritor: solo un agente (o una persona) cambia esos archivos.
El tamaño de la tarea también cuenta. La documentación de agent teams las prefiere como unidades autocontenidas que entregan algo claro, como una función, un archivo de pruebas o una revisión. Demasiado pequeñas, y la coordinación cuesta más que el beneficio; demasiado grandes, y el agente trabaja mucho tiempo sin que nadie lo revise.
¿Qué debe llevar cada encargo?
Anthropic cuenta que, sin descripciones detalladas, sus agentes duplicaban trabajo, dejaban huecos o no encontraban lo necesario. Para código, un encargo útil lleva cinco cosas:
| Elemento | Qué responde |
|---|---|
| Objetivo | Qué debe quedar hecho, en una frase |
| Archivos propios | Qué carpetas o archivos puede modificar |
| Archivos prohibidos | Qué puede leer pero no escribir (rutas, configuración) |
| Contrato | Nombres, formatos o endpoints que debe respetar |
| Criterio de éxito | Qué prueba o comprobación demuestra que terminó |
Si no puedes llenar esa tabla en cinco líneas, la tarea todavía no está lista para paralelizarse. El mismo patrón de delegación, visto desde el agente que reparte, está en orquestador-trabajador.
¿Cómo se aísla cada agente?
El aislamiento técnico más usado son los git worktrees: una carpeta y una rama por agente, con historial compartido. Evitan que dos agentes sobrescriban el mismo archivo en disco. Claude Code, por ejemplo, los crea con claude --worktree <nombre>, y la documentación aclara que no todos los modos de trabajo en paralelo los usan: los agent teams no aíslan a sus miembros en worktrees, por eso ahí manda el reparto por archivos.
Aislar carpetas no evita los conflictos de integración: si dos ramas tocan la misma línea, Git lo marca al fusionar. Tampoco aísla todo. Augment advierte que las bases de datos locales, Docker y las cachés siguen compartidos a menos que los separes de forma explícita, y que ejecutar commit, fetch o pull a la vez desde varios worktrees puede corromper metadatos compartidos, por lo que conviene serializar las operaciones de git.
¿Cómo se integra el resultado?
Integra una rama a la vez, y actualiza las demás contra la rama principal cada vez. Augment lo propone para reducir sorpresas de conflictos al final de la secuencia:
- Revisa el diff de la primera rama y corre sus pruebas.
- Fusiónala en la rama principal.
- Actualiza las demás ramas contra la nueva base.
- Repite con la siguiente.
Empieza por la rama más corta o la que más cosas desbloquea. Y no confundas “sin conflictos” con “funciona”: Git detecta conflictos de texto, no de significado. Augment pone como ejemplo un manejo de zonas horarias que funciona en UTC pero falla en los cambios de horario de verano, un error que pasa los chequeos automáticos y aparece en producción. Por eso los tests corren en cada integración y una persona revisa lo que las pruebas no ven.
¿Cuántos agentes lanzar a la vez?
Pocos. Augment habla de 2 a 4 agentes de código en paralelo, y la documentación de agent teams (una función experimental, desactivada por defecto) sugiere empezar con 3 a 5 compañeros y avisa de que más agentes traen más coordinación, más posibilidad de conflictos y más tokens. Para quien supervisa, la carga cambia: en vez de revisar un cambio grande, revisas varios pequeños y sigues varios avances. Una lista con el estado de cada agente, los archivos que toca y la rama donde vive ayuda más que tres conversaciones mezcladas en un chat. La parte de coordinar quién hace qué está en orquestación de agentes y la delegación dentro de una sola sesión, en subagentes.
Ejemplo
Ejemplo ilustrativo: un equipo quiere lanzar una exportación a CSV y, a la vez, mejorar el texto de error de un formulario. El agente A posee src/export/ y escribe la función con sus pruebas. El agente B posee src/forms/ y ajusta los mensajes. Ninguno toca src/routes.ts, que es archivo caliente con un solo escritor: una persona lo cambia al final, cuando la exportación ya existe. Antes de empezar, el equipo escribió el contrato: la exportación recibe una lista de filas y devuelve texto CSV. Se integra primero la rama de B, que es más corta; se actualiza la de A contra la nueva base, se corren las pruebas y recién entonces se fusiona.
Errores comunes
- Paralelizar tareas que dependen entre sí y pasar después horas integrando.
- Dejar que dos agentes editen el mismo archivo de rutas o de configuración.
- Acumular todas las ramas y fusionarlas juntas al final de la jornada en vez de integrar una a una.
- Suponer que “sin conflictos” significa “funciona”, sin pruebas en cada integración.
- Olvidar los recursos compartidos: la misma base de datos local o el mismo puerto de desarrollo.
- Lanzar más agentes de los que puedes revisar.
Fuentes
- How to Build a Multi-Agent AI System for Code Development (Augment Code, publicado en marzo de 2026)
- Run parallel sessions with worktrees (documentación de Claude Code)
- Run agents in parallel (documentación de Claude Code)
- Orchestrate teams of Claude Code sessions (documentación de Claude Code)
- How we built our multi-agent research system (Anthropic Engineering)