Claude Code Dynamic Workflows no significa “abrir muchos agentes porque sí”. Es una superficie donde Claude Code escribe un JavaScript workflow script y un runtime en segundo plano coordina varios subagents. Conviene usarla solo cuando el plan de orquestación debe convertirse en código que puedas leer, guardar y mejorar. Si una sesión normal de Claude Code, un subagent, una skill, un hook o una routine ya poseen el trabajo, empieza por esa superficie más pequeña.
Al 3 de junio de 2026, la documentación oficial de Anthropic describe Dynamic Workflows como research preview y exige Claude Code v2.1.154 o posterior. La misma documentación dice que los workflow runs cuentan para plan usage y rate limits, con límites actuales de hasta 16 concurrent agents y 1.000 total agents por ejecución. Por eso la primera decisión no es velocidad; es control.
| Trabajo delante de ti | Usa Dynamic Workflows cuando... | Usa una superficie menor cuando... | Primer movimiento seguro |
|---|---|---|---|
| Auditoría o migración grande | las partes pueden correr en paralelo y compararse | un archivo, paquete o reviewer basta | pide una porción pequeña y una barra de verificación |
| Investigación o validación repetible | el branching plan debe guardarse como script | solo necesitas reutilizar el método | mantenlo como skill hasta que el código importe |
| Implementación con muchas tools | subagents necesitan contextos separados | una regla determinista basta | usa hooks |
| Trabajo scheduled o unattended | el workflow es parte de un runtime mayor | cadence, retries y external state son el owner | usa routine o job externo |
| Exploración con ultracode | quieres que Claude evalúe si workflow aporta valor | una sesión simple termina el trabajo | empieza pequeño y observa /workflows |
Regla de parada: no empieces con una migración de todo el repo, una búsqueda amplia o un workflow con permisos altos. Pide una porción pequeña, aprueba solo las tools necesarias, mira /workflows para estado y uso, y decide detener, guardar, reanudar o escalar según evidencia.
Qué cambia cuando el plan pasa a ser script
El cambio central es dónde vive el plan. En una conversación normal, Claude Code mantiene el plan, los resultados de tools y las correcciones dentro del contexto de chat. En Dynamic Workflow, Claude escribe un JavaScript orchestration script y el runtime lo ejecuta en segundo plano. El script puede lanzar subagents, dividir ramas, recoger resultados intermedios y devolver una síntesis.
La estructura sirve cuando el valor nace de verificaciones independientes. Una security audit, una migración multi-paquete, una revisión de arquitectura o una verificación de claims pueden ganar calidad si varias perspectivas limpias trabajan por separado. El número de agentes no prueba nada por sí mismo. La prueba es que la división, la verificación y la síntesis mejoren el resultado.
La contrapartida es menos control conversacional. Un workflow no se detiene en cada paso para pedirte más contexto. Puede mostrar permission prompts, pero el run avanza en background. Los subagents leen, escriben y ejecutan comandos según las tools permitidas. Por eso el primer workflow debe ser pequeño, observable y fácil de detener.
| Pieza | Posee | Qué vigilar |
|---|---|---|
| Claude Code session | petición, aprobación, review final | si la orquestación era necesaria |
| Workflow script | ramas, llamadas a subagents, síntesis | si el plan es legible y reutilizable |
| Subagents | slices independientes | writes, commands, duplicación, checks omitidos |
| /workflows | gestión del run y usage visibility | stop, save, resume y presión de tokens |
Si el script solo pide a un agente editar un archivo, no es un problema de workflow. Si captura un harness repetible para migration, audit, validation o comparación, empieza a justificar la superficie.
Diferencia frente a subagents, skills, hooks y routines
Dynamic Workflows no sustituye otras superficies de Claude Code. La pregunta correcta es quién debe poseer el plan, el método, el runtime y el trigger.
| Superficie | Mejor owner | Úsala cuando | Por qué no workflow |
|---|---|---|---|
| Sesión normal | una conversación viva | un contexto resuelve y revisa | complejo no significa script |
| Subagent | worker especializado | necesitas un reviewer o investigator independiente | un worker basta |
| Skill | método reutilizable | importa recordar el proceso | no necesitas runtime con ramas |
| Hook | regla determinista | algo debe dispararse antes o después de un evento | una regla no necesita agentes |
| Routine | runtime unattended | tiempo, retry o trigger externo son el owner | workflow no es scheduler |
| Dynamic Workflow | JavaScript orchestration script | el plan debe ser código revisable | muchos agentes no garantizan calidad |
Estas salidas reducen riesgo. Método reusable: skill. Regla de ciclo de vida: hook. Trabajo que debe despertarse mañana: routine. Elección entre productos o agentes: otra guía. Dynamic Workflows gana cuando el plan como script es más claro que el prompt.
Dónde encajan ultracode, deep research y /workflows
Hay varios puntos de entrada. El más explícito es pedir a Claude un workflow y exigir primero plan, slices, allowed tools y verification bar. /deep-research encaja con research synthesis. /workflows es la superficie para observar y gestionar runs, no una promesa de mejor resultado.
ultracode es una session setting. La documentación de model configuration lo distingue de un effort level normal: usa very high effort y permite que Claude considere Dynamic Workflows en tareas sustantivas. No es un saved workflow, no es precio fijo y no autoriza convertir cualquier prompt en fan-out.
| Necesidad | Empieza con | Motivo |
|---|---|---|
| Run orquestado explícito | pedir workflow directamente | decisión visible |
| Research synthesis | /deep-research | forma natural de investigación |
| Explorar si hace falta orquestación | ultracode | Claude puede evaluar el patrón |
| Observar o detener run | /workflows | estado y usage visibles |
| Reusar un harness probado | saved workflow file | el plan se vuelve artifact |
Si estás depurando comportamiento antiguo, actualiza primero. Luego verifica /config y /workflows en el mismo entorno donde ejecutarás el trabajo.
Primer workflow seguro
Antes de empezar, aplica tres pruebas. El trabajo debe dividirse en slices independientes. La comparación o verificación de esos slices debe mejorar la calidad. El script de orquestación debe poder reutilizarse. Si una prueba falla, vuelve a sesión normal, subagent o skill.
Un buen prompt inicial es estrecho. No digas “migra todo el repo”. Di: toma solo el paquete auth y sus tests; identifica tres riesgos de migración; propone patches; verifica con el test command existente; no edites fuera del paquete; pide permiso antes de writes; informa usage y riesgos pendientes antes de escalar.
Ese prompt fija scope, tools, verification y condición de escalado. El resultado que buscas no es mucha actividad de agentes. Es una respuesta a la pregunta: ¿la orquestación como script produjo mejor evidencia que una sesión normal?
Durante el run, mantén /workflows visible. Mira si los tokens se gastan en trabajo independiente o en exploración duplicada. Mira si los permission prompts son más amplios de lo necesario. Mira si la síntesis explica qué verificó cada subagent. Si no, detén y reduce.
Coste, límites, permisos y controles de desactivación
Dynamic Workflows no es paralelismo gratis. La documentación actual dice que los runs cuentan para usage y rate limits, y que una misma tarea puede consumir más tokens que una conversación única. /workflows muestra usage de workflow; /usage ayuda a revisar el perfil general de Claude Code.
Al 3 de junio de 2026, los límites actuales son hasta 16 concurrent agents y hasta 1.000 agents por run. Son suficientemente potentes para un harness serio, y suficientemente altos para que un prompt flojo queme presupuesto rápido.
El control de permisos empieza antes del lanzamiento. Los subagents actúan según tools y approval path. En el primer run, limita target path, allowed commands y review checkpoint. En equipo, decide antes quién controla /config, disableWorkflows, CLAUDE_CODE_DISABLE_WORKFLOWS=1, managed settings o admin settings.
| Pregunta previa | Por qué importa | Evidencia |
|---|---|---|
| Qué versión corre | evitar comportamiento antiguo | local version check |
| Feature enabled | availability cambia | /config y docs del mismo día |
| Slice mínimo | evita run amplio | target path y verification bar |
| Tools permitidas | agents pueden escribir y ejecutar | approval mode y allowlist |
| Cómo mirar usage | tokens pueden crecer | /workflows, /usage |
| Quién desactiva | hace falta kill switch | settings, env, admin |
Si no puedes contestar esas preguntas, no ejecutes un workflow amplio.
Ejemplos que encajan y ejemplos que no
Los buenos candidatos comparten una cosa: varios contextos limpios mejoran la evidencia. Una large migration encaja si los paquetes pueden cambiarse y probarse por separado. Una security audit encaja si dependency risk, auth boundary, data exposure y test coverage se investigan en ramas independientes. Claim verification encaja si docs, code y runtime behavior se verifican por separado.
Los malos candidatos son más simples. Un single-file refactor no se vuelve workflow por ser importante. Un comportamiento determinista de pre-commit debe ser hook. Un método de prompt reusable debe ser skill. Un daily repo sweep se parece más a routine. Un debugging sencillo sigue siendo conversation hasta que aparezcan ramas reales.
También existe riesgo de equipo: usar workflow para esconder incertidumbre. Si no sabes qué debe probar cada subagent, la orquestación hará el trabajo menos auditable. Escribe primero la verification bar y decide después si necesitas agents.
Qué guardar tras un run exitoso
Un saved workflow debe parecer automation artifact, no transcript. Debe aclarar owner, inputs, allowed tools, stop rule, verification y reuse rule.
| Elemento | Debe incluir |
|---|---|
| Owner | repo area, team o release job |
| Intent | manual audit, migration slice, research harness |
| Inputs | paths, branch assumptions, test commands |
| Tool boundary | reads, writes, commands |
| Stop rule | cuándo detenerse |
| Verification | tests, comparisons, review evidence |
| Reuse rule | cuándo merece repetirse |
No guardes el workflow solo porque funcionó. Guárdalo cuando el script sea más fácil de leer, reutilizar y mejorar que un prompt normal.
Cómo introducirlo en equipo
En un equipo, la pregunta central no es cuántos agents puedes abrir. Es quién posee el boundary. Un workflow compartido necesita owner, allowed tools, stop rule, verification evidence y rollback path. Sin eso, el saved workflow es un experimento personal difícil de repetir con seguridad.
Guarda evidencia del primer run: prompt original, target paths, approved tools, workflow slices, usage visible en /workflows, findings de subagents, failed branches, test commands y unresolved risks. Si la síntesis no explica qué verificó cada subagent, no escales el scope.
| Elemento de rollout | Señal de paso | Si está débil |
|---|---|---|
| Owner | repo area o team definidos | no compartir aún |
| Permissions | writes y commands limitados | reducir scope |
| Usage | /workflows y /usage revisados | reducir fan-out |
| Verification | tests y comparación explícitos | reescribir prompt |
| Disable path | /config, settings, env o admin owner conocido | pausar rollout |
Dynamic Workflows no sustituye el proceso de review. Elige un job repetible, como migration slice, claim verification o audit harness. Demuestra valor con un run pequeño y guarda script, explicación y reuse rule juntos.
Cuando el workflow crea patch, revisa más que el diff final. Mira evidence de subagents, branches fallidos, exploración duplicada y tests. Si la síntesis no trae verificación independiente, la tarea era demasiado amplia o la verification bar era demasiado vaga.
Preguntas frecuentes
¿Dynamic Workflows es lo mismo que subagents?
No. Subagents son workers con contexto separado. Dynamic Workflow es la capa de orquestación que coordina muchos workers mediante un script.
¿Qué hace ultracode?
ultracode es una session setting. Combina very high effort con la posibilidad de usar Dynamic Workflows en tareas sustantivas. No es un saved workflow.
¿/deep-research es un workflow?
Es un entry point para comportamiento research-heavy. En migration o audit, define scope, tools y verification de forma explícita.
¿Dónde viven los saved workflows?
Los docs actuales mencionan .claude/workflows/ y ~/.claude/workflows/. Trátalos como artifacts revisables de automation.
¿Puedo reanudar después?
Los docs actuales vinculan resume a la misma Claude Code session. Antes de salir, revisa /workflows.
¿Cuánto cuesta?
No hay precio fijo seguro. Cuenta para usage y rate limits y puede consumir más tokens. Empieza pequeño y mira /workflows y /usage.
¿Cómo se desactiva?
Revisa /config, disableWorkflows, CLAUDE_CODE_DISABLE_WORKFLOWS=1, managed settings y admin settings. En equipo, asigna owner.
¿Reemplaza routines, hooks o skills?
No. workflows poseen script-owned orchestration. routines poseen unattended runtime. hooks poseen deterministic event rules. skills poseen reusable method.