Dynamic workflows: when a fleet of agents earns its keep, and when it just burns money

In June I wrote a short piece about one word changing: the trigger word for dynamic workflows in Claude Code moved from “workflow” to “ultracode”, because an ordinary word was quietly launching a fleet of agents. That piece was about the switch. What sat underneath it I had not looked into.

Anthropic has now published a cookbook for exactly that, a notebook in the claude-cookbooks repo that runs a dynamic workflow end to end from the Python Agent SDK. It is the first material that goes past “this exists” and shows what a run costs, what the scripts look like, and where the thing breaks. I read it alongside the documentation and pulled out the rule of thumb I intend to use.

What it is, in one paragraph

Normally Claude is the orchestrator. You ask for something, Claude decides turn by turn what comes next, and every intermediate result lands in the same context window. In a dynamic workflow, Claude instead writes a JavaScript script describing the whole arrangement: which agents start, in what order, and what happens to their answers. That script goes to the Workflow tool and a separate runtime executes it in the background. Every agent it spawns is a full Claude Code agent with a clean context: it sees only the prompt the script hands it.

So the difference is not smarter agents. It is who holds the plan. With subagents that plan lives in Claude’s head. With a workflow it lives in code.

The cookbook’s example is a fact-check. A draft investor update makes ten claims that have to be traced back to four source files. The script does it in four phases: one agent pulls out the ten claims, then one verifier per claim reading the sources in parallel, then a skeptic that tries to knock down every confirmation, then one agent compiling a report. The data is fictional, with errors planted in it.

The upside

The plan is enforced by code. This is the core and everything else follows from it. “Double-check your findings” is an instruction, and instructions get dropped under context pressure. A skeptic phase that runs after the verifiers because the control flow says so does not get dropped.

Every item gets the same treatment. An agent working through ten claims in one context is skimming by claim seven. Ten agents holding one claim each are not. The cookbook points at claim 6, where the press article says “one of the fastest-growing” and the draft has turned it into “the fastest-growing”. That difference slips past a hurried reader and not past a verifier with nothing else to do.

Claude’s context stays clean. Every verdict and quoted source line lives in script variables. Only the final report comes back to your session. That is the reverse of subagents, where each result lands in the lead agent’s context window.

The logic between steps is free. Filtering, deduplicating, counting, looping until a check passes: that is ordinary JavaScript, exact and costing no tokens. Routing only the confirmed verdicts to a skeptic costs nothing at all.

The script is a file. Every run writes its script under your session directory in ~/.claude/projects/. You can read it, diff it against the previous run, edit it and relaunch from the edited version, or save it as a command of your own. The orchestration becomes something you keep rather than something you hope to get again.

The downside

Tokens. This is not a footnote. Anthropic puts the notebook run, ten claims against four small source files, at roughly two to four dollars in API usage, and more if a stage fails and retries. On a plan it counts against your limits just as hard. A workflow that verifies everything costs more than one that verifies nothing, and that dial sits in your prompt.

You cannot get in between. There is no mid-run input; only an agent’s permission prompt can pause a run. If you want sign-off between two stages, each stage has to be its own workflow. The prompt you wrote up front is the only steering you get.

Stopping costs more than it looks. On resume, completed agents come back from cache, but the cache stops at the first agent that did not finish. Everything started after that one runs again, even if it completed. Stop a fan-out of four while the second is still going and three of the four run again. And resume only works inside the same session: quit Claude Code and the next session starts the workflow fresh.

The script itself may do nothing. No filesystem, no shell, and an import() fails the run before it starts. All real work happens in the agents. That is a sensible boundary, but it means “just pull in a library” is off the table in the script.

It scales faster than you expect. The runtime runs up to 16 agents concurrently and at most 1,000 per run. From version 2.1.203 Claude Code flags a run that schedules more than 25 agents or projects past 1.5 million tokens, but that is a notice and not a brake. Turn on /effort ultracode and the warning disappears altogether, on the reasoning that you already opted into large runs.

More agents is not more certainty. A skeptic checking a verifier is still the same model looking at the same text. The cookbook is honest about this: the skeptic pass sometimes comes back stricter than the answer key, and they count that as the mechanism working. For an investor update that trade is right. For work where strictness has its own cost, it may not be.

How to use it

• Describe the shape, not just the task. The cookbook’s prompt is mostly about structure: extract, verify per item, set a skeptic on it, compile. The harness you ask for is the harness you get.
• Run a thin slice first. One directory instead of the whole repo, one narrow question instead of a broad one. Then you know what the full run costs.
• Route cheap stages to a small model. Every agent runs on your session model unless the script sends a stage elsewhere. Mechanical extraction does not need your strongest one.
• Set the size deliberately. From version 2.1.219 the workflow size guideline defaults to medium, meaning fewer than fifteen agents. On older versions it sits at unrestricted and Claude sizes the run itself. For most tasks small is plenty.
• Prefer many small agents over a few long ones. Not only for parallelism, but because more work survives an interruption that way.
• Read the script. It is on disk and it is the most honest summary of what happened. If it holds up, save it as a command and the orchestration becomes reusable.
• Start with what ships. /deep-research is a built-in workflow. It shows you the pattern without you having to describe anything.

How not to use it

• Not for work that fits in one context. This is the big one. A single agent stays the right tool for the large majority of tasks. Wrapping a workflow around it makes it more expensive without making it better.
• Not as a speed button. The gain is equal treatment of many items and verification you cannot skip, not wall-clock time.
• Not for anything you want to steer halfway through. There is no mid-run input. If you want to look between two steps, that is two workflows.
• Not with /effort ultracode as your resting state, unless you accept the bill on purpose. That mode plans a workflow for every substantive task in the session and switches off the size warning.
• Not as a replacement for your own judgment about the sources. A compiled report is convenient, and it is exactly the point where reading the material slips out of your hands.
• Not without knowing where the agents may go. Subagents inherit your tool allowlist and run in acceptEdits. Whatever is on that list applies to the whole fleet.

Where I would put this in my own work

Here is the part I have to be upfront about: I have not turned this pattern loose on my own material in production. What follows are the three places in my work where the shape fits, written as candidates rather than as a report.

Editorial checking across the whole corpus. This site now holds dozens of articles in two languages, with gates that catch reused sentences and missing caveat sections. Those gates are deterministic: they count word groups and look for headings. What they cannot do is judge whether a claim in an article still matches the source it cites. That is precisely the fact-check shape from the cookbook, with my articles as claims and the source lines as sources. One verifier per article, a skeptic behind it, one report back.

Wine claims against the source. Wine writing is full of numbers that drift: hectares, vintages, appellation rules, the alcohol figure on a label. That is a claims-against-sources problem in its purest form, and it is the kind of error a reader notices and a spellchecker never will.

Policy documents that cite each other. In public-sector innovation work the hard part is rarely reading one document. It is holding ten of them side by side, where they quote and sometimes contradict each other. The shape fits. Whether that material may pass through a model at all is a separate question, and it has nothing to do with the technique.

All three are candidates. I have run none of them, so there is no agent count here, no dollar figure, and no story about what broke. This piece is an explainer, not a field report. When I do run one, I will write that up separately, bill included.

The caveat

Steering moves to the front. In a conversation you correct course. In a workflow you write the arrangement up front and then watch. There is no mid-run input, only stopping. That makes the result reproducible, and it makes your prompt the only place your judgment still enters the process. Describe the arrangement sloppily and you get a sloppy process executed neatly and consistently.

Responsibility lands on the allowlist. One decision about permitted tools no longer covers one agent but a hundred, all in acceptEdits, all in the same working directory. That is the same question auto mode raised, multiplied. The runtime bounds how many agents run; what those agents may touch is bounded by you.

What drains away is the reading. The output of a fact-check workflow is one report instead of four source files. That is the intent and it is the gain. It is also the moment your judgment about the source material leaves the chain, because you never saw that material. Add the consumption on top: hundreds of agents reading the same documents in parallel are not free thoroughness, they are thoroughness somebody pays for in energy and money.

What I do myself: small as the size guideline, /effort ultracode off, and the question “does this fit in one context” asked first. If the answer is yes, a workflow is waste.

Frequently asked questions

Do I need the Agent SDK for this?

No. Dynamic workflows live in the Claude Code runtime and work in the CLI, the desktop app, the IDE extensions, non-interactive mode with claude -p, and through the Agent SDK. The cookbook uses the Python SDK because it wants to show how you launch a run from code and stream its progress.

How do I start one?

Asking in your prompt is enough: “use a workflow for this” works, as does the keyword ultracode. With /effort ultracode Claude plans one for every substantive task in that session. From the Agent SDK you put Workflow in your allowed_tools and ask for it in plain words.

What does a run cost?

The cookbook cites two to four dollars for the fact-check example with ten claims and four source files, and more if a stage fails and retries. On a plan the usage counts against your limits. The /workflows progress view shows each agent’s token usage while the run is going.

What happens if I stop a run?

You can resume it inside the same session. Completed agents return from cache, but only up to the first agent that did not finish; everything started after that runs again. Quit Claude Code and the next session starts the workflow fresh.

Can I turn this off?

Yes, three ways: the toggle in /config, "disableWorkflows": true in ~/.claude/settings.json, or the environment variable CLAUDE_CODE_DISABLE_WORKFLOWS=1. Organization-wide it goes through managed settings. Off also means the keyword does nothing and ultracode disappears from the /effort menu.

How is this different from subagents?

In who holds the plan. With subagents Claude decides turn by turn what to delegate and every result lands in its context window. With a workflow the script sets the order, intermediate results sit in script variables, and only the final answer comes back.

Sources

• Anthropic, Orchestrate subagents at scale with dynamic workflows, claude-cookbooks, accessed 11 August 2026
• Claude Code Docs, Orchestrate subagents at scale with dynamic workflows, accessed 11 August 2026
• My earlier piece: One word spun up a fleet of AI agents, 5 June 2026

Checked on 11 August 2026 against the cookbook and the documentation. I read the notebook rather than running it: the two-to-four-dollar figure and the outcomes of the fact-check run come from Anthropic’s own text, not from my own observation. The hard limits (16 concurrent agents, 1,000 per run, no mid-run input, no filesystem access from the script) come from the documentation and do not contradict the cookbook. The version requirement is phrased differently in the two places: the cookbook names CLI 2.1.154 or later by way of claude-agent-sdk 0.2.90, while the documentation names only Claude Code 2.1.154 or later. The three use cases in this piece are candidates, not accounts of runs I have made.