Home / Several agents and adversarial checking

Deterministic workflows: schemas, checkpoints, resumption

A workflow is a script that orchestrates subagents deterministically, with output structured by a JSON schema and a checkpoint after every step, but the model applied to a relaunched agent follows a four tier priority order, and when the first three tiers are left empty, that agent falls back, as a last resort, on the model of the session running it, not the one that wrote the script.

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 official Claude Code workflows documentation shows an example that passes a schema object directly to the function calling an agent, which removes any room for interpretation about the shape of the expected result.

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.

é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

This last field, no model set in the script for this step, is the easiest point to miss when rereading a script written several months earlier.

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. 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. Skipping this produces a result rendered by a model nobody chose for that specific step, with no alert warning of the change.