Workflows dinámicos: el ejército de subagentes de Claude Code (sin tronar tu plan)

Normalmente, cuando le pides algo a Claude, un solo agente lo hace de principio a fin. Con esta función nueva de Claude Code, Claude escribe sobre la marcha un plan de orquestación y arma un ejército de subagentes que trabajan todos al mismo tiempo, cada uno en una parte distinta de tu proyecto. Al final se juntan en una sola respuesta. Suena increíble, y la verdad lo es.

Por dentro pasa esto, en una sola sesión:

1. 01

   Planea

   Con tu prompt, Claude descompone la tarea enorme en muchos pedazos que se pueden atacar en paralelo.

2. 02

   Lanza el ejército

   Abre decenas o cientos de subagentes al mismo tiempo, cada uno en su pedazo, dentro de una sola sesión.

3. 03

   Verifica y refuta

   Otros agentes intentan tumbar lo que encontraron los primeros. El trabajo se repite hasta que las respuestas convergen.

4. 04

   Te entrega una sola cosa

   Solo cuando todo cuadra, junta el resultado en una respuesta. El progreso se va guardando: si se corta, retoma donde iba.

Piénsalo como pasar de un solo trabajador a un equipo entero, coordinado por un jefe que revisa todo antes de entregártelo. Es la diferencia entre disparar un subagente suelto y armar un equipo completo —sin que tú tengas que orquestarlo a mano—.

Aquí está el detalle que casi nadie te dice: cada subagente que Claude lanza vuelve a leer tu proyecto desde cero. No comparten lo que ya leyó el otro. Así que si Claude decide mandar 40 agentes, literalmente son 40 lecturas completas de tu proyecto. En unos minutos puedes tronar tu plan por completo —se han ido cuentas enteras con un solo prompt mal acotado—.

La conclusión no es «no lo uses». Es úsalo bien: con un prompt que le diga dónde está todo (para que los agentes no exploren a ciegas), pidiéndole un entregable claro, y con modelos normales en lugar de los caros. Eso es justo lo que viene en las 3 reglas.

Cada regla, lista para pegar en tu prompt:

Antes de armar el workflow, usa este mapa en vez de
explorar el proyecto entero:
- Lo relevante vive en: <carpetas/archivos exactos>
- Ignora por completo: <lo que no aplica>
La meta es que cada subagente vaya directo a su pedazo, no que todos busquen en
todos lados.

El resultado tiene que ser UN entregable concreto:
<un archivo REPORTE.md / una investigación con fuentes / una lista de cambios
propuestos>. Defínelo así de claro para que los agentes converjan en una sola
salida y no me devuelvan 40 respuestas sueltas.

Para este workflow, corre los subagentes con Sonnet,
no con Opus. Son muchas tareas en paralelo y los modelos caros multiplican el
gasto por cada agente. Reserva Opus para el cierre o la síntesis final, si acaso.

Y las 3 juntas, en una sola plantilla que puedes adaptar:

Quiero un workflow dinámico para <tu tarea grande>
(auditar, migrar, reorganizar o revisar). Antes de lanzar agentes, lee esto
para que NO exploren todo el proyecto desde cero:

# Dónde está todo (mapa del proyecto)
- App / interfaz: src/app y src/components
- Lógica compartida: src/lib
- NO toques: node_modules, .next, public, archivos generados

# Qué quiero que hagas
<describe la tarea concreta: encontrar bugs, código muerto, migrar de X a Y...>

# Qué quiero de resultado (entregable)
Un solo archivo REPORTE.md con una tabla: archivo · hallazgo · severidad · sugerencia.
No cambies código todavía; primero quiero ver el reporte.

# Modelo
Usa Sonnet para los subagentes, no Opus. Es un barrido grande y quiero que me
dure el plan.

# Empieza acotado
Corre primero SOLO sobre src/lib para que yo mida el consumo. Si va bien,
seguimos con el resto.

La regla mental es simple: vale la pena cuando el trabajo se parte en muchas piezas distintas que se harían al mismo tiempo, y en vez de irlas haciendo Claude por Claude, dejas que arme el equipo y lo resuelva completo. Si no, es como matar una mosca a bazucazos.

Hay dos formas de prender un workflow dinámico:

La primera vez pide confirmación: antes de soltar el ejército, Claude te avisa que esto consume bastante más de lo normal. Buen momento para arrancar con una tarea acotada y medir el gasto antes de soltar todo.

El ejemplo que prueba para qué sirve de verdad: el equipo de Bun (un runtime de JavaScript) usó workflows dinámicos para reescribir parte de su código de Zig a Rust. Un agente mapeó cómo se relacionaban las piezas y, a partir de ahí, cientos de agentes trabajaron en paralelo con dos revisores sobre cada archivo.

Y no es un caso aislado: Klarna lo usó para detectar código muerto y oportunidades de limpieza que el análisis estático tradicional no veía. El resumen del equipo de CyberAgent lo dice bien: estos workflows «llenan el hueco entre disparar un subagente y armar un equipo de agentes completo». Eso es exactamente la clase de trabajo donde vale la pena soltar el ejército.