ANTHROPIC

Claude Code Dynamic Workflows, Clearly Explained

Claude Code dynamic workflows, clearly explained: what actually changed on May 28, how they run, and when you’d reach for one.

Here is the whole thing in a sentence. The orchestration plan moves out of Claude’s context window and into a JavaScript script Claude writes on the fly.

A runtime then executes that script in the background while your main session stays free.

That single move is the feature. Normally Claude is the orchestrator, and every intermediate result piles back into its context until the run runs out of room.

When the plan lives in a script instead, that script holds the loop and the messy middle, so Claude’s context only ever sees the final, verified answer.

That is what makes a run of hundreds of agents possible, and it changes which jobs you can hand off.

Why One Agent Eventually Hits a Wall

A single agent has one context window, and that window is the binding constraint on any long autonomous run.

Every file it reads, every tool result it gets back, every reasoning step it takes, all of it accumulates in the same place.

For a quick task that ceiling never matters. For a codebase-wide audit or a large migration, you hit it well before the job is done, and the agent starts forgetting the early parts of its own plan.

You feel this on the jobs that genuinely need scale: hunt a bug across two hundred files, port a library module by module, stress-test one function from forty angles at once.

None of those fit in a single pass, no matter how patient you are.

The accumulation problem is also why throwing a bigger model at it doesn’t help much. More intelligence per step still funnels through one window, and the window fills at the same rate.

There’s a quieter version of the same failure, where the agent doesn’t run out of room but slowly loses the thread while dragging stale tool results behind it.

The output looks fine right up until it isn’t, and you only catch the drift when something downstream breaks.

So the real question was never how to make Claude think harder in one session, it was how to keep the plan somewhere that doesn’t fill up, and let many small workers do the reading.

How Claude Code Dynamic Workflows Actually Run

You describe the job in plain language, the same way you’d brief a person.

Claude reads it and writes an orchestration script in JavaScript, which is the plan turned into code you can actually inspect.

A background runtime then takes that script and fans the work out, spinning up anywhere from tens to a few hundred subagents.

Each one gets its own fresh context and its own narrow slice of the task, and they run in parallel, not one after another.

Then comes the part that earns the trust: the results get cross-checked adversarially, with separate agents reviewing the work rather than the original author grading its own homework.

Only after that review does one merged, verified result come back into your session, and the hundreds of intermediate steps never touch your context at all.

The adversarial review step is the quiet hero here, because a wide fan-out is only as good as the checking that follows it.

Without it you’d just have hundreds of confident answers and no way to know which ones to trust.

Because the plan is a saved script, you can rerun it later against a different input, which is closer to having a small program than a one-off chat.

That rerun property is also why a workflow can grow into something you keep around, rather than a clever trick you set up once and lose.

The Ladder, and the One Distinction That Sticks

The cleanest way to hold all of this is a ladder, where each rung adds power, cost, and risk. Most of the confusion around Claude Code dynamic workflows comes from skipping the rungs below it.

At the bottom you just ask Claude, one session doing its own reasoning.

Above that sits a skill, a reusable recipe that captures the how of a task you repeat.

Next is a subagent, a parallel worker with its own context that keeps your main session clean, though subagents can’t talk to each other and only report back up.

Then an agent team, a small crew that does talk, shares a task list, and carries individual roles.

Near the top is **/goal**, a loop that keeps going until an explicit done-criterion is true. A dynamic workflow sits beside it, fanning one plan out across many lone agents and merging once.

Here is the distinction worth memorizing. /goal is depth, the same objective hammered over many passes until it's satisfied, while a workflow is width, one plan spread across dozens of agents running at the same time.

You can even picture nesting them, a workflow that fans out with a /goal loop tightening one branch.

That's a lot of moving parts to trust at once, and worth earning before you try it.

A skill is the how. A workflow is the how many.

Get those two axes straight and the rest of the orchestration menu stops feeling like a pile of overlapping buzzwords.

How to Turn Claude Code Dynamic Workflows On

You need version 2.1.154 or later and a paid plan, since the feature is gated.

On a Pro plan you flip it on with a toggle inside /config, and from there it's available in normal use.

Two things will trigger a workflow.

Putting the word “workflow” into your prompt is one path, and choosing the ultracode effort setting is the other, both of which tell Claude to write the orchestration script rather than handle the job inline.

The fastest way to watch one run start to finish is /deep-research.

I pointed /deep-research at a real question I actually had, then sat back and watched it move through the phases, fan out, and pull a single answer back.

That first watch-through is worth more than any diagram, because you see the fan-out and the review happen in real time instead of taking my word for the shape of it.

One small habit makes the difference once you’re past the demo.

Say “set up a dynamic workflow to” instead of hoping the word “workflow” trips it on its own. Being explicit about the intent gives you a cleaner script and fewer surprises about what actually ran.

The Catch Nobody Tells You

Here’s the honest downside: token cost.

Every one of those subagents is a full model call with its own context to read, so a single large run can cost an order of magnitude more than a normal session.

This is exactly where the skeptics live, and they’re not wrong.

The sharpest version of the critique is that speed was never the bottleneck, correctness was, and a fair amount of the chatter is plain token-maxxing dressed up as progress while the real need is correctness-maxxing.

Conclusion

If your work is large migrations, codebase-wide audits, or stress tests that genuinely split into parallel pieces, Claude Code dynamic workflows is the rare feature that earns its keep.

The context-to-script shift removes the one ceiling that capped long runs.

If your work is single edits, greenfield CRUD, or anything resting on one judgment call, it’s overkill and the cost will tell you so.

So pick one real job that breaks into many independent parts, point /deep-research at a scoped version of it first, then watch the bill closely before you ever let it touch the big one...