Claude Code Dynamic Workflows: When Agent Orchestration Is Worth It

Download the 10-slide visual deck as PDF

Claude Code Dynamic Workflows are easy to misunderstand.

After Anthropic's June 2026 write-up, the tempting headline is still: Claude Code can now coordinate many agents in parallel.

But that is not the real lesson.

The deeper shift is this:

Claude Code is moving from a conversation loop toward an orchestration loop.

A normal Claude Code session is already powerful. It can inspect a repository, edit files, run commands, use tools, review output, and continue. Subagents extend that by delegating focused work to separate roles.

Dynamic Workflows go one level further. They let Claude generate an executable JavaScript orchestration script that coordinates subagents, tracks intermediate state, branches across stages, and consolidates results in the background.

Anthropic describes this as Claude Code writing and orchestrating its own task-specific harness. That word matters. A harness is not just "more workers." It is the structure that holds the work together.

That makes them powerful.

It also makes them expensive, easy to overuse, and dangerous if the task is not scoped.

This guide is my practical judgment: when Dynamic Workflows are worth using, when they are not, and how to think about them without turning every task into a token bonfire.

1. What Dynamic Workflows Are

Dynamic Workflows are a research-preview capability in Claude Code for complex agent orchestration.

Instead of only keeping the plan inside the model's current context, Claude can generate a JavaScript workflow script. That script becomes the coordination layer for a larger job.

The official docs say Dynamic Workflows require Claude Code v2.1.154 or later. They are available on paid plans and supported Claude Code environments, and Pro users can enable them from /config.

The rough shape is:

user goal
-> Claude drafts a workflow
-> JavaScript orchestration script
-> multiple subagents
-> intermediate results
-> review / aggregation
-> final answer or deliverable

The important word is not "parallel."

The important word is orchestration.

Dynamic Workflows are useful when the task itself needs a small operating system: task queues, stages, partial results, cross-checking, and a lead agent that can turn scattered findings into one coherent output.

That is different from asking Claude Code to fix one bug or write one function.

2. The Old Loop vs. The New Loop

A normal Claude Code workflow looks like this:

understand context
-> choose action
-> use tool
-> observe result
-> continue or ask

This is the loop I still teach first.

It is enough for most real work:

• inspect the repo;

• make a plan;

• change a small slice;

• run checks;

• review the diff;

• revise or commit.

Dynamic Workflows add another layer:

define goal and boundaries
-> generate orchestration script
-> spawn specialized agents
-> collect independent results
-> run review or adversarial passes
-> consolidate findings
-> report risks and next actions

The workflow is no longer just "Claude thinks, then acts."

It becomes "Claude writes the coordination logic for a group of agents, then runs that coordination logic."

That changes the kind of task you should give it.

3. Subagents vs. Skills vs. Dynamic Workflows

These features can sound similar, but they solve different problems.

Subagents are useful when you need a focused worker:

• a reviewer;

• a researcher;

• a tester;

• a security auditor;

• a documentation writer.

Skills are useful when you have a reusable instruction contract:

• how to review a diff;

• how to produce a slide deck;

• how to run a migration;

• how to stage a blog handoff;

• how to apply project-specific rules.

Dynamic Workflows are useful when the coordination itself becomes complex:

• many agents;

• multiple stages;

• branching;

• intermediate state;

• aggregation;

• review passes;

• resumable background work.

My mental model:

Subagents = delegated roles.
Skills = reusable procedures.
Dynamic Workflows = executable orchestration.

The official docs make the same distinction from another angle: who holds the plan and where intermediate results live.

With a normal turn, subagent, or skill, a lot of state still flows through Claude's conversation context. With a workflow, the script holds the loop, branching, and intermediate variables. Claude sees the final consolidated result instead of trying to keep every partial result in one long context window.

If you only need one role, use a subagent.

If you only need a repeatable instruction, use a skill.

If you need many roles moving through a staged plan with state and review, then Dynamic Workflows may be justified.

4. When Dynamic Workflows Are Worth It

Dynamic Workflows are best for tasks that are large, separable, and reviewable.

The task should have multiple work packets that can be handled independently, then consolidated.

Good candidates include:

1. Codebase-wide audits

Ask multiple agents to inspect different modules, search for recurring bug patterns, and return findings in a shared schema.

2. Large migrations

For example: migrating many files from one API pattern to another, where each batch needs local edits, validation, and a summary.

3. Security or performance sweeps

Let agents inspect different layers, then use a judge phase to challenge false positives and missing evidence.

4. Multi-source research synthesis

Assign different sources, ask each agent to extract claims and evidence, then have a consolidation pass merge, de-duplicate, and flag weak claims.

5. Adversarial quality gates

Use one set of agents to build or propose, and another set to review for bugs, missing tests, scope creep, and unsupported claims.

The shared pattern is:

many independent observations
-> structured intermediate outputs
-> cross-checking
-> final synthesis

If the work does not need that pattern, you probably do not need a Dynamic Workflow.

5. When Not To Use It

The fastest way to waste Dynamic Workflows is to use them for small work.

Do not use them for:

• a single-file bug fix;

• a quick explanation;

• a small copy change;

• a narrow refactor;

• an unclear product idea;

• a task where you cannot define success;

• anything where the cost of orchestration is larger than the task.

For these tasks, ordinary Claude Code is better.

Use the base workflow:

explore -> plan -> code -> review/check -> commit or revise

That loop is boring in the best way. It keeps scope small. It makes changes inspectable. It teaches the human what happened.

Dynamic Workflows should not replace this baseline.

They should sit above it as an advanced option.

6. Why Anthropic Thinks Workflows Help

Anthropic names three failure modes that show up in long, complex agent work.

Agentic laziness

The agent stops after partial progress and declares the job done.

Example: it reviews 35 of 50 files and then writes a confident summary as if the whole review happened.

A workflow helps because the work can be split into explicit batches, phases, and completion conditions.

Self-preferential bias

The same agent that produced a result also judges the result.

This is shaky. It is a bit like letting a student write the exam and grade it with vibes. Charming, but not exactly ISO certified.

A workflow helps by assigning independent verifier or judge agents.

Goal drift

Long sessions lose fidelity to the original objective, especially after context compaction.

A workflow helps because the orchestration logic, stop conditions, and intermediate state live in code rather than only in the model's current memory.

That does not make workflows magically correct.

It makes the failure surface more inspectable.

7. The Cost Reality

Dynamic Workflows can be expensive because they multiply work.

You are not only paying for one answer. You are paying for:

• the orchestration planning;

• each subagent's context;

• each subagent's tool use;

• intermediate summaries;

• review passes;

• final aggregation.

That can be worth it for a migration, audit, or research synthesis where the alternative is many hours of manual coordination.

But if you use it for a five-minute task, you have only made the five-minute task theatrical.

My rule:

Only use Dynamic Workflows when the cost of not coordinating the work is higher than the cost of coordination.

That sounds obvious, but it is the line that prevents overuse.

8. The Official Pattern Library

Anthropic's article names several reusable workflow patterns. These are useful because they give you vocabulary for prompting.

Classify-and-act

Use a classifier agent to route each item before action.

Good for support queues, bug reports, raw knowledge inboxes, or any workflow where different items need different treatment.

Fan-out-and-synthesize

Split a task into independent parts, run agents separately, and merge the structured outputs.

Good for large source sets, codebase audits, research reports, or multi-file inspection.

Adversarial verification

Have one agent produce an answer and another agent challenge it against a rubric.

Good for technical claim checking, security review, or public writing where unsupported claims would be embarrassing.

Generate-and-filter

Generate many candidates, dedupe and filter them against a rubric, then keep only the best.

Good for demo ideas, course module ideas, naming, content angles, and prompt variations.

Tournament

Let agents compete on the same task, then use judging agents to compare results.

Good for taste-heavy work such as headlines, design directions, naming, or strategy choices.

Loop until done

Keep running until a real stop condition is met, not until an arbitrary number of passes is reached.

Good for flaky tests, log investigation, recurring issue mining, or "keep going until no new failure class appears."

My advice: do not stack every pattern into one prompt. Pick the smallest pattern that matches the task.

9. The Three Practical Patterns: Scout, Builder, Judge

The cleanest way to use Dynamic Workflows is to think in three patterns.

Scout

Scout agents explore independently.

They should not make final decisions. Their job is to inspect, summarize, and return structured findings.

Examples:

• inspect different folders in a repo;

• read different research sources;

• find repeated failure modes;

• list candidate files for migration.

The scout output should be a map, not a conclusion.

Builder

Builder agents act on scoped work packets.

They should receive clear boundaries:

• which files;

• which change;

• which output format;

• what not to touch;

• what validation to run.

This pattern works best after the scout phase narrows the surface area.

Judge

Judge agents review independently.

They should challenge the result:

• Is the claim supported?

• Did the edit exceed scope?

• Are tests missing?

• Is there a cheaper approach?

• Did any agent hallucinate a file, API, or conclusion?

The judge pattern is the one I like most because it turns "AI reviewing AI" into a concrete workflow with limits.

It does not guarantee correctness.

It does create friction against unchecked confidence.

10. Commands And Controls Worth Remembering

Here is the practical command layer I would keep in my notes.

The docs also list limits that matter:

• the workflow script coordinates agents, but the agents perform file, shell, and tool actions;

• no mid-run user input, so approval gates should happen between workflow stages;

• up to 16 concurrent agents;

• up to 1,000 agents total per run;

• higher token usage than normal turns.

This is why I would test on a small slice first. One folder before the whole repo. One narrow research question before the entire market.

11. A Practical Dynamic Workflow Prompt Template

Here is the kind of prompt I would use before letting an agent start a Dynamic Workflow.

Use a dynamic workflow only if this task truly benefits from parallel agents.

Token budget:
- Use at most [N] tokens unless I explicitly approve continuing.

Goal:
- [Write the specific outcome.]

Scope:
- Work only inside [project path].
- Do not modify unrelated files.
- Do not touch [explicit forbidden paths].
- Split the work into slow, auditable batches.

Pattern:
- Choose exactly one primary pattern:
  classify-and-act / fan-out-and-synthesize / adversarial verification /
  generate-and-filter / tournament / loop until done.

Workflow shape:
1. Scout agents inspect independent areas or sources.
2. Builder agents produce bounded changes or artifact sections.
3. Judge agents independently review scope, evidence, bugs, and missing validation.
4. The lead agent consolidates findings and reports decisions.

Stop if:
- The task requires editing outside scope.
- The source evidence is missing.
- Validation cannot run.
- Token or cost usage becomes disproportionate to the task value.
- The workflow starts spawning agents without a clear stop condition.

Validation:
- Run relevant build, test, lint, or content checks.
- Separate source evidence from inference.
- Produce a final summary with changed files, risks, and remaining questions.

Final report:
- Batches completed.
- Files changed.
- Checks run.
- Issues found.
- What still needs human review.

Notice what this prompt does.

It does not just say "use many agents."

It defines the operating boundary, the workflow shape, the stop conditions, and the validation loop.

That is what makes orchestration useful.

12. The Right Teaching Order

For learning Claude Code, I would not teach Dynamic Workflows first.

The right order is:

1. What an AI coding agent is.

2. How context, tools, and permissions work.

3. How to write a bounded goal.

4. How to use explore -> plan -> code -> review.

5. How to review diffs and run checks.

6. How subagents delegate roles.

7. How skills turn repeated workflows into contracts.

8. How Dynamic Workflows orchestrate large, parallel, reviewable work.

If someone skips straight to Dynamic Workflows, they may confuse complexity with capability.

The advanced feature only becomes useful after the basic discipline exists.

13. My Final Judgment

Dynamic Workflows are not a magic mode.

They are not a default accelerator.

They are not the right tool for every coding task.

They are an orchestration layer for work that is large enough, structured enough, and important enough to justify parallel agents and explicit coordination.

The practical question is not:

Can I use Dynamic Workflows here?

The better question is:

Would this task become clearer, safer, or more complete if several agents worked independently and then got reviewed?

If the answer is no, keep the task simple.

If the answer is yes, define the scope, budget, stop conditions, and validation before you start.

That is the difference between agent orchestration and expensive chaos.

References

• Introducing Dynamic Workflows in Claude Code

• A harness for every task: dynamic workflows in Claude Code

• Claude Code Dynamic Workflows docs

• Claude Code subagents docs

• Agent Skills spec

• AI_Brain source note: CLAUDECODE-20260530-001 - Claude Code Dynamic Workflows

• AI_Brain source note: CLAUDECODE-20260608-001 - A harness for every task Dynamic Workflows

• AI_Brain method: Claude Code Dynamic Workflows 使用判断法