Book a call (opens Google Calendar)
Book a call (opens Google Calendar) hey@pronovahq.com

Claude Code Dynamic Workflows Explained

By Izzy Aly, Co-Founder, Systems and Architecture

Dynamic workflows turn one Claude Code chat into maker, checker and fixer agents. 57% of organisations already deploy agents for multi-stage workflows.

At YC Startup School 2026, Boris Cherny talked through the birth of Claude Code. He kept coming back to the same idea: the best builders today are not the ones writing the cleverest prompts. They are the ones figuring out how to unhobble the model, how to hand it a task that feels slightly too hard, give it a clear definition of done, and get out of its way.

Dynamic workflows are the Claude Code feature built for exactly that. You describe an outcome, and Claude writes a custom harness on the fly: separate maker, checker, and fixer agents, each with its own clean window and one narrow job. The result is the difference between a long conversation that slowly loses the thread and a multi-day run that actually finishes.

This post is about what dynamic workflows actually are, when they are worth the extra tokens, what they cannot do, and how to start building workflow instructions you can reuse. I have watched enough long tasks drift sideways in a single window that I now reach for structure before I reach for a better prompt.

Key takeaways

  • One Claude in one window hits three structural limits: agentic laziness, self-preferential bias, and goal drift (Chung et al., 2025; Pombal et al., 2026; Du et al., Findings of EMNLP 2025).
  • Dynamic workflows split work across maker, checker, and fixer agents so nobody grades their own homework.
  • The six reusable patterns are classify-and-act, fan-out-and-synthesize, adversarial verification, generate-and-filter, tournament, and loop-until-done.
  • Start with the open skill repo at github.com/pronovahq/prompt-workflow-architecture, paste a workflow instruction, adapt the rubric, and save the run as a command you can rerun.

Why does one long chat window eventually fail?

The default Claude Code harness is excellent for bounded work: a function, a refactor, an error you need explained, a small bug. The trouble starts when the task grows past the window. Hundreds of files. Thousands of rows. A strict rubric. A run that has to last longer than an afternoon.

In one window, three failure modes set in. These are not quirks you can prompt around. They are structural.

Agentic laziness

Claude starts optimising for completion inside a shrinking window. It closes 20 of 50 review items and calls it done. Research on long-context web agents shows success rates dropping from 40–50% to under 10% as the task drags on, mostly because the agent gets stuck in loops and loses sight of the original objective (Chung et al., 2025).

Self-preferential bias

Ask the same Claude that wrote the output to grade the output, and it will pass itself more often than it should. A 2026 study found that, on rubrics the output fails, LLM judges can be more than 50% more likely to incorrectly mark it as satisfied when the output is their own, even with fully objective, programmatically verifiable rubrics (Pombal et al., 2026). On a benchmark with subjective rubrics (HealthBench, in the same study), that self-preference bias skewed scores by up to 10 points, a margin that can decide how frontier models rank. No clever prompt removes it.

Goal drift

Over many turns, especially after context compacts, the objective blurs. The guardrail you wrote at the start quietly falls off. Even when the model can retrieve every relevant token, sheer context length degrades performance by 13.9% to 85% (Du et al., Findings of EMNLP 2025).

Why one long window fails: three structural limits Three structural limits of running a long task in one context window, each with its research figure. Agentic laziness: web-agent success falls from 40–50% to under 10% in long context, as the agent loops and loses the objective (Chung et al., 2025). Self-preferential bias: an LLM judge can be more than 50% more likely to wrongly pass a failing rubric when the output is its own (Pombal et al., 2026). Goal drift: context length alone degrades performance by 13.9% to 85%, even when every relevant token can be retrieved (Du et al., Findings of EMNLP 2025). A workflow fixes all three by structure: each subtask gets its own window, its own goal and its own judge. WHY ONE LONG WINDOW FAILS Agentic laziness 40–50% → <10% web-agent success The agent loops, loses the objective and calls partial work done. Chung et al., 2025 Self-preferential bias >50% more likely to wrongly pass itself A judge grading its own output passes rubrics the output fails. Pombal et al., 2026 Goal drift 13.9%–85% performance lost Context length alone degrades performance, even with full retrieval. Du et al., EMNLP 2025 A workflow fixes all three by structure: own window, own goal, own judge.
Why one long window fails: three structural limits Three structural limits of running a long task in one context window, each with its research figure. Agentic laziness: web-agent success falls from 40–50% to under 10% in long context, as the agent loops and loses the objective (Chung et al., 2025). Self-preferential bias: an LLM judge can be more than 50% more likely to wrongly pass a failing rubric when the output is its own (Pombal et al., 2026). Goal drift: context length alone degrades performance by 13.9% to 85%, even when every relevant token can be retrieved (Du et al., Findings of EMNLP 2025). A workflow fixes all three by structure: each subtask gets its own window, its own goal and its own judge. WHY ONE LONG WINDOW FAILS Agentic laziness Chung et al., 2025 40–50% → <10% success, long context Self-preferential bias Pombal et al., 2026 >50% more likely to wrongly pass Goal drift Du et al., EMNLP 2025 13.9%–85% performance lost to length A workflow fixes all three by structure: own window, own goal, own judge.
Fig. 1 — Each limit is structural, so a better prompt does not remove it. Source: Chung et al., 2025, Pombal et al., 2026 and Du et al., Findings of EMNLP 2025.

A workflow fixes all three by structure, not willpower. It gives each subtask its own window, its own narrow goal, and, crucially, its own judge.

What are dynamic workflows, really?

Dynamic workflows are the Claude Code feature that turns one chat into a team. You describe an outcome, and Claude writes a custom harness for that exact task, then runs it.

What the harness does

Under the hood, the harness is a JavaScript script Claude writes for your task. A runtime executes it in an isolated environment, separate from your conversation, while your session stays responsive. The script spins up separate worker agents, assigns each one a narrow job, and routes their outputs through verification and synthesis steps. Intermediate results stay in the script, so Claude's context holds only the final answer (Claude Code docs). The harness is not generic; it is tailored to your files, your rubric, your stop conditions, and your budget.

The three roles you cannot merge

The separation that matters is the one you cannot fake in a single window:

  • The maker does the work.
  • The checker grades it against a rubric.
  • The fixer steps in only when the checker says the work is not good enough, reworks the specific failing part, and sends it back to the checker. The fixer is a second maker, not a judge; it never signs off on its own output.
Maker, checker, fixer: the three roles you cannot merge A loop of three separate agents. The task and its rubric go to the maker, which does the work. The checker grades the work against the rubric. On a pass, the work is done. On a fail, it goes to the fixer, which reworks only the failing part and sends it back to the checker. The fixer is a second maker, not a judge: it never signs off on its own output. MAKER, CHECKER, FIXER Task and rubric Maker does the work Checker grades against the rubric Done pass Fixer reworks the failing part fail resubmit The fixer is a second maker, not a judge: it never signs off on its own output.
Maker, checker, fixer: the three roles you cannot merge A loop of three separate agents. The task and its rubric go to the maker, which does the work. The checker grades the work against the rubric. On a pass, the work is done. On a fail, it goes to the fixer, which reworks only the failing part and sends it back to the checker. The fixer is a second maker, not a judge: it never signs off on its own output. MAKER, CHECKER, FIXER Task and rubric Maker does the work Checker grades against the rubric pass fail resubmit Done Fixer reworks the failing part The fixer never signs off on its own output.
Fig. 2 — The checker is the only role that can pass the work; the fixer always sends its rework back for grading.

This is what turns a drifting chat into something that can carry a hard, multi-day task to completion. Nobody is grading their own homework, and nobody is trying to hold the entire plan, the execution, and the verification in one context window at the same time.

One note on availability: dynamic workflows launched as a research preview in May 2026 and are now generally available on all paid plans and through the API, Amazon Bedrock, Google Cloud and Microsoft Foundry; on Pro, you turn them on in /config (Anthropic; Anthropic; Claude Code docs). If an admin has turned them off, the same workflow-shaped problems are still solvable by hand with the Claude API and the Agent SDK; you just have to wire the harness yourself.

When is a single window not enough?

You do not need a workflow for every task. A single Claude in a single window still handles most day-to-day work. Reaching for a workflow for a two-line bug fix is like calling a town hall meeting to decide what to have for lunch.

Reach for a workflow when the task has one of these shapes:

  • It is long enough that the context window will compact before it finishes.
  • It is parallel enough that one agent would have to queue up work that could run side by side.
  • It is adversarial; you need a real second opinion, not a polite self-review.
  • It has a strict rubric and a binary definition of done.
  • It spans multiple files, multiple data sources, or multiple days.

The test is simple: if you have ever watched Claude lose the thread halfway through a task and quietly redefine success downward, that task is workflow-shaped.

What can you use workflows for?

The first assumption people make is that this is a developer tool. It is not. A workflow is just Claude coordinating a team of Claudes, and the jobs that need a team show up in every function. 57% of organisations already deploy agents for multi-stage workflows, and 80% report measurable ROI today (Anthropic, The 2026 State of AI Agents Report).

Ranking a pile of stuff. “Here are 80 resumes. Use a workflow to rank them for the backend role, then double-check the top ten. Interview me to build the rubric first.” One agent reads each resume. A tournament compares pairs. A checker re-reads the top ten so nothing good slips through. You can run the same shape over support tickets, vendor proposals, bug reports, or a quarter of customer feedback.

Fact-checking your own writing. “Go through my blog draft and use a workflow to verify every technical claim against the codebase. I do not want to ship anything wrong.” One agent extracts claims. A separate agent checks each one. A third rates the strength of the source. The writer never gets to wave their own claim through.

Mining a backlog nobody reads. “Dig through #incidents in Slack for the last six months and find recurring root causes where nobody filed a ticket.” Separate agents form theories from separate evidence, then argue them out. Swap Slack for sales numbers, a failed process, or a churn analysis, and the same shape runs the post-mortem.

Naming things and other taste calls. “Brainstorm 30 names for this tool, then run a workflow tournament to pick the top three against a rubric.” A generator proposes options. A reviewer scores them against what “good” means. A bracket picks the winner. No single agent falls in love with its own idea.

Turning your mistakes into rules. “Use a workflow to go through my last 50 sessions, find the corrections I keep making, and turn the recurring ones into rules.” It clusters the corrections, checks each candidate rule against a real past mistake, and keeps only the ones that would have caught something. The survivors become institutional memory.

The six reusable patterns

Anthropic names six common patterns that Claude composes its workflows from (Anthropic, 2026). You do not need to memorise them to use workflows, but learning them helps you read the harness after it is built and steer it next time.

PatternWhat it doesBest for
Classify-and-actA classifier decides the task type, then routes to the right agentMulti-type inboxes, triage, routing
Fan-out-and-synthesizeSplit the work into many small steps, run an agent on each, then merge the results.Bulk processing, audits, migrations
Adversarial verificationFor every maker, spawn a second agent whose only job is to attack the output against a rubric.Fact-checking, code review, grading
Generate-and-filterMake many candidates, drop duplicates, keep only tested survivorsBrainstorming, test-case generation
TournamentAgents compete on the same task; a judge compares pairs until a winner emerges.Ranking, naming, design selection
Loop-until-doneKeep going until a condition holds, not until a fixed counter runs outBug hunting, exhaustive verification
The six reusable workflow patterns Six small schematics, one per pattern, each with what it is best for. Classify-and-act: one classifier routes each task to one of three agents; best for triage and routing. Fan-out-and-synthesize: one task splits across many agents whose results merge into one; best for bulk processing, audits and migrations. Adversarial verification: each maker is paired with an attacker that tests its output against a rubric; best for fact-checking and code review. Generate-and-filter: many candidates narrow to a few tested survivors; best for brainstorming and test-case generation. Tournament: candidates meet in a bracket of pairwise comparisons until one winner remains; best for ranking and naming. Loop-until-done: work cycles through a check until a stop condition holds; best for bug hunting and exhaustive verification. Source: Anthropic, 2026. SIX REUSABLE PATTERNS Classify-and-act Triage, routing Fan-out-and-synthesize Bulk processing, audits, migrations Adversarial verification Fact-checking, code review Generate-and-filter Brainstorming, test-case generation Tournament Ranking, naming Loop-until-done Bug hunting, exhaustive verification Source: Anthropic, “A harness for every task: dynamic workflows in Claude Code”, 2026.
The six reusable workflow patterns Six small schematics, one per pattern, each with what it is best for. Classify-and-act: one classifier routes each task to one of three agents; best for triage and routing. Fan-out-and-synthesize: one task splits across many agents whose results merge into one; best for bulk processing, audits and migrations. Adversarial verification: each maker is paired with an attacker that tests its output against a rubric; best for fact-checking and code review. Generate-and-filter: many candidates narrow to a few tested survivors; best for brainstorming and test-case generation. Tournament: candidates meet in a bracket of pairwise comparisons until one winner remains; best for ranking and naming. Loop-until-done: work cycles through a check until a stop condition holds; best for bug hunting and exhaustive verification. Source: Anthropic, 2026. SIX REUSABLE PATTERNS Classify-and-act Triage, routing Fan-out-and-synthesize Audits, migrations Adversarial verification Fact-checking, review Generate-and-filter Brainstorming, test cases Tournament Ranking, naming Loop-until-done Bug hunting
Fig. 3 — Six common patterns Claude composes workflows from. Source: Anthropic, 2026.

The pattern that matters most is adversarial verification. It is the structural move behind every useful workflow: the agent that made the thing cannot be the agent that signs off on the thing.

What changed in May 2026?

Before dynamic workflows, the closest thing to a workflow was a static, hand-wired orchestration script. A developer had to anticipate every branch, build a generic harness, and maintain it as the task changed. It worked, but it was rigid.

Dynamic workflows made the harness generative. You describe the outcome; Claude writes the orchestration for that specific case. The difference is like buying a suit off the rack and having one tailored to your measurements. Anthropic shipped them on 28 May 2026 as a research preview, the same day as Claude Opus 4.8 (Anthropic), and they have since become generally available (Anthropic). Opus 4.8 is now a legacy model: Anthropic's current line-up is Claude Fable 5.1, Opus 5.5, Sonnet 5.5 and Haiku 5.5 (Anthropic models overview).

The most telling public example so far is the one Boris discussed: Jarred Sumner used a dynamic workflow to port Bun from Zig to Rust, roughly 750,000 lines of Rust, a 99.8% test pass rate, and 11 days from first commit to merge (Anthropic, 2026). That is not a demo: Bun 1.4, released on 20 August 2026, is the first Bun release written in Rust (Bun). It is production infrastructure, rewritten by a team of Claudes orchestrated by one human with a prompt.

Boris was careful not to claim this was a single prompt with zero steering. There was steering. But the point stands: “previous models just couldn't do this, even with the steering,” and he dates the change to Fable. What makes the orchestration itself dynamic is the script: it branches on what earlier agents return, so the run can change course and keep going based on what it learns mid-run, without a developer anticipating every branch up front.

The real trade-offs

Dynamic workflows are not free. They burn more tokens, they take longer to set up than a single prompt, and they can be overkill.

  • Cost. A panel of five reviewers is overkill for a normal bug fix. Claude Code shows a Large workflow warning once a run schedules more than 25 agents or its projected total passes 1.5 million tokens (Claude Code docs). You can cap the budget (Anthropic's own example prompt is “use 10k tokens”, per Anthropic) or set a smaller workflow size in /config, but the ceiling is still higher than a single-window session.
  • Setup. You have to describe the task, the rubric, and the stop conditions clearly enough for Claude to build the harness. If you do not know what “done” looks like, a workflow will not tell you.
  • Monitoring. Long-running workflows need check-ins. They save progress and can resume, but you still want to know whether the run is converging or spinning. /workflows shows each phase, its agents and their token usage as the run goes.

Use workflows where the cost of getting it wrong is higher than the cost of the extra tokens. For everything else, a single Claude in a single window is still the right call.

Frequently asked questions

Do I need to be a developer to use dynamic workflows?

No. You need to describe what you want done. Claude picks the patterns. The six patterns are for reading the harness after it is built. They help you understand what Claude decided and why, so you can steer it next time. But your first workflow works with nothing more than a clear prompt.

How many tokens does a workflow burn?

It varies by task, but dynamic workflows consume substantially more than a typical session. /workflows shows each agent's token usage while it runs, so you can stop a run there, usually without losing completed work. You set the ceiling with a budget in the prompt, and a smaller workflow size in /config steers Claude towards fewer agents. For recurring workflows, the cost drops over time as you learn which patterns your tasks actually need.

What happens if a workflow fails mid-run?

Workflows save progress as they go. An agent that stalls restarts on its own, and inside a fan-out a failed agent leaves an empty slot instead of crashing the run. Relaunch a stopped run and finished agents return their saved results, up to the first one that failed or changed. If you exit Claude Code mid-run, the run does not continue on its own: resume the session and ask Claude to relaunch it (Claude Code docs). The runtime tracks every agent's result, so it knows what is done and what is left.

Is this only for Claude Code, or can I use it with the API?

Dynamic workflows are a Claude Code feature; they rely on Claude's ability to write orchestration scripts and on the runtime that executes them. That runtime runs wherever Claude Code does: the CLI, the Desktop app, the IDE extensions, claude -p and the Agent SDK. The underlying patterns (fan-out, adversarial verification, tournament) can be implemented with the Claude API directly, but the “describe it, and Claude builds it” experience is Claude Code-specific.

How do I start building my own workflow instructions?

Clone the open skill repo at github.com/pronovahq/prompt-workflow-architecture. Each instruction is a prompt file with a rubric and stop conditions. Paste one into Claude Code, adapt the rubric to your task, and once a run does what you wanted, save it from /workflows as a command of your own. Start with one hard task that keeps slipping through a single window, split the maker from the checker, and see if the structure does what a better prompt cannot.

What was Boris's bigger point?

Boris's argument at YC Startup School was not really about dynamic workflows as a feature. It was about the broader shift in what it means to use a frontier model well.

The old style was to write increasingly specific prompts: do this, then this, then this, in exactly this way. The new style is to describe the task, describe the guardrails, describe the exit criteria, and let the model cook. As Boris put it, “You want to describe the task, you want to describe the guardrails, you want to describe the exit criteria, and then just go let the model cook and come back in a little bit.”

That only works if you also give the model a way to verify its own work, because verification is what keeps a long-running task from wandering off into the weeds. Boris put that even more bluntly: “The verification is probably the single most important thing that people do not get right, largely.”

That is the connection. Dynamic workflows are the mechanism that makes “give it a hard task and a clear definition of done” actually work for tasks longer than an afternoon. They are the unhobbling move for multi-day work.

They are also a Claude Code-specific move. The underlying patterns (fan-out, adversarial verification, tournament) can be implemented with the Claude API and the Agent SDK if you want to wire them by hand. Loop-until-done is one of the patterns Anthropic names for Claude Code workflows. But the “describe it, and Claude builds the harness” experience, plus the runtime that keeps every agent's result so a run can pick up where it stopped, is what Claude Code does.

Where to start

If you want to go beyond reading, the open skill repo at github.com/pronovahq/prompt-workflow-architecture provides reusable workflow instructions. Paste one into Claude Code, adapt the rubric to your task, and save the run as a command from /workflows. Start with one hard task that keeps slipping through a single window, split the maker from the checker, and see if the structure does what a better prompt cannot.

Topics
Author
Izzy Aly · Co-Founder, Systems and Architecture
Share

Keep reading

All posts →