Claude Code workflows: un script en lugar de un agente y lo que cuesta

Cada artículo de este sitio sale en cinco idiomas. Antes de publicarlo, cada idioma se revisa por separado: fidelidad de la traducción, frases que suenan a IA, caracteres ocultos. Son quince revisiones por artículo, y hasta ahora Claude Code las hacía una detrás de otra, acumulando todos los informes intermedios en el contexto de una sola sesión. Los Claude Code workflows resuelven justo esto: Claude escribe un script de JavaScript, el runtime lanza con él subagentes en segundo plano y a la conversación solo vuelve el resultado final.

Lo que sigue explica qué es este modo según la documentación de Claude Code, en qué se diferencia de los subagentes, las skills y los agent teams, cómo lanzarlo y dónde deja de compensar. Todo está comprobado con la documentación a 3 de noviembre de 2026; yo uso Claude Code 2.1.316. Los workflows están disponibles en todos los planes de pago y a través de la API de Anthropic, Amazon Bedrock, Google Cloud Agent Platform y Microsoft Foundry. En Pro hay que activarlos en /config, en la línea Dynamic workflows.

Claude Code workflows: el plan pasa al código#

Subagentes, skills y agent teams ya los lanzaba Claude Code antes. La diferencia está en quién lleva el plan. En las tres opciones anteriores el orquestador es el propio Claude: sobre la marcha decide a quién lanzar después, y cada resultado cae en su contexto. En un workflow, los bucles, las ramas y los datos intermedios viven en variables del script.

De aquí sale también la respuesta a una pregunta frecuente: en qué se diferencia un workflow de una skill. Una skill es un texto que Claude lee y ejecuta él mismo. El workflow lo ejecuta el runtime, y Claude solo ve la respuesta.

Lo importante aquí no es la escala. Como el orden del trabajo está escrito en código, se le puede meter un control de calidad: unos agentes buscan problemas, otros intentan refutarlos por su cuenta, y al informe solo llega lo que aguanta. O el plan se escribe desde tres ángulos y un cuarto agente compara las versiones.

Tres formas de lanzarlo#

El /deep-research integrado. Es la forma más rápida de ver el modo en acción. El comando reparte la búsqueda web en varias direcciones, contrasta entre sí las fuentes encontradas, vota cada afirmación y devuelve un informe con enlaces. Las afirmaciones que no pasan el contraste quedan fuera. Si una afirmación no se pudo comprobar por un límite o un error de la API, se marca como no verificada, no como refutada.

/deep-research What changed in the Node.js permission model between v20 and v22?

Pedirlo en el prompt. Basta la palabra ultracode al principio del prompt o una petición directa con tus palabras ("use a workflow"), y Claude escribirá un script para esa tarea en vez de trabajar paso a paso. La palabra resaltada se puede anular para el prompt actual: Option+W en macOS, Alt+W en Windows y Linux.

La palabra solo funciona en un prompt que ha tecleado una persona. Un prompt de claude -p, una tarea programada, un webhook o un comentario en un pull request no lanzan un workflow aunque lleven ultracode.

Activarlo para toda la sesión. Es la tercera forma y tiene apartado propio.

Ultracode en Claude Code: qué es y cuándo desactivarlo#

/effort ultracode es un ajuste de la sesión y no toca el nivel de esfuerzo. Con él, Claude decide por su cuenta qué tarea necesita un workflow, y una sola petición puede convertirse en tres ejecuciones seguidas: entender el código, hacer el cambio, comprobarlo. Arrancar con claude --effort ultracode fija además el nivel xhigh. Se desactiva con /effort ultracode off.

Con ultracode activado caen tres salvaguardas: el aviso Large workflow, el límite de subagentes simultáneos del Agent tool y, en modo auto, la confirmación de la primera ejecución. La documentación lo dice sin rodeos: con suscripción, una sesión así llega antes al límite diario o semanal. Para el trabajo de todos los días (un cambio, la revisión de un archivo, un correo) yo no lo activaría.

Cómo es el script#

El script suele escribirlo Claude, pero conviene saber leerlo: antes de lanzarlo, Claude Code muestra las fases y deja abrir el código (View raw script o Ctrl+G). Aquí va un borrador para mi revisión de idiomas. Lo armé a partir de la documentación y todavía no lo he probado con un artículo real:

export const meta = {
  name: 'article-locale-review',
  description: 'Review every locale of an article against the Russian source',
  phases: [{ title: 'Review' }, { title: 'Verify' }],
}
 
const FINDINGS = {
  type: 'object',
  required: ['findings'],
  properties: {
    findings: {
      type: 'array',
      items: {
        type: 'object',
        required: ['locale', 'quote', 'problem'],
        properties: {
          locale: { type: 'string' },
          quote: { type: 'string' },
          problem: { type: 'string' },
        },
      },
    },
  },
}
const VERDICT = {
  type: 'object',
  required: ['isReal', 'reason'],
  properties: { isReal: { type: 'boolean' }, reason: { type: 'string' } },
}
 
const LOCALES = ['en', 'es', 'ja', 'zh-CN']
 
phase('Review')
const reviews = await pipeline(LOCALES, locale =>
  agent(
    `Compare content/articles/ru/general/${args.slug}.mdx with ` +
      `content/articles/${locale}/general/${args.slug}.mdx. ` +
      `List omissions, additions and mistranslations. Do not edit files.`,
    { label: locale, schema: FINDINGS },
  ),
)
 
phase('Verify')
const findings = reviews.filter(Boolean).flatMap(r => r.findings)
const verdicts = await parallel(
  findings.map(f => () =>
    agent(`Try to refute this translation issue: ${JSON.stringify(f)}`, {
      label: `verify:${f.locale}`,
      schema: VERDICT,
    }).then(v => (v ? { ...f, ...v } : null)),
  ),
)
 
return verdicts.filter(v => v?.isReal)

agent() lanza un subagente; pipeline(), un agente por cada elemento de la lista; parallel(), un conjunto de tareas a la vez, y espera a que terminen todas. phase() agrupa los agentes en la ventana de progreso, y args es la entrada que se pasa al lanzar el comando guardado ("Run /article-locale-review on slug claude-code-workflows").

Fíjate en filter(Boolean). Un agente que se detuvo o que falló por un error irrecuperable de la API devuelve null, y pipeline() deja ese null en el array. Y schema obliga al subagente a devolver un JSON con la forma pedida: tras cinco intentos fallidos, la llamada falla con el último error de validación.

Una ejecución que salió bien se guarda como comando: /workflows, eliges la ejecución, s. El archivo irá a .claude/workflows/ del proyecto (lo ve cualquiera que clone el repositorio) o a ~/.claude/workflows/ (solo tú, pero en cualquier proyecto).

Límites que conviene conocer antes de la primera ejecución#

• No se puede intervenir a mitad de camino. El workflow solo se pausa por sí mismo para pedir permisos de un agente y para esperar a que se reinicie un límite. Si necesitas una aprobación entre etapas, lanza cada etapa por separado.
• El script no toca nada por sí mismo. Los archivos los leen y editan los agentes; el script solo los coordina. import() está prohibido, y Date.now(), Math.random() y new Date() sin argumentos lanzan un error: al relanzar, los agentes tienen que llamarse en el mismo orden. La hora se pasa por args.
• Topes. 16 agentes a la vez (CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS, de 1 a 256), 4 096 elementos en un solo parallel() o pipeline(), 1 000 agentes por ejecución.
• Repetir tras un fallo sale más caro de lo que parece. Al relanzar, los agentes terminados devuelven el resultado guardado. Pero si el script arrancó A, B, C y D y falló B, el relanzamiento solo sacará A de la caché, y B, C y D volverán a ejecutarse aunque C y D ya hubieran terminado.
• Un agente colgado se reinicia solo, hasta cinco veces. A las tareas largas se les puede dar más margen con stallMs en agent().
• Si chocas con el límite de la suscripción, la ejecución espera al reinicio y sigue sola, pero solo en una sesión interactiva, con autoContinueAtUsageLimit activado, si el reinicio llega dentro de las 24 horas y como mucho dos veces. En claude -p y en una sesión en segundo plano, el agente simplemente falla.

Si cerraste la sesión deteniendo las tareas, la ejecución se para con ella. Los resultados guardados se conservan: claude --resume y luego pides a Claude que relance el workflow.

Cuánto cuesta un workflow#

Una ejecución gasta bastantes más tokens que el mismo trabajo dentro de la conversación, y todo cuenta para los límites del plan. Claude Code marca la ejecución como Large workflow cuando hay más de 25 agentes o la previsión pasa de 1,5 millones de tokens. Es solo un aviso y no detiene nada.

Cuántos agentes planificará Claude lo orienta workflowSizeGuideline:

Por defecto es medium; en Pro, desde la versión 2.1.271, small. Se cambia con /config workflowSizeGuideline=small. Es una pauta para el modelo, y si en el prompt pides más de forma explícita, Claude hará caso al prompt.

Hay también un ahorro fácil de olvidar. Los agentes de una misma ejecución con el mismo modelo, nivel de esfuerzo, herramientas, esquema y carpeta de trabajo leen una caché de prompt común, así que Claude Code los retiene hasta cinco segundos, a la espera de que empiece la respuesta del primero. La caché dura cinco minutos, y subagentPromptCacheTtl: "1h" la alarga a una hora con un precio de escritura más alto.

Un consejo de la documentación con el que estoy de acuerdo: prueba el workflow primero con un trozo pequeño. Una carpeta en lugar del repositorio, una pregunta acotada en lugar de una amplia. /workflows muestra el consumo de tokens de cada agente, y la ejecución se puede parar en cualquier momento sin perder lo ya hecho.

Dónde compensa un workflow#

La señal es sencilla: la misma operación sobre muchos objetos más una verificación cruzada del resultado. Auditar todos los route handlers en busca de autorización que falta, migrar quinientos archivos en copias aisladas, cazar tests flaky por rondas hasta que una ronda nueva ya no encuentra nada. Si en un trabajo así varios agentes escriben en archivos comunes, necesitan la misma disciplina que las personas: aislamiento o reservas en lugar de sobrescrituras silenciosas.

En mi caso son dos procedimientos. La revisión de los cinco idiomas de cada artículo, la de arriba. Y la revisión de parches de seguridad en todos mis sitios: un agente por repositorio comprueba versiones y Dockerfile, un segundo agente vuelve a verificar esos hallazgos. Los dos se repiten y los dos se comen hoy el contexto de la sesión.

Una carta de presentación, el cambio de una función o un solo artículo no piden un workflow. Una pasada sale más barata y el resultado no es peor. Para el conocimiento del proyecto que necesita cada agente, el workflow tampoco cambia nada: hay que guardarlo en algún sitio, por ejemplo en una wiki conectada a Claude Code por MCP. Y si los agentes son muchos y escriben código en serio, el cuello de botella puede ser el propio git, como en el caso de Anthropic, que lo sustituyó por un sistema propio.

Yo empezaría así: /config workflowSizeGuideline=small, después /deep-research con una pregunta a la que de todos modos ibas a dedicar media hora en Google, y luego mirar en /workflows cuánto costó.