Resumen de la publicación
Orquestar decenas de agentes de Claude Code en paralelo —en vez de uno solo trabajando en secuencia— cambia por completo cómo se planifica, se coordina y se controla la calidad de un proyecto de software o de investigación.
Lo cuento porque lo vengo aplicando yo mismo en el día a día del MUG, y porque entender estos patrones —fan-out, supervisor, agent teams— es la diferencia entre usar la IA como un asistente más rápido o como una fuerza de trabajo que escala.
Esta nota la escribo en medio de armar, en paralelo, la tanda de posts de esta quincena para el blog del MUG: catorce notas, cada una con su propia investigación, sus fuentes verificadas y su redacción. Si lo hubiera hecho con un solo agente, uno detrás del otro, probablemente todavía estaría terminando la tercera. En cambio disparé varias sesiones de Claude Code al mismo tiempo, cada una con una tarea acotada y sus propias fuentes, y volví después a revisar resultados. El tema de esta nota es, literalmente, el método que estoy usando para escribirla.
Un agente solo es un empleado brillante con anteojeras
Un agente de Claude Code, trabajando solo, es extraordinario para una tarea a la vez: entiende contexto, ejecuta código, corrige errores. El problema aparece cuando el trabajo real no es una tarea sino diez o cien tareas independientes entre sí. Ahí un solo agente empieza a acumular decisiones, se satura de contexto y termina yendo más lento que si hubiera dividido el problema.
Un análisis reciente de Towards Data Science sobre cómo orquestar cien agentes con Claude Code lo plantea así: el patrón que funciona es un agente orquestador que dispara múltiples sesiones headless de Claude Code (con el comando claude -p), cada una acotada a su propia subtarea, sin pisarse entre sí. No es que un agente se vuelva más inteligente por trabajar de a uno: es que ciertos problemas son embarazosamente paralelos, y forzarlos a una cola secuencial es directamente un desperdicio.
Fan-out, supervisor, swarm: no hay un solo modo de paralelizar
Lo que más me sorprendió investigando esto es que «correr varios agentes» no es una receta única. Hay varios patrones bien distintos, y elegir mal el patrón para el problema que tenés es donde más tiempo se pierde. Te nombro algunos de estos patrones:
- El fan-out (repartís el mismo tipo de tarea en n copias que corren en paralelo y después juntás resultados, como hice yo con las catorce notas).
- El pipeline (una cadena secuencial donde cada agente le pasa la posta al siguiente).
- El patrón supervisor (un agente jerárquico que delega y controla).
- El swarm o Agent Teams: en vez de que todo pase por un líder central, los agentes se mandan mensajes entre sí directamente mientras comparten una lista de tareas.
En Claude Code esto ya existe en tres capas: subagentes dentro de una misma sesión para research o verificación puntual, Agent Teams para compañeros que corren en paralelo en la misma máquina, y orquestadores externos cuando el trabajo cruza varios repositorios o un equipo entero.
Cuando escalás a decenas, el cuello de botella pasás a ser vos
Acá está el cambio que más noto en la práctica: con un agente, revisás el código o el texto que produjo. Con veinte agentes corriendo, no podés revisar veinte diffs línea por línea sin convertirte vos en el cuello de botella.
Lo que cambia es que la verificación tiene que moverse un escalón más arriba y, en parte, automatizarse: cada agente valida su propio trabajo antes de reportar, y el orquestador o una capa de tests corre pruebas end-to-end sobre entornos efímeros antes de aceptar el resultado, en vez de que un humano mire todo a mano. Esto tiene un costo real que conviene no subestimar: Steve Yegge, uno de los que más publicó sobre esto este año, cuenta que para mantener el ritmo de su propio orquestador multiagente necesitó correr tres cuentas Claude Max en simultáneo.
Escalar agentes en paralelo no es gratis ni en cómputo ni en atención: cambiás «revisar un PR» por «diseñar cómo se revisan cien PRs sin que se cuele un error». Y varias de estas herramientas de orquestación siguen siendo, en palabras de sus propios autores, «experimentales» —lo cual quiere decir que la validación exhaustiva no es opcional, es la mitad del trabajo.
Si te interesa meterte en serio con estos patrones —no solo usar Claude Code para chatear, sino diseñar flujos con agentes que se coordinan solos— es justo el tipo de cosa que trabajamos en el AI-First Builders Lab del MUG, un curso que su próxima edición arranca en Septiembre (no te quedes afuera).
¿Cuántos agentes tenés corriendo vos ahora mismo?
No creo que la respuesta correcta sea «todos deberíamos tener cien agentes trabajando a la vez». Para la mayoría de las tareas del día a día, un agente bien dirigido alcanza y sobra (si, lo estás leyendo bien: un agente alcanza). Pero cuando el problema es genuinamente paralelo —investigar catorce temas, refactorizar veinte módulos independientes, revisar seguridad, performance y tests al mismo tiempo— insistir con un solo agente secuencial es dejar plata y tiempo arriba de la mesa.
La pregunta que me queda dando vueltas, y que te tiro a vos: ¿ya probaste correr más de un agente a la vez en algo tuyo, o todavía te da un poco de vértigo soltar el control de esa manera? Contame en los comentarios cómo te fue.
Fuentes
- Towards Data Science — How to Orchestrate 100 Agents With Claude Code
- Shipyard — Multi-agent orchestration for Claude Code in 2026
- Digital Applied — Multi-Agent Orchestration: 5 Patterns That Work in 2026
