For two years, every task you handed Claude Code ran through the same harness: one coding-optimized loop tuned to edit files, run tools, and iterate. It was a good harness. It was also the only harness, which meant a 500-file migration and a one-line typo fix both went through the same machinery. The companion to this article covered the other move a team can make, renting a hosted runtime so it never builds the agent loop by hand. This article covers the opposite direction: instead of one fixed harness for everything, Claude Code writes a new harness at runtime, shaped to the specific job in front of it.
The feature is called dynamic workflows, and most of the coverage of it misses the one sentence that matters. The interesting part is not that Claude can spin up subagents. It is where the plan lives. In a dynamic workflow the plan is a JavaScript program, and the results of the work live in a scripts variable that sits outside any model’s context window. The plan is code, not context. That single design choice is what makes the whole thing worth understanding.
Figure 1 - Code, Not Context: A conventional agent holds its plan inside the model’s context window, where it can be compacted, forgotten, or quietly rewritten as the window fills. A dynamic workflow writes the plan as a JavaScript program and accumulates results in a scripts variable that lives outside every model’s context. The plan becomes a versionable, pausable, resumable artifact instead of a fading memory.
It Is Code, Not Context
Reach for a normal agent and its plan lives in the model’s context window. Reach for an agent team and the plan lives in a shared task list every agent has to read back. Both approaches put the plan inside a context window, and a context window is the one part of the system guaranteed to degrade under load. It fills, it compacts, and what the model is optimizing for on turn 40 drifts away from what you asked on turn 1.
Dynamic workflows move the plan out of that failure zone. When you trigger one, Claude writes a JavaScript orchestration script, an executor runs it in the background, and the intermediate results accumulate in a scripts variable rather than in the model’s attention [1]. The script is an ordinary artifact. You can read it, version it, pause it, resume it after a crash, and audit exactly what ran and why. A plan you can git diff cannot rot the way a plan held in fading memory does.
The trigger is one word: ultracode. Include it in a prompt, or just ask Claude to “use a workflow,” and the model writes the harness for that task [1]. For a whole session, /effort ultracode turns on automatic workflow planning so Claude decides per task when the machinery is worth it, a mode that landed in Claude Code v2.1.203 and later [2]. The keyword was renamed from workflow before v2.1.160, so older write-ups that say “Ultra code” as two words are describing the same single-word trigger [2]. The capability itself is generally available: “Dynamic workflows require Claude Code v2.1.154 or later and are available on all paid plans, with Anthropic API access, and on Amazon Bedrock, Google Cloud’s Agent Platform, and Microsoft Foundry” [2].
There is a model requirement worth naming plainly, because it is the reason this arrived in 2026 and not earlier. Writing a correct harness at runtime is a harder task than doing the work the harness coordinates. Anthropic ties the feature to a specific model: “With Claude Opus 4.8 and dynamic workflows, Claude is now intelligent enough to write a custom harness tailor-made for your use case” [1]. Opus 4.8 is a current generally available model, listed as claude-opus-4-8 for complex agentic and enterprise work [3]. The harness-writing step is where that capability gets spent.
KEY INSIGHT: The question to ask about any agent architecture is where the plan lives. If it lives in a context window, one compaction can erase it. Dynamic workflows make the plan a versionable program, which is why it can survive a crash and be audited after the fact.
Figure 2 - The Runtime Harness, Assembled On Demand: A single orchestrator reads the task, writes a JavaScript program that divides it into subtasks, and dispatches each subtask to a fresh subagent. Every subagent returns its result into the scripts variable. The orchestrator never holds all the work in its own context window at once, which is what keeps a large job from overrunning a single attention budget.
The Three Failure Modes of a Context-Held Plan
The case for moving the plan into code is easiest to see through the three ways a large job fails when it all runs in one context window. Dynamic workflows exist to address each one.
The first is what we will call agentic laziness. When a big job runs in a single window, the window fills, and the model reads that filling as a natural place to stop. A security sweep handles 35 of 50 files, declares itself finished, and hands back a confident summary of partial work. Nothing crashed. The agent simply mistook running low on room for being done.
The second is self-preferential bias. Ask a model to check its own work and it grades kindly, because the same context window that produced the answer is the one now reviewing it. There is no separation between the author and the critic, so the critique inherits every assumption the work was built on.
The third is goal drift. After enough turns and enough context compaction, the original brief leaks out of the model’s effective attention. The agent keeps working, but on a subtly different objective than the one it started with, and it has no way to notice the substitution.
Splitting the job across separate, clean context windows dissolves all three. Each subagent starts fresh with a narrow brief, so it cannot inherit the orchestrator’s laziness, its bias, or its drift. The patterns below are the concrete ways a dynamic workflow performs that split.
Figure 3 - Three Ways a Single Window Fails: Agentic laziness stops early when the window fills. Self-preferential bias grades its own work too kindly because author and critic share one context. Goal drift optimizes a slowly mutated version of the original brief after repeated compaction. A dynamic workflow gives each subagent a fresh window, so none of the three carries forward.
Six Patterns for a Task-Shaped Harness
Anthropic documents six named patterns for how a dynamic workflow structures its subagents [1]. They are not exotic. Each is a small, legible shape you would recognize from ordinary systems design, and the value is in knowing which one a given job wants.
- Classify-and-Act: a classifier subagent examines the incoming work and routes it to the right specialist. It can sit at the front, deciding which handler runs, or at the back, shaping the final output format. A bug report goes to a fixer, a question goes to an answerer, and neither handler needs to know how the other works.
- Fan-Out-and-Synthesize: split the task into N independent pieces, run each in its own window, then hold them all at a barrier until a synthesizer merges the results. This is the pattern for reviewing 50 files independently before writing one summary, where each file deserves its own clean attention.
- Adversarial Verification: a worker produces a result and a separate subagent, with its own window and no stake in the answer, checks it against a rubric. The output survives only if it passes. This is the direct cure for self-preferential bias, because the verifier has no reason to be kind. Add a fixer and you get an implement-verify-fix loop.
- Generate-and-Filter: produce many candidates, then run them through a rubric or an automated test to keep only the best. Use it to explore an option space broadly before committing, with the caveat below that the filter has to be objective for this to pay off.
- Tournament: several subagents each attempt the same task differently, and a judge compares them head to head, because pairwise comparison is more reliable than absolute scoring. Winners advance until one remains. This is how you rank 1,000 items that would never fit in a single prompt.
- Loop-Until-Done: a subagent runs, then a gate asks whether new findings remain. If yes, run another pass. If no, stop. Termination is a decision the loop makes, not a side effect of the context window filling up.
That last pattern is the direct answer to agentic laziness, and it is worth pausing on. In a context-held job the agent stops when it runs out of room. In a loop-until-done workflow it stops when the completion criterion is satisfied, which is a different and much better trigger. The loop does not care that the window is full. It cares whether the job is finished, and it keeps re-entering until the answer is no.
Figure 4 - The Six Named Patterns: Anthropic’s official taxonomy for structuring subagents inside a dynamic workflow. Classify-and-act routes, fan-out-and-synthesize parallelizes then merges, adversarial verification checks with an independent critic, generate-and-filter explores then prunes, tournament ranks by pairwise comparison, and loop-until-done runs until a completion gate says stop.
Figure 5 - Fan-Out-and-Synthesize: The task splits into N independent pieces, each running in its own context window so they cannot contaminate one another. A synthesizer waits at a barrier until every piece finishes, then merges the results into one output. The isolation is the point: each piece gets clean attention that a single shared window could not give it.
Figure 6 - Adversarial Verification: The worker produces a result. A separate verifier with its own context window and no attachment to the answer checks it against a rubric. Output is kept only if it survives the critique, and a fixer can close the loop. The verifier did not write the work, so it has no incentive to grade it kindly.
KEY INSIGHT: Loop-until-done fixes agentic laziness and adversarial verification fixes self-preferential bias, because both replace a single self-judging window with a structure that has an external stopping rule. When an agent quits early or grades itself too well, the fix is usually not a better prompt. It is a second window that does not share the first one’s incentives.
Figure 7 - Loop-Until-Done: Each pass runs, then a completion gate asks whether new findings remain. A yes re-enters the loop, a no exits. The gate, not the size of the context window, decides when the job is finished, which is exactly why the pattern beats an agent that stops when it runs low on room.
What It Costs to Run
Dynamic workflows are powerful and expensive in equal measure, and the system has no built-in brake. Left pointed at a vague goal, it will keep spinning up subagents until your budget is gone. So the operational facts matter before the aesthetic ones.
The ceiling is up to 16 concurrent agents at any moment, fewer on machines with limited CPU cores, and 1,000 agents total per run [2]. Read the 16 as a maximum, not a constant. On a constrained laptop the practical concurrency is lower. The 1,000 is the total fan-out budget for a single run. Live demonstrations that show hundreds of agents in one session are counting agents at a moment in time, not reporting a limit, so treat any “hundreds in a single session” figure as illustration rather than a documented number.
You can cap spend conversationally. Telling Claude to “use 10k tokens” sets the token budget for that run [1]. When you land on a workflow worth keeping, press s in the workflow menu to save it to ~/.claude/workflows, or ship it inside a skill so a team reuses it [1]. A saved workflow can even route a different model to each subagent and run each in its own isolated git worktree, so a cheap classifier and an expensive implementer coexist in one run without stepping on each other’s files [1].
The cautionary case is the Bun runtime’s migration from Zig to Rust, which Anthropic cites in the dynamic-workflows post as a real example done with workflows [1]. Bun’s maintainer, Jarred Sumner, reported on X that the AI-generated Rust carried more than 13,000 unsafe blocks against 73 in the handwritten equivalent [4]. Those numbers come from Sumner’s thread, not from Anthropic, and they are a single-source illustration rather than a benchmark. The lesson still transfers: even a migration with strong test coverage as its oracle can produce output that runs and passes yet is not what you would have written by hand. An objective oracle tells you the result works. It does not tell you the result is good.
Figure 8 - The Ceiling and the Brake: A single run can hold up to 16 concurrent agents, fewer on limited-CPU machines, and 1,000 agents total. The system has no automatic spend limit, so the only brake is the one you set, a conversational token budget such as “use 10k tokens.” Fan-out this wide is a cost multiplier, not a free lunch.
The Decision Tree: When To Reach For This
There is no internal brake, so the discipline lives in deciding whether to start a workflow at all. Three gates decide it, and all three have to clear.
The first and most important gate is an objective, measurable oracle. Something outside the model has to be able to say pass or fail: a test suite, a required output schema, a classification rubric, a compile step. If the only judge of “good” is the same kind of model that produced the work, fanning out 200 subagents just produces 200 confidently-argued opinions and a large bill. No ground truth, no workflow.
The second gate is a genuine need for massive fan-out. If the job is a handful of steps, a single agent or a plain prompt is cheaper and easier to follow. Workflows earn their overhead when the parallelism is real: hundreds of files to review, a large inbox to triage, a corpus of transcripts to audit against one rubric. That last case is worth stressing, because dynamic workflows are not a coding-only tool. Batch knowledge work, running the same extraction or review prompt across hundreds of documents in parallel, is a first-class use, and its oracle is a schema or a required-field check rather than a passing test.
The third gate is a need to hold state across the run. If a job has to remember what earlier passes found and branch on it, that state belongs in the workflow’s script and its scripts variable, not in a context window trying to keep it all in mind. When a job clears the oracle gate but needs neither wide fan-out nor mid-run state, /goal alone, a single agent with a hard completion requirement, is often the right and cheaper tool.
The wrong uses share one property: no objective oracle. Generating 10 website copy variants, where the model cannot know which reads best. Rating your own skills, where self-preferential bias is the whole problem. A small, well-scoped change a single agent finishes in seconds. Point a workflow at any of these and it burns tokens against a subjective target with nothing to tell it to stop. The published /deep-research skill is the clean positive example: it fans out web searches, adversarially verifies the claims it gathers, and synthesizes a cited report, all on dynamic workflows underneath, precisely because “did the sources corroborate this claim” is an oracle the system can actually check [1].
Figure 9 - Three Gates Before You Fan Out: Gate one asks whether an objective, measurable oracle exists. No oracle means no workflow, full stop. Gate two asks whether the job genuinely needs massive fan-out. Gate three asks whether it needs state mid-run. A job that passes the oracle gate but needs neither wide parallelism nor durable state is usually better served by /goal on a single agent.
KEY INSIGHT: The oracle gate is not bureaucracy, it is the minimum spec that keeps a wide fan-out from failing quietly. If you cannot write down what “done” objectively looks like before the run starts, the workflow cannot know either, and it will spend your budget guessing.
The Orchestration Tax
Suppose every gate clears and the workflow runs beautifully. There is still a ceiling nobody prints on a pricing page, and it is not the 1,000-agent limit. It is you.
The number of workflows you can actually operate in parallel is set by how much output a human can review, not by what the tooling can launch. Every unattended pass that produces work also produces review debt, and that debt does not disappear because the run succeeded. Addy Osmani makes the point directly in his essay on loop engineering: a loop running unattended is also a loop making mistakes unattended, and the reviewer’s burden compounds with every iteration [5]. We call this the orchestration tax, and it inverts the naive assumption that more automation means more throughput. More automation demands proportionally more human review capacity. A team that skips the review to gain throughput has not escaped the tax. It has deferred it into undetected errors that surface later, usually at the worst time.
The failure mode a wide fan-out invites is not a loud crash. A loud crash you would catch. The dangerous outcome is the workflow that succeeds quietly, in a direction you stopped following a few hundred commits ago, shipping confident output nobody read closely. This is sharpest in regulated settings, healthcare, legal, financial, where compliance review is a human step that cannot be parallelized as freely as the loops that feed it. In those contexts the real ceiling on how many workflows you can run is the size of the review team, not the API rate limit.
Figure 10 - The Orchestration Tax: The tooling can launch far more parallel workflows than a human can review. The true ceiling is review bandwidth, not the agent limit or the rate limit. Work that ships without passing through that bottleneck has not skipped the tax, it has converted it into undetected errors downstream.
Composing the Pieces
Dynamic workflows do not stand alone. They compose with the two commands that turn a one-shot workflow into an ongoing system. Pair a triage or research workflow with /loop to re-run it at regular intervals, and use /goal to hand it a hard completion requirement, so the workflow runs until the goal is met rather than until it feels done [1]. A saved workflow, checked into ~/.claude/workflows or shipped in a skill, becomes a reusable asset a team invokes by name instead of rebuilding by prompt each time [1].
The practical shape this suggests is modest. Start with a task that has a real oracle. Cap the token budget conversationally. Run it once, read the output closely enough to trust it, then decide whether it earns a /loop. Resist the urge to fan out to the ceiling on day one, not because the tooling cannot handle it, but because your review bandwidth cannot. The tooling scales the work. Only you scale the trust.
Figure 11 - Composing the Machinery: A dynamic workflow pairs with /loop for scheduled re-runs and /goal for a hard completion requirement. Saving it with s writes it to ~/.claude/workflows or into a skill for reuse. The /deep-research skill is a shipped workflow built this way, fanning out searches, verifying claims adversarially, and synthesizing a cited result.
Conclusion
Dynamic workflows are the second half of a trade the managed-runtime article opened. One direction rents the harness so a team never builds the loop. The other lets the model write a fresh harness at runtime, shaped to the job, with the plan living in code instead of context. Both aim at the same target: keep the durable part of the work, the plan and the record, out of the one place guaranteed to degrade.
The six patterns are the easy part to learn. Classify-and-act, fan-out-and-synthesize, adversarial verification, generate-and-filter, tournament, and loop-until-done are legible shapes, and matching one to a job is a skill that comes quickly. The hard part is the discipline around them. A workflow with no objective oracle has nothing to tell it when to stop, and a wide fan-out with no matching review capacity ships quiet errors at scale. The teams that get value from this feature are the ones that treat the oracle gate and the orchestration tax as the real work, and the pattern selection as the easy part. Write down what “done” objectively means, cap the spend, run one loop, read the output, and only then decide whether to run a hundred more.
The Series
This is Part 2 of the 2-part Managed Runtimes & Dynamic Workflows sub-series:
- Managed Agents: Stop Building the Agent Loop Yourself. The hosted runtime category: brain/hands/session architecture, Anthropic vs Google, the competitive landscape, and the model-drift risk a managed runtime does not remove.
- Dynamic Workflows: Six Patterns for Writing Your Own Harness at Runtime (this article). The other half of the trade: Claude Code writing a task-specific harness at runtime, the six named orchestration patterns, and the cost-discipline decision tree for when to use them.
References
[1] T. Shihipar and S. Bidasaria, “A harness for every task: dynamic workflows in Claude Code,” Anthropic, Jun 2026. https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code
[2] Anthropic, “Orchestrate subagents at scale with dynamic workflows,” Claude Code Documentation, 2026. https://code.claude.com/docs/en/workflows
[3] Anthropic, “Models overview,” Claude Platform Documentation, 2026. https://platform.claude.com/docs/en/docs/about-claude/models
[4] J. Sumner, X thread on the Bun Zig-to-Rust migration, 2026. https://x.com/jarredsumner/status/2060050578026189172
[5] A. Osmani, “Loop Engineering,” addyosmani.com, 2026. https://addyosmani.com/blog/loop-engineering/
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.