Los dynamic workflows de Claude Code explicados: ultracode, /workflows y el límite de 1000 agentes (2026)

- Cada número y umbral de versión de aquí lo contrasté yo misma con la documentación oficial (code.claude.com/docs/en/workflows) al momento de escribir (08/2026); esta función cambia casi con cada release, así que verifica la documentación en vivo antes de depender de ella.

Este es contenido avanzado - escrito para quien ya usa Claude Code con subagents y skills; no vuelve a enseñar lo básico. Si no tienes claro qué es un subagent, lee primero cómo funcionan los subagents de Claude Code o qué es una skill de Claude Code.

Qué es realmente un dynamic workflow

Un dynamic workflow no es una función de interfaz aparte - es un mecanismo: una vez activado, Claude escribe un script en JavaScript que describe el plan (qué se ejecuta primero, qué corre en paralelo, qué espera el resultado de un paso anterior). Ese script reparte el trabajo a muchos subagents en segundo plano, y Claude conserva solo el resultado final en el contexto de la sesión principal - no todo el rastro de razonamiento de cada subagent.

Compáralo con un turno normal, incluso uno en el que le pediste a Claude que delegara en un subagent: la sesión principal todavía tiene que sostener la salida de cada subagent en su propio contexto para decidir qué sigue, y si cierras la sesión a mitad de la tarea, ese razonamiento en curso se pierde. Un dynamic workflow saca la decisión de "qué sigue" por completo de la conversación y la mete en el script, que es lo que hace posible una ejecución de 1000 agentes sin reventar la ventana de contexto de la sesión principal.

Un ejemplo ilustrativo para hacer el mecanismo concreto (no son datos medidos de verdad, solo la lógica): le pides a Claude que audite todo el directorio src/ en busca de problemas de seguridad. El script que escribe podría verse como "entregar cada subdirectorio a su propio agente para escanear, cualquier agente que encuentre un problema lo reporta con evidencia, un agente final agrega todo en una tabla" - toda esa lógica de ramificación, espera y agregación vive en el archivo de script, no en la memoria de trabajo de Claude como ocurre cuando orquestas subagents a mano.

Requisito: Claude Code v2.1.154 o más nuevo (umbral de versión - verifica tu propia versión antes de depender de esto), disponible en todos los planes de pago más API/Bedrock/Vertex/Microsoft Foundry. En Pro no viene activado por defecto - lo activas manualmente en la fila "Dynamic workflows" de /config. No lo confundas con el auto-mode (activado por defecto desde 2026-08-14) - esa es una función completamente distinta, sin relación con dynamic workflows, aunque ambas aparecieron más o menos en la misma tanda de releases.

Requiere Claude Code v2.1.154+ (verifica primero tu versión real); funciona en todos los planes de pago más API/Bedrock/Vertex/Microsoft Foundry; los usuarios de Pro deben activarlo manualmente en /config, no viene encendido por defecto.

Dos formas de activarlo

Hay dos formas de invocar un dynamic workflow, según quieras usarlo para una sola tarea o para toda la sesión.

Un detalle histórico que la mayoría de los textos se salta: la palabra clave escrita solía ser workflow antes de la v2.1.160, y luego se renombró a ultracode en la v2.1.160. Pero la formulación en lenguaje natural ("usa un workflow para esto") siempre funcionó en ambas épocas - nunca dependió de la palabra clave exacta. Si ves documentación o publicaciones antiguas que dicen "escribe workflow", esa es la nomenclatura anterior a la v2.1.160.

Una trampa que vale la pena recordar: la palabra clave solo se dispara desde entrada humana, escrita - no a través de la flag -p, no a través de entrada no humana del Agent SDK, no a través de tareas programadas, y no a través de relays de webhook/comentario de PR. Si estás automatizando Claude Code por cualquiera de esos canales, escribir "ultracode" en algún lado no va a activar un dynamic workflow por sí solo.

Qué método elegir depende de lo que estés haciendo. Para una tarea grande dentro de una sesión por lo demás normal (digamos, "ultracode: audita todo el manejo de errores en el directorio api/"), escribir la palabra clave solo en ese turno basta - el resto de la sesión corre como siempre, sin sobrecarga extra de razonamiento en lo pequeño. Si ya sabes que toda la sesión va a ser trabajo pesado (un día reservado para una migración o una auditoría), /effort ultracode te ahorra reescribir la palabra clave en cada turno - pero el trade-off es que cada tarea sustancial de esa sesión se empuja a razonamiento xhigh, incluidas cosas que nunca pensaste ejecutar como workflow.

Prueba primero el workflow integrado /deep-research

La forma más rápida de ver un dynamic workflow corriendo de verdad, con cero configuración, es el workflow integrado /deep-research:

1. Ejecuta /deep-research <your question>.
2. Aprueba el plan que Claude propone antes de que corra.
3. Sigue el progreso con /workflows.
4. Lee el informe final - viene con citas.

La parte interesante: las afirmaciones que no pasan la verificación cruzada se filtran fuera, y las que no se pueden verificar se marcan como no verificadas en lugar de refutarse de plano - un modo de fallo distinto a que Claude invente una única respuesta con toda la seguridad. Ten en cuenta que este workflow necesita la herramienta WebSearch activada. Si todavía tienes dudas sobre qué es un subagent, lee cómo funcionan los subagents de Claude Code antes de la siguiente sección.

Por qué vale la pena probarlo primero: es el único workflow para el que no tienes que escribir el prompt de orquestación - Anthropic ya empaquetó la lógica de "buscar fuentes → verificación cruzada → filtrar afirmaciones débiles → escribir un informe con citas" dentro. Ejecútalo una vez sobre una pregunta técnica concreta (digamos, "compara cómo Next.js 16 y Remix manejan el streaming SSR") y verás la forma general que sigue todo dynamic workflow: un plan aprobado por adelantado, varios agentes corriendo en paralelo que no tienes que vigilar paso a paso, y un resultado final que ya viene filtrado en lugar de una única respuesta sin verificar.

Observa y gestiona una ejecución - /workflows

Escribe /workflows para abrir la vista de seguimiento en vivo: fase actual, cuántos agentes están corriendo, total de tokens gastados, tiempo transcurrido - todo en una sola pantalla que se actualiza en tiempo real.

Esta vista importa más de lo que parece: es la única forma de saber cuánto está "comiendo" una ejecución antes de que se coma tu límite semanal - más sobre el costo abajo. Piénsalo como dejar correr un pipeline de CI sin un dashboard: puede terminar bien solo, pero vale la pena vigilar una ejecución grande las primeras veces, al menos hasta que le agarres el pulso a cuánto token quema en el tipo de tarea que sueles pasarle.

Los números que hay que saber antes de activar esto

Esta es la sección que vale la pena leer con atención antes de apuntar esta función a cualquier cosa grande, ya que ninguno de estos números es obvio desde la interfaz hasta que vas a buscarlo.

Topes rígidos: hasta 1000 agentes por ejecución (evita que un bucle desbocado corra para siempre), y hasta 16 agentes simultáneos (menos en máquinas/contenedores limitados de CPU). La cifra de 1000 es un techo para toda la ejecución, no una meta - la mayoría de las tareas reales terminan con muchos menos agentes; existe justamente para impedir que un script mal delimitado genere agentes indefinidamente si una condición de parada nunca se dispara.

Las guías de tamaño son orientativas, no un límite rígido (requiere v2.1.202+ - umbral de versión, verifícalo antes de depender de él). Puedes fijar una si quieres forzar a Claude a mantener el número de agentes por debajo del predeterminado.

El aviso de workflow grande (Large): salta cuando una ejecución supera 25 agentes O 1,5 millones de tokens proyectados (el 25 cambia si fijaste tu propia guía de tamaño). Es solo orientativo - no pausa la ejecución. Las sesiones que ya corren /effort ultracode no muestran este aviso, ya que optar por ese modo significa que aceptaste ejecuciones grandes desde el inicio.

Juntando los números: una auditoría acotada a un directorio con unas pocas docenas de archivos, con la guía de tamaño predeterminada medium (por debajo de 15 agentes), casi nunca va a rozar el umbral de aviso de 25 agentes. Pero una migración que abarca más de 200 archivos en un repositorio entero puede superar con facilidad tanto los 25 agentes como el 1,5 millón de tokens - a ese punto te conviene fijar la guía de tamaño en large a propósito (o aceptar el aviso) en lugar de que te sorprenda a mitad de la ejecución. Dicho de otro modo, los números 1000/16/25 no están ahí para espantarte de la función - están ahí para que puedas estimar "qué tan grande es lo que estoy a punto de entregarle" antes de pulsar enter.

Workflows vs subagents vs skills vs agent teams - quién sostiene el plan

Esta es la pregunta más importante si ya usas subagents y skills: estos cuatro se diferencian en quién sostiene el plan de orquestación, no en cuál es "más fuerte".

En términos simples: subagents y skills dejan que Claude decida cada paso por sí mismo, limitado por la ventana de contexto de esa sesión. Agent teams (experimental - ve agent teams para colaboración entre múltiples sesiones) es un agente líder que supervisa agentes pares a través de una lista de tareas compartida, apto para sesiones colaborativas largas. Un dynamic workflow es distinto porque el plan vive en un script, no en el contexto de Claude - así el contexto principal solo tiene que sostener la respuesta final, no todo el proceso.

Elección rápida: delegación de rutina → subagents/skills. Una sesión larga y colaborativa que necesita supervisión continua → agent teams. Una tarea más grande que una ventana de contexto, o que necesita verificación cruzada adversarial (varios agentes verificando los resultados de los demás) → un dynamic workflow. ¿Quieres definir tu propio subagent reutilizable? Ve la guía de subagents; ¿necesitas antes lo básico de skills? Ve qué es una skill de Claude Code.

La confusión más fácil entre estos cuatro: subagents y skills ambos dejan que el Claude de la sesión principal tome la decisión - solo se diferencian en que una skill es un paquete de instrucciones cargado por el contexto, mientras que un subagent es una "persona" aparte que se invoca para hacer un trabajo y devolver los resultados. Ambos viven y mueren con la ventana de contexto de esa sesión: interrumpe la sesión a mitad y el progreso desaparece. Agent teams y dynamic workflows ambos escapan de ese límite, pero de formas distintas - agent teams escapan dejando que varias sesiones colaboren a través de una lista de tareas compartida que sobrevive al contexto de cualquier agente individual; dynamic workflows escapan sacando el plan por completo del contexto y convirtiéndolo en un objeto que puedes guardar, versionar en git y volver a ejecutar idéntico en cualquier momento - que es exactamente por lo que encaja mejor con el trabajo grande y repetible que con una conversación exploratoria.

Guarda un workflow que te gustó como un comando reutilizable

¿Te gustó una ejecución? Guárdala para no tener que hacer que Claude reescriba el script desde cero la próxima vez:

1. Abre /workflows, selecciona la ejecución que quieres conservar.
2. Pulsa s para guardarla.
3. Elige dónde: .claude/workflows/ (compartido, en el ámbito del proyecto) o ~/.claude/workflows/ (personal).
4. El workflow guardado se convierte en un comando /<name>, y puede recibir entrada a través de un parámetro args.

Si trabajas en equipo, un workflow también puede distribuirse dentro de un plugin (un directorio workflows/), llamado con un /plugin-name:workflow-name con namespace - práctico para compartir un script de orquestación con todo el equipo en vez de copiar y pegar comandos.

Lo bueno de guardar un workflow como archivo: como vive como un archivo de texto plano dentro de .claude/workflows/, lo confirmas en git como cualquier otra cosa del repositorio. Un compañero que haga pull de la rama recibe el mismo workflow automáticamente - Claude no tiene que "reaprender" el enfoque de auditoría o migración que ya ajustaste. Esta es también la diferencia más clara respecto a subagents y skills: un subagent que te gusta usar no se convierte automáticamente en algo que un compañero pueda invocar idéntico - un dynamic workflow guardado sí.

La realidad del costo en tokens

Voy a ser directa: la documentación oficial no da ninguna cifra fija en dólares para dynamic workflows, y no voy a inventar una solo para que esta sección se sienta completa. Circula una historia - algo como "un plan Max de $200/mes quemó el 20% de un límite semanal en un día" - la verifiqué yo misma, y se remonta a una entrada de blog que sintetiza un reporte de redes sociales, no a una fuente primaria ni verificable de forma independiente, así que no voy a repetir ese número aquí.

Lo que la documentación sí dice con claridad: los dos topes rígidos (1000 agentes / 16 simultáneos) existen justamente para acotar el costo desbocado. Cada subagent usa el modelo de la sesión principal, a menos que el script o la variable CLAUDE_CODE_SUBAGENT_MODEL lo redirija a otro lado.

Consejo práctico y respaldado por la documentación:

• Prueba primero en una porción pequeña (un directorio, no el repositorio entero) antes de una ejecución completa.
• Observa los totales de tokens por agente en vivo en /workflows mientras la ejecución está en marcha.
• Baja la guía de tamaño a small si quieres forzar un número de agentes menor que el predeterminado.

Por qué no invento una estimación propia: el costo real depende de demasiadas variables a la vez - cuánto corre cada subtarea, para qué modelo está configurada la sesión, cuántos agentes decide generar el propio script por ramificación - así que cualquier cifra "promedio" única engañaría más de lo que ayudaría. Un enfoque mucho más seguro es medir tu propia carga: corre una pasada pequeña, lee el conteo de tokens en /workflows, y escala de forma aproximadamente lineal hasta el tamaño que de verdad planeas ejecutar - en vez de confiar en un número que alguien pescó de las redes sociales.

¿AgentKit te da esto? (la respuesta honesta)

Una pregunta que vale la pena hacer si ya usas AgentKit: ¿AgentKit tiene su propia cosa de "workflow", y es lo mismo que esto? Respuesta directa: no. Dynamic Workflows es un motor nativo de Claude Code - exactamente el mecanismo de reparto de agentes por script de JavaScript que describe este artículo. AgentKit no trae ese motor, y no tiene un equivalente del lado de ak.

Yo misma revisé docs.agentkit.best/en/beta/reference/cli directamente (08/2026): la palabra "workflow" en el sitio de AgentKit es texto de marketing genérico para su paquete de skills, y el comando ak orchestrate es una función completamente distinta - un grafo de trabajos para herramientas de CLI externas, solo para macOS, sin relación con los dynamic workflows de Claude Code.

Entonces, ¿qué te da AgentKit en realidad? Un conjunto curado y licenciado de skills y personas de subagent (que se llaman a través de /ak:cook y comandos parecidos) al que puedes apuntar un dynamic workflow - ya sea que escribas el script tú misma o dejes que Claude lo escriba - usados como tareas de agente individuales, igual que cualquier otro subagent. En corto: compra AgentKit por la capa lista de skill/persona; usa Dynamic Workflows (gratis, nativo) por la capa de orquestación a escala. Se apilan, no compiten. Lee la reseña completa de AgentKit para más.

Un ejemplo ilustrativo de cómo encajan las dos capas (no es un resultado medido, solo un patrón de uso): un dynamic workflow auditando seguridad en cinco microservicios podría entregar cada servicio a un agente que corre la skill ak-security de AgentKit, y luego tener un agente final agregando los hallazgos de los cinco. El script de orquestación (qué corre en paralelo, qué espera a qué) pertenece a Dynamic Workflows; el conocimiento de dominio dentro de cada agente pertenece a la skill que compraste. Quita AgentKit y el workflow sigue corriendo - cada agente simplemente recurre al conocimiento general de Claude en lugar de una skill hecha a medida para ese trabajo.

¿Deberías activar esto hoy?

No hay una respuesta universal aquí, lo cual, honestamente, es una conclusión más útil que un sí/no tajante - la decisión correcta depende de qué tan grande y qué tan repetible es de verdad tu próxima tarea, no de si la función es nueva y emocionante. Veredicto corto: prueba la palabra clave ultracode en una tarea real y acotada primero (una auditoría de un solo directorio, no una migración del repositorio entero), antes de decidir configurar /effort ultracode para toda la sesión. Buen encaje para: migraciones grandes, auditorías en toda la base de código, investigación que necesita verificación cruzada entre fuentes. Sáltatelo para: pequeñas ediciones de rutina, o si estás en un plan Pro sensible al costo sin margen.

Una lista rápida antes de pulsar enter: (1) ¿la tarea es de verdad lo bastante grande como para dividirla en ramas independientes, o en realidad es una cadena secuencial que harías más rápido a mano?; (2) ¿de verdad vas a mantener /workflows abierto para observarla, o piensas alejarte?; (3) si esta ejecución falla a mitad de camino, ¿te quedas tranquila con los tokens ya gastados? Si las tres responden "sí", adelante, actívalo; si la pregunta uno es "no", un subagent simple suele seguir siendo más rápido y más barato.

FAQ

¿Qué es ultracode en Claude Code?

Ultracode es la palabra clave (y ajuste de effort) que activa un dynamic workflow - Claude escribiendo un script en JS que reparte una tarea entre hasta 1000 subagents en segundo plano. Escribir "ultracode" o formularlo de forma natural, como "usa un workflow para esto", ambos lo activan.

¿Cuántos agentes puede ejecutar un dynamic workflow?

Hasta 1000 agentes por ejecución, con hasta 16 corriendo a la vez (menos en máquinas/contenedores limitados de CPU). Son topes rígidos, no recomendaciones.

¿Qué dispara el aviso de workflow grande (Large)?

Una ejecución que supera 25 agentes o 1,5 millones de tokens proyectados (el 25 cambia según tu propia guía de tamaño). Es solo orientativo y no pausa la ejecución.

¿Un dynamic workflow es lo mismo que agent teams?

No. Agent teams es un agente líder que supervisa agentes pares a través de una lista de tareas compartida, apto para sesiones colaborativas largas (una función experimental). El plan de un dynamic workflow vive en un script escrito de antemano en lugar del contexto de Claude, y se puede guardar y volver a ejecutar idéntico - agent teams por lo general no se puede reproducir de la misma forma dos veces.

¿Necesito un plan de pago?

Sí. Funciona en todos los planes de pago más API/Bedrock/Vertex/Microsoft Foundry. Los usuarios de Pro deben activarlo manualmente en la fila "Dynamic workflows" de /config; no viene encendido por defecto.

¿AgentKit incluye los dynamic workflows de Claude Code?

No. Dynamic Workflows es un motor nativo y gratuito de Claude Code. AgentKit es un conjunto aparte y de pago de skills y personas de subagent que puedes usar como tareas de agente individuales dentro de un dynamic workflow - los dos se complementan, no son lo mismo.

Conclusión

Dynamic workflows es una función para usuarias avanzadas: topes reales (1000 agentes/16 simultáneos), un aviso orientativo en 25 agentes/1,5 millones de tokens, y se combina con - en lugar de reemplazar - la capa de skills de AgentKit. Pruébalo en algo pequeño antes de activarlo para toda una sesión, y mantén /workflows abierto para que siempre sepas cuánto estás gastando. Los umbrales de versión se mueven rápido, así que trata cada límite de este artículo como un punto de partida, no como dogma - vuelve a revisar la documentación en vivo el día en que de verdad actives esto para algo que importa.