Home / Several agents and adversarial checking

Deterministic workflows: schemas, checkpoints, resumption

A workflow is a script that chains agent calls deterministically: the same steps and the same output schema on every run. A JSON schema imposes named fields from one step to the next, and each completed step writes a checkpoint, so an interrupted workflow resumes without redoing everything.

A workflow, in the sense used in this module, is a script that chains several agent calls deterministically: the same sequence of steps and the same output schema on every run, unlike a conversation where the agent decides on its own the order of its actions.

The schema that replaces a free-text report

When an agent has to pass its result on to the next step, a JSON schema imposes named fields and precise types, rather than a paragraph the next agent would have to read and interpret. Two agents exchanging through a shared schema do not misunderstand each other on shape, which moves the vigilance to where it actually matters, the content.

The checkpoint that avoids redoing everything

Every completed step writes a checkpoint. When resuming an interrupted workflow, a step marked complete returns its saved result directly without relaunching the agent that produced it. A step whose prompt has changed since the last run gets relaunched, and any step placed after it in the sequence is relaunched too, even if its own prompt has not moved. Before version 2.1.305, completed agents could also run again when an unedited script was relaunched; the resume now serves them from the run's journal.

étape : rédaction_synthèse
statut : terminé
prompt identique à la dernière exécution : oui
modèle posé dans le script pour cette étape : aucun

The model a relaunched agent actually inherits

Since version 2.1.251, the model applied to a relaunched agent follows a four tier priority order: the parameter set directly in that agent's call, the model field of the subagent itself, an environment variable specific to the subagent, then, as a last resort, the model of the session running the script at the moment it relaunches it. Before this version, the order differed on a point that changes everything for an old script: the environment variable came first and won out over both the call parameter and the frontmatter's model field, including over the value model: inherit. Since October, the CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL variable runs every agent of a workflow on a single model without touching other subagents; the changelog line does not say where it sits in this order, and the workflows page does not mention the variable: only the changelog documents it. When none of the priority tiers is set, an agent written under a given model on a given date silently switches to the model of the session relaunching it months later, with no on screen message flagging it. This point connects with the architecture choice laid out in fan-out, pipeline, barrier: a saved pipeline remains a pipeline, and each of its steps keeps its own risk of silent model inheritance.

Reopening a script written several months earlier and checking line by line which model will actually apply to each agent takes a few minutes, provided you also check the version of the orchestration tool at the time the script was written against the one installed today.

When to stop a failing step

In a loop of steps, "the same error twice" is judged on the whole set of criteria rejected in an attempt, not on one isolated identifier. A different set opens one more attempt, the same set closes the step, and two failed steps in a row stop the loop. A failed step does not stop the project: its work stays in the repository and is picked up in a small new project. At each resume, reread the plan and add a clarification before the next attempt, and have the verdicts written by a script that checks the keys equal the criteria.