Flujos de trabajo dinámicos en Claude Code: guía 2026

Los flujos de trabajo dinámicos en Claude Code suponen un cambio en la forma de abordar tareas de ingeniería que hasta ahora exigían semanas de planificación. Presentados en mayo de 2026 en fase de research preview, permiten que Claude escriba un script de orquestación capaz de coordinar desde decenas hasta cientos de subagentes trabajando en paralelo, todo dentro de una misma sesión y comprobando su propio trabajo antes de entregarte un único resultado coordinado.

La promesa es directa: trabajo que normalmente planificarías por trimestres puede resolverse en días, sin que tú tengas que coser a mano cada paso.

¿Qué son los flujos de trabajo dinámicos?

Un flujo de trabajo dinámico es, en esencia, un script en JavaScript que orquesta subagentes a gran escala. Lo que lo distingue de otros enfoques es quién sostiene el plan. Con subagentes o skills, es Claude quien decide turno a turno qué ejecutar a continuación, y cada resultado ocupa su ventana de contexto. En un flujo de trabajo, el plan vive dentro del código: el bucle, las ramificaciones y los resultados intermedios se guardan en variables del propio script, de modo que el contexto de Claude solo conserva la respuesta final.

Esa diferencia habilita un patrón de calidad repetible. El script puede hacer que varios agentes independientes revisen de forma crítica los hallazgos de los demás antes de reportarlos, o que tracen un plan desde distintos ángulos para contrastarlos entre sí. El resultado es más fiable que el de una sola pasada.

Cómo funcionan por dentro

Cuando arranca uno de estos flujos, Claude planifica de forma dinámica a partir de tu petición, divide la tarea en subtareas y reparte el trabajo entre subagentes que se ejecutan en paralelo. Cada resultado se comprueba antes de integrarse: unos agentes atacan el problema desde ángulos independientes y otros intentan refutar lo que han encontrado, y la ejecución sigue iterando hasta que las respuestas convergen.

El runtime ejecuta el script en un entorno aislado, separado de tu conversación. Como la coordinación ocurre fuera del chat, el plan se mantiene en rumbo por grande que sea la tarea. Además, el progreso se guarda a medida que avanza: si una ejecución se interrumpe, puede retomarse donde se quedó dentro de la misma sesión, en lugar de empezar de cero.

Cuándo conviene usar un flujo de trabajo

No toda tarea necesita esta artillería. La regla práctica es recurrir a un flujo de trabajo cuando el trabajo necesita más agentes de los que una sola conversación puede coordinar, o cuando quieres dejar la orquestación escrita como un script que puedes leer y reejecutar.

Enfoque	Quién decide qué se ejecuta	Dónde viven los resultados	Escala
Subagentes	Claude, turno a turno	Contexto de Claude	Pocas tareas por turno
Skills	Claude, según el prompt	Contexto de Claude	Igual que subagentes
Flujos de trabajo	El script	Variables del script	Decenas a cientos de agentes

Casos de uso reales

Los equipos que han tenido acceso anticipado los están usando sobre todo en tres frentes:

• Auditorías a escala de repositorio: cazas de bugs, auditorías de seguridad y optimización guiada por profiler, con verificación independiente de cada hallazgo para que el informe muestre problemas reales.
• Grandes migraciones y modernizaciones: cambios de framework, deprecaciones de API y portados de lenguaje que abarcan miles de archivos de principio a fin.
• Trabajo crítico que exige doble comprobación: cuando el coste de un error es alto, el flujo da a Claude varios intentos independientes y agentes adversarios que tratan de romper el resultado antes de que llegue a tus manos.

El ejemplo más llamativo es la reescritura de Bun. Jarred Sumner portó este runtime de Zig a Rust con flujos de trabajo dinámicos: un 99,8 % de la suite de tests pasando, unas 750.000 líneas de Rust y once días desde el primer commit hasta el merge. Un flujo mapeó el lifetime de Rust adecuado para cada campo de cada struct; otro escribió cada archivo .rs como un portado de comportamiento idéntico a su equivalente .zig, con cientos de agentes en paralelo y dos revisores por archivo; un bucle de corrección dejó limpias la compilación y las pruebas; y un flujo nocturno eliminó copias de datos innecesarias y abrió una pull request por cada caso para revisión final.

Cómo empezar a usarlos

Hay dos caminos para lanzar un flujo de trabajo:

1. Pedirlo en el prompt: basta con incluir la palabra “workflow” en tu instrucción y Claude escribe el script en lugar de resolver la tarea turno a turno.
2. Activar ultracode: con /effort ultracode combinas el esfuerzo de razonamiento xhigh con la orquestación automática, y Claude decide por sí mismo cuándo una tarea merece un flujo de trabajo.

También puedes ejecutar el flujo incluido /deep-research, que reparte búsquedas web, contrasta fuentes y devuelve un informe citado. Y si una ejecución hace justo lo que querías, puedes guardar su script como comando reutilizable en tu proyecto o en tu carpeta personal.

Coste, límites y disponibilidad

Conviene tener presente que estos flujos consumen bastantes más tokens que una sesión normal de Claude Code, así que la recomendación es empezar con una tarea acotada. El runtime limita la ejecución a un máximo de 16 agentes concurrentes (menos en máquinas con pocos núcleos) y 1.000 agentes por ejecución, no admite entrada del usuario a mitad del proceso y no accede directamente al sistema de archivos: son los agentes quienes leen, escriben y ejecutan comandos.

Los flujos de trabajo dinámicos están disponibles en la CLI, la app de escritorio y la extensión de VS Code. La primera vez que se dispara uno, Claude Code muestra qué va a ejecutar y pide confirmación, y los administradores de una organización pueden desactivarlos desde los ajustes gestionados.

Conclusión

Los flujos de trabajo dinámicos llevan la orquestación de subagentes a un terreno nuevo: tareas largas, paralelas y verificadas que antes habrían ocupado semanas. Para quien trabaja con bases de código grandes o heredadas, son la diferencia entre acompañar a un agente paso a paso y delegar un proyecto completo con control sobre el plan.