La primera vez que corres dos agentes a la vez parece un truco. Dos tareas avanzando mientras te tomas un café. Así que corres tres, luego cinco, luego ocho, y en algún punto de ahí la sensación cambia. Ya no escribes código y tampoco descansas de verdad. Cambias de contexto entre paneles, sostienes ocho estados parciales en la cabeza, decides a quién le toca tu atención. Te has dado un segundo trabajo, y el trabajo es scheduler.
Yo corro el trabajo así a diario construyendo PaellaDoc, y el paralelismo es de verdad como sacas throughput de los agentes. Pero el throughput no es gratis, y el coste no son tokens. Es un tipo concreto de atención humana que se vuelve más cara cuantas más sesiones añades, y entender ese coste es la diferencia entre un paralelismo que escala y uno que solo te deja frito.
La parte mecánica: worktrees
El truco que lo habilita son los git worktrees. Un worktree es un segundo directorio de trabajo respaldado por el mismo repositorio, en su propia rama. En vez de un checkout por el que se pelean todos los agentes, cada agente tiene su propio directorio y su propia rama, y todos pueden editar a toda velocidad sin tocar los ficheros del otro.
Esto importa porque el montaje ingenuo, varios agentes en un directorio, se corrompe solo enseguida. Los agentes no ven los cambios sin commitear del otro, así que dos escribiendo al mismo árbol se sobrescriben y se lían constantemente. Los worktrees dan a cada agente aislamiento, que es la precondición de todo lo demás. Las colisiones no desaparecen, se mueven al merge, donde puedes manejarlas a propósito. Este es el suelo mecánico bajo todo el trabajo multiagente: sin aislamiento no hay nada que orquestar, solo un amontonamiento.
El montaje en sí no es complicado. Un worktree por tarea, una rama por worktree, un agente por rama. La complejidad no está en la mecánica de git. Está en el humano de pie en medio de ocho de ellos.
La parte de la que nadie te avisa: eres el scheduler
Cuando los worktrees están corriendo, un papel nuevo te cae encima lo quisieras o no. Cada uno de estos trabajos es ahora tuyo, todos a la vez:
- Prioridad. ¿Qué sesión se lleva tu atención ahora? Terminan y se atascan en momentos distintos, y la que te necesita no siempre es la que estás mirando.
- Contexto. Cada sesión sostiene un trozo distinto del producto en la cabeza, y tú también, porque cuando la sesión cuatro pregunta algo, necesitas recargar qué estaba haciendo siquiera la cuatro.
- Recuperación. Un run se muere en un momento incómodo y se queda ahí, sin hacer nada, esperando. Si no lo notas, es un panel muerto quemando nada más que tu throughput.
- Routing. Distintas tareas quieren distintos motores, la tarea de arquitectura y el refactor mecánico no deberían correr en el mismo modelo al mismo coste, y elegir es cosa tuya. Ese es el argumento entero de enrutar cada tarea al motor correcto, que se vuelve agudo justo cuando corres muchas a la vez.
- Integración. Todas vuelven como ramas que tienen que integrarse en una sola cosa coherente, y el merge es donde aflora la deriva entre ellas.
Ninguna de estas es difícil en aislamiento. El coste es que son concurrentes y van por interrupción. No las haces en orden. Te arrastra el panel que te reclama, a mitad de un pensamiento en otro, y cada cambio paga el impuesto de recargar qué estabas haciendo ahí. Esa recarga es la misma pérdida de contexto que golpea a los agentes, solo que te golpea a ti, en tiempo real, de ocho formas a la vez.
Por qué el coste es superlineal
Aquí están las cuentas incómodas. Dos sesiones no son el doble de carga que una. Son más, porque encima de las dos sesiones está el cambio entre ellas, y el coste del cambio crece más rápido que el número de sesiones.
Con una sesión nunca te interrumpen, no hay a qué cambiar. Con dos, cambias de vez en cuando. Con ocho, casi siempre estás a mitad de cambio, y los estados chocan en tu memoria de trabajo: vas a contestar a la sesión tres y no recuerdas de inmediato si lo que miras es de la tres o de la seis. Las sesiones escalan lineal. La coordinación entre ellas, lo que de verdad corre en ti, no. Por eso cinco agentes pueden sentirse productivos y ocho pueden sentirse como ahogarse, aunque solo sean tres más.
Esta es la versión concreta y sentida del argumento entero del runtime. Cuando dicen que un buen desarrollador puede correr agentes bien a mano, tienen razón, y esta es justo la parte del «a mano». Eres el scheduler, la memoria, el bucle de recuperación y el router, todo en tiempo real, y la razón de que funcione es que estás absorbiendo un coste de coordinación superlineal con atención humana. Funciona justo hasta que deja de funcionar, y dónde deja es distinto para cada uno pero siempre deja. El nombre que le da el manifiesto es que tú eres el runtime, y correr ocho sesiones es la forma más física de sentirlo.
Qué ayuda de verdad
Esto no se arregla corriendo menos sesiones, eso solo te limita el throughput a lo que un humano pueda cuidar. Se arregla moviendo trozos del trabajo del scheduler fuera de ti y hacia el sistema.
La decisión de routing la puede tomar un router en vez de tú eligiendo modelo por panel. La recuperación puede ser un retry gobernado que nota un run muerto y lo reinicia, en vez de tú pillando el panel atascado, que es una disciplina entera en cuanto tratas la recuperación como un flujo de primera. El contexto puede vivir en memoria duradera que cada sesión carga por su cuenta, para que cambiar a la sesión cuatro no requiera que tú recuerdes en persona qué hacía la cuatro. La integración puede ser un paso de reconciliación de verdad en vez de tú integrando ocho ramas a ojo y rezando. Es la misma razón por la que los agentes necesitan un runtime y no solo un modelo más grande: la inteligencia por sesión no toca el coste de coordinación entre sesiones, y el coste de coordinación es lo que de verdad te está limitando. La versión larga la escribí en los agentes necesitan un runtime, no un modelo más grande.
Cada uno de esos movimientos quita un trabajo del scheduler, que eres tú. Haz suficientes y el coste superlineal deja de trepar con cada sesión añadida, porque la coordinación pasa en el sistema en vez de en tu cabeza. Ese es el juego entero: no más agentes vigilados por un humano más heroico, sino los mismos agentes coordinados por algo que no es tu atención. Corre ocho sesiones si quieres el throughput. Solo no seas la octava cosa que lo sostiene todo.
¿Cuántas sesiones en paralelo aguantas antes de dejar de construir y empezar a arbitrar? Cuéntame en el foro.
Preguntas frecuentes
¿Cuántas sesiones de agente puedo llevar en paralelo?
No hay un número fijo; el límite es donde el coste de coordinación adelanta a tu atención, y es distinto para cada uno. Lo predecible es la forma: cinco sesiones pueden sentirse productivas y ocho como ahogarse, aunque solo sean tres más. El coste es superlineal porque el cambio entre sesiones crece más rápido que el número de sesiones. Extiendes el techo moviendo los trabajos del scheduler al sistema, no siendo más heroico.
¿Cómo corro varias sesiones de código con IA a la vez?
Usa git worktrees: un worktree por tarea, una rama por worktree, un agente por rama. Un worktree es un segundo directorio de trabajo respaldado por el mismo repositorio, en su propia rama, así cada agente edita a toda velocidad sin tocar los ficheros del otro. El montaje ingenuo —varios agentes en un directorio— se corrompe solo enseguida, porque los agentes no ven los cambios sin commitear del otro. Los worktrees dan el aislamiento del que depende todo lo demás.
¿Por qué correr muchos agentes en paralelo agobia?
Porque te conviertes en el scheduler, y cinco trabajos concurrentes te caen a la vez: prioridad, contexto, recuperación, routing e integración. Van por interrupción, así que te arrastra el panel que te reclama a mitad de un pensamiento en otro, y cada cambio paga el coste de recargar qué estabas haciendo. Esa recarga es pérdida de contexto golpeándote en tiempo real, de ocho formas a la vez. Las sesiones escalan lineal; la coordinación que corre en ti, no.
¿Qué son los git worktrees y por qué los necesitan los agentes?
Un worktree es un segundo directorio de trabajo del mismo repositorio en su propia rama. Los agentes los necesitan porque el aislamiento es la precondición del trabajo en paralelo: sin él, dos agentes escribiendo al mismo árbol se sobrescriben y se lían constantemente. Los worktrees no hacen desaparecer las colisiones, las mueven al merge, donde puedes manejarlas a propósito. Este es el suelo mecánico bajo toda la orquestación multiagente.