Inicio / Varios agentes y verificación adversa
Workflows deterministas: esquemas, checkpoints, reanudación
Un workflow es un script que encadena llamadas de agente de forma determinista: las mismas etapas y el mismo esquema de salida en cada ejecución. Un esquema JSON impone campos con nombre de una etapa a otra, y cada etapa terminada escribe un checkpoint, de modo que un workflow interrumpido se reanuda sin rehacerlo todo.
Un workflow, en el sentido de este módulo, es un script que encadena varias llamadas de agente de forma determinista: la misma secuencia de etapas y el mismo esquema de salida en cada ejecución, a diferencia de una conversación donde el agente decide solo el orden de sus acciones.
El esquema que reemplaza a un informe en lenguaje libre
Cuando un agente debe transmitir su resultado a la etapa siguiente, un esquema JSON impone campos con nombre y tipos precisos, en lugar de un párrafo que el agente siguiente tendría que releer e interpretar. Dos agentes que intercambian mediante un esquema común no se malentienden sobre la forma, lo que traslada la vigilancia a donde de verdad importa, el contenido.
El checkpoint que evita rehacerlo todo
Cada etapa terminada escribe un checkpoint. En el momento de reanudar un workflow interrumpido, una etapa marcada como terminada devuelve directamente su resultado guardado sin relanzar al agente que lo produjo. Una etapa cuyo prompt ha cambiado desde la última ejecución se relanza, y toda etapa colocada después de ella en la secuencia también, incluso si su propio prompt no se ha movido. Antes de la versión 2.1.305, los agentes terminados podían también volver a ejecutarse al relanzar un script sin modificar; la reanudación los sirve ahora desde el diario de la ejecución.
etapa : rédaction_synthèse
estado : terminado
prompt idéntico a la última ejecución : sí
modelo puesto en el script para esta etapa : ninguno
El modelo que un agente relanzado hereda realmente
Desde la versión 2.1.251, el modelo que se aplica a un agente relanzado sigue un orden de prioridad de cuatro niveles: el parámetro puesto directamente en la llamada de ese agente, el campo modelo del propio subagente, una variable de entorno propia del subagente, y luego, como último recurso, el modelo de la sesión que ejecuta el script en el momento en que lo relanza. Antes de esta versión, el orden difería en un punto que afecta a los scripts antiguos: la variable de entorno pasaba primero y prevalecía sobre el parámetro de la llamada así como sobre el campo modelo del frontmatter, incluso sobre el valor model: inherit. Desde octubre, la variable CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL hace funcionar todos los agentes de un workflow con un solo modelo sin tocar los demás subagentes; la línea del registro de cambios no dice dónde se sitúa en este orden, y la página de workflows no menciona la variable: solo el registro de cambios la documenta. Cuando ninguno de los niveles prioritarios está rellenado, un agente escrito bajo un modelo dado en una fecha determinada cambia silenciosamente al modelo de la sesión que lo relanza meses después, sin que ningún mensaje en pantalla lo señale. Este punto se une a la elección de arquitectura planteada en fan-out, pipeline, barrera: un pipeline guardado sigue siendo un pipeline, y cada una de sus etapas conserva su propio riesgo de herencia silenciosa de modelo.
Reabrir un script antiguo y verificar qué modelo se aplicará a cada agente lleva unos minutos, comparando también la versión de la herramienta en que se escribió con la instalada hoy.
Cuándo detener una etapa que falla
En un bucle de etapas, «el mismo error dos veces» se juzga sobre el conjunto de criterios rechazados en un intento, no sobre un identificador aislado. Un conjunto distinto abre un intento más, el mismo conjunto cierra la etapa, y dos etapas fallidas seguidas detienen el bucle. Una etapa fallida no detiene el proyecto: su trabajo queda en el repositorio y se retoma en un pequeño proyecto nuevo. En cada reanudación, relee el plan y añade una precisión antes del intento siguiente, y haz que los veredictos los escriba un script que compruebe que las claves igualan los criterios.
Un script de workflow, de la escritura a la relanzada
Una persona abre en agosto un script de workflow escrito en enero, en una instalación de Claude Code que permaneció en la misma versión posterior a 2.1.251 durante todo ese intervalo, con una variable de entorno de modelo por subagente dejada en su valor vacío por defecto. El script encadena cuatro llamadas de agente, la primera con un campo modelo que lleva el valor sonnet y las tres siguientes con ese campo dejado vacío. Esta persona relanza el script desde una sesión cuyo modelo por defecto pasó a ser haiku entre enero y agosto.
Escribe en una frase lo que esta situación establece, y en una frase lo que no establece.
Lo que esto establece: Establece que el primer agente seguirá ejecutándose con el modelo sonnet en esta relanzada, ya que su campo modelo está rellenado explícitamente en el script y un campo explícito prevalece sobre el modelo por defecto de la sesión que relanza.
Lo que esto no establece: No establece qué modelo utilizarán los otros tres agentes en esta relanzada, ya que su campo modelo vacío hace que dependan de niveles de prioridad no descritos en esta situación, entre ellos el modelo de la sesión como último recurso.
Los tres calibrados falsos más frecuentes
- Demasiado amplio El script entero seguirá ejecutándose con el modelo sonnet en esta relanzada, ya que ese es el valor que lleva su primer agente.
- Demasiado estrecho Esta situación no permite afirmar nada sobre el modelo que se utilizará en la relanzada, ya que el modelo por defecto de la sesión cambió entre enero y agosto.
- Fuera de tema Esta situación muestra sobre todo que el modelo por defecto de una sesión evoluciona con el tiempo independientemente de los scripts que se ejecutan en ella, un hecho sobre el entorno de trabajo más que sobre el comportamiento del script relanzado.
- Una salida estructurada mediante un esquema JSON elimina la ambigüedad entre dos agentes que se leen mutuamente, una estructura impuesta reemplaza a un texto por interpretar.
- Un checkpoint registra el resultado de cada etapa terminada y la reanudación lo sirve desde el diario de la ejecución: solo se relanzan la etapa cuyo prompt cambió y las que la siguen.
- El modelo aplicado a un agente relanzado depende, desde la versión 2.1.251, de un orden de prioridad de cuatro niveles, el parámetro de la llamada, el campo modelo del subagente, una variable de entorno, y luego el modelo de la sesión como último recurso; antes de esa versión, la variable de entorno pasaba primero y prevalecía sobre todo lo demás.
- Un agente para el que ninguno de los tres primeros niveles está rellenado cambia silenciosamente, en el momento de la relanzada, al modelo de la sesión que ejecuta el script ese día.
- Retomar un script antiguo implica reauditar cada campo de modelo, y un bucle de etapas se detiene con el mismo conjunto de criterios rechazados dos veces o con dos etapas fallidas seguidas.
Abre el último script de workflow que hayas guardado, enumera cada llamada de agente que contiene, y anota junto a cada una si su campo modelo lleva un valor explícito o si permanece vacío antes de relanzarlo.
Estos puntos dependen de una interfaz o de una regla que puede haber cambiado desde la redacción. Verifícalos en tu propia pantalla antes de fiarte de ellos.
- Verifica si tu herramienta de orquestación define una variable de entorno de modelo por subagente en tu equipo, prevalece sobre el modelo de la sesión si está puesta, y verifica también si tu instalación es anterior o posterior a la versión 2.1.251, que invirtió el orden de prioridad entre esa variable y el parámetro de la llamada.
Cada afirmación datable de esta lección remite aquí al texto público que la respalda. Una fuente que no se abre no prueba nada.
- Anthropic, documentación de los workflows de Claude Code consultée le 2026-09-02
- Anthropic, documentación de los subagentes de Claude Code, orden de resolución del modelo consultée le 2026-09-02
- Claude Code, workflows, reanudación desde el diario de la ejecución consultée le 2026-10-24
- Registro de cambios de Claude Code, versiones 2.1.296 y 2.1.305, workflows consultée le 2026-10-24