Dos agentes editando el mismo código a la vez no son dos veces un agente. Son un modo de fallo nuevo. El agente A refactoriza una interfaz. El agente B, en su propia sesión, construye una feature que llama a esa interfaz, sobre la forma vieja, porque nadie le dijo que la forma cambió. Los dos son localmente correctos. Los dos pasan sus propias comprobaciones. Juntos producen un código que no compila o, peor, uno que compila y está mal en silencio.
Eso es contaminación, y es lo que convierte «voy a correr más agentes» de una victoria de throughput en un lío. Que los agentes en paralelo ayuden de verdad se reduce a tres disciplinas: aíslalos, dales un contrato compartido y reconcílialos a la vuelta. Sáltate una y las colisiones se comen la ganancia.
Por qué más agentes multiplican el problema en vez de repartir el trabajo
Un solo agente tiene una propiedad agradable: ve todo lo que hizo. Su contexto es su propia historia. En el momento en que tienes varios agentes trabajando a la vez, esa propiedad desaparece. Cada uno ve su ventana y nada de las demás. No pueden observar los cambios de los otros, porque «el otro agente editó este fichero» no es un hecho que exista dentro del contexto de ninguno.
Así que la coordinación que un solo agente hacía implícitamente, recordando sus propias ediciones, ahora tiene que hacerla explícitamente algo fuera de los agentes. Si ese algo eres tú, leyendo cada diff y sosteniendo cada colisión en la cabeza, te has convertido en el bus de integración, y eres el cuello de botella que el paralelismo debía quitar. Esta es la textura concreta de ser el runtime a mano: no escribes código, eres el canal entre agentes que no se ven.
Disciplina uno: aislamiento
La primera regla es que los agentes no deben compartir una superficie de trabajo mientras trabajan. Dos agentes escribiendo a los mismos ficheros en el mismo directorio se corromperán el estado constantemente, no porque sean malos sino porque ninguno ve los cambios sin commitear del otro.
Para eso están los worktrees. Cada agente tiene su propio checkout, su propia rama, su propio directorio de trabajo. Puede editar libremente sin pisar a nadie, porque no hay nadie más en su copia. Las colisiones no pasan durante el trabajo. Se aplazan al merge, donde se pueden manejar a propósito en vez de en carrera. Correr sesiones paralelas en worktrees es la base mecánica de todo el trabajo multiagente, y lo demás lo da por hecho.
El aislamiento te compra seguridad durante la ejecución. Lo que no te compra es coherencia. Dos agentes aislados pueden construir cada uno algo sensato que contradice al otro, porque el aislamiento impide que se corrompan los ficheros, no que tomen decisiones incompatibles. De eso van las dos disciplinas siguientes.
Disciplina dos: un contrato compartido
Los agentes aislados aún necesitan estar de acuerdo en lo que los cruza: las interfaces, los invariantes, la forma de la cosa que los dos tocan. Si cada agente inventa su propia versión de la frontera compartida, el aislamiento solo significa que chocan limpio en el merge en vez de sucio durante el trabajo. Mejor, pero no resuelto.
El arreglo es que las partes compartidas viven en un contrato que ambos agentes leen, fuera de la sesión de cualquiera. La interfaz contra la que ambos construyen está especificada, no improvisada. Los invariantes que ambos deben respetar están en el fichero de reglas que ambos cargan. Cuando el agente A necesita cambiar la interfaz compartida, eso es un cambio al contrato, no una decisión privada dentro de la ventana de A que B descubrirá rompiéndose.
Aquí convergen la orquestación multiagente y la memoria. El contrato compartido es justo la memoria que persiste fuera del chat: decisiones e invariantes que no posee ningún agente, que todos leen. Sin esa capa externa y compartida, «orquestación» es solo varios agentes adivinando una frontera que ninguno puede ver, y las adivinanzas no van a cuadrar.
Y deberías esperar divergencia incluso con contrato, porque un contrato restringe sin eliminar las opciones. Diseñar para esa expectativa, en vez de suponer que el contrato pone a todos de acuerdo, es justo el sentido de aceptar que los agentes derivan. El aislamiento y los contratos reducen las colisiones. No las llevan a cero. Por eso la tercera disciplina no es opcional.
Disciplina tres: reconciliación
El aislamiento aplaza las colisiones al merge. Un contrato compartido encoge cuántas hay. La reconciliación es donde de verdad resuelves las que quedan, y es el paso que la gente se salta porque no luce y porque es donde vive el trabajo real del desarrollo multiagente.
Reconciliar no es git merge y rezar. Es el acto deliberado de volver a juntar las ramas paralelas y comprobar que la combinación es coherente, no solo que cada rama estaba bien sola. Este es justo el problema de lo localmente correcto, globalmente incoherente, y el trabajo multiagente es su forma más aguda: has fabricado, a propósito, varios cambios localmente correctos, y nada garantiza que sumen un sistema globalmente correcto.
Un paso de reconciliación de verdad hace las preguntas que ningún agente solo podría: ¿la feature del agente B sigue funcionando contra la interfaz refactorizada del agente A? ¿Alguien rompió un invariante que solo importaba a través de la frontera? ¿El resultado integrado pasa los criterios que las piezas pasaban por separado? La reconciliación es verificación aplicada a las costuras, y las costuras son justo donde fallan los agentes en paralelo, porque son el único sitio donde ningún agente individual estaba mirando. Esa comprobación combinada es un bucle de verificación apuntado a la integración, no al diff individual: una puerta que el resultado integrado tiene que pasar, no una afirmación que cada agente se auto-declara.
La forma de esto
Junto todo, orquestar varios agentes sin contaminación es un bucle, no un lanzamiento. Aíslas cada agente en su worktree para que no se corrompan durante el trabajo. Les das un contrato compartido para que lo que los cruza esté especificado, no improvisado. Reconcilias en el merge, comprobando la combinación y no solo las partes. Y lo vuelves a hacer.
Lo que hay que interiorizar es que la parte difícil del trabajo multiagente no es lanzar los agentes. Lanzar es fácil, por eso todo el mundo empieza ahí y se choca con el muro. La parte difícil es la frontera entre ellos: el contrato compartido que leen y la reconciliación que pilla lo que cruzó la frontera mal. Acierta con aislamiento, contratos y reconciliación y más agentes significa de verdad más hecho. Falla en ellos y más agentes solo significa más colisiones que arbitrar a mano.
Cuando dos de tus agentes chocan, ¿te enteras en el merge o tres commits después? Cuéntame en el foro.
Preguntas frecuentes
¿Cómo corres varios agentes de código a la vez sin conflictos?
Tres disciplinas. Aísla cada agente en su propio worktree para que no se corrompan los ficheros mientras trabajan. Dales un contrato compartido —las interfaces y los invariantes que ambos leen fuera de cualquier sesión— para que lo que los cruza esté especificado, no improvisado. Después reconcilia en el merge, comprobando que la combinación es coherente, no solo cada rama por separado. Sáltate una y las colisiones se comen la ganancia.
¿Pueden dos agentes de IA editar el mismo código con seguridad?
No sobre la misma superficie de trabajo. Dos agentes escribiendo a los mismos ficheros se corrompen el estado constantemente, porque ninguno ve los cambios sin commitear del otro. El arreglo es el aislamiento: cada agente tiene su propio checkout, rama y directorio con git worktrees. Las colisiones se aplazan al merge, donde se manejan a propósito en vez de en carrera. El aislamiento compra seguridad durante la ejecución, aunque no coherencia; eso necesita un contrato compartido y reconciliación.
¿Qué es la contaminación entre agentes en paralelo?
La contaminación es cuando dos cambios localmente correctos se combinan en un todo roto. El agente A refactoriza una interfaz; el agente B, en su sesión, construye una feature sobre la forma vieja porque nada le dijo que cambió. Los dos pasan sus propias comprobaciones, y juntos producen código que no compila o, peor, compila y está mal en silencio. Pasa porque el contexto de ningún agente contiene el hecho de que otro editó algo.
¿Cómo integras el trabajo de varios agentes de IA?
Con reconciliación, no con git merge y rezar. La reconciliación junta a propósito las ramas paralelas y comprueba la combinación: ¿la feature de B sigue funcionando contra la interfaz refactorizada de A?, ¿alguien rompió un invariante que solo importaba a través de la frontera?, ¿el resultado integrado pasa los criterios que las piezas pasaban solas? Es verificación apuntada a las costuras, que es justo donde fallan los agentes en paralelo, porque son donde ningún agente individual estaba mirando.