Claude Code Dynamic Workflows: What Actually Changed
Straight up, this is the biggest change to how Claude Code runs a long job since subagents shipped. As of the research preview released the first week of June 2026, Claude Code can write its own harness for a task on the fly - a custom script built for that exact job - instead of grinding through it turn by turn in your main session. Anthropic laid it out in their own writeup, A harness for every task (https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code).
Here is the part that matters for anyone running client work. The default Claude Code harness was built for coding. It is good at a lot of things because a lot of tasks look like coding. But research, security review, large refactors, anything that fans out into dozens of parallel steps - those always wanted a custom harness. Dynamic workflows let Claude build that harness itself, then run it in the background while your session stays open for everything else.
I have spent fifteen years shipping inside teams at Apple, PlayStation and Schwab, and the pattern is always the same: the work that eats your week is the multi-step stuff a junior could run if someone wrote the runbook. This is the runbook, written by Claude, executed by Claude. That is the whole idea.
Turn Dynamic Workflows On in Two Minutes
On a paid plan, open /config and flip the row marked Dynamic workflows. That is the whole setup. On Pro it is off by default, so this one toggle is the gate.
Once it is on, you have two ways to trigger a workflow. The simplest is to just ask: put use a workflow or run a workflow in your prompt and Claude treats it as an opt-in. The deliberate way is the keyword ultracode - type it in your prompt and Claude writes a workflow script for the task instead of working through it live. One version note that will trip you up: before v2.1.160 the trigger word was literally workflow, so if ultracode does nothing, update your CLI.
Want every substantive task in a session to run as a workflow without thinking about it? Set /effort ultracode and Claude plans a harness for each meaningful job automatically. For an agency, that is the setting you leave on during a heavy build day.
Run Your First One: /deep-research
Do not write a workflow from scratch on day one. Claude Code ships with one already built so you can see the shape of the thing. Run /deep-research with a real question and watch what happens: agents work through a set of phases in the background, your session stays free the entire time, and instead of a turn-by-turn transcript you get one cited report at the end.
Open /workflows while it runs. That view is your control panel - you can watch each phase, pause, resume, and save the run. The first time you see several agents fanning out across sources while you keep typing in the same session, the model clicks. This is not a chat that happens to be long. It is a background job with a progress bar.
Turn-by-turn session vs a dynamic workflow
| What you care about | Default turn-by-turn | Dynamic workflow |
|---|---|---|
| Your session while it runs | Blocked until the task finishes | Free - the work runs in the background |
| How the work is structured | One long thread of context | Phases of subagents coordinated by a script |
| What you get at the end | A scrolling transcript | One synthesized, cited result |
| Repeatability | Re-prompt from memory each time | Saved as a command you rerun |
| Best fit | A single focused change | Research, audits, big multi-file builds |
The Primitives: phase, agent, pipeline, parallel
Under the hood a workflow is a JavaScript file with a handful of special functions. You do not have to hand-write it - Claude authors it for you - but knowing the four pieces helps you steer the prompt and read what it built.
- meta - an export that names the workflow, describes it, and lists its phases.
- phase("name") - a marker that segments the progress view, one row per phase in /workflows.
- agent(prompt, options) - launches one subagent. You pass it a label, an output schema, and which phase it belongs to.
- pipeline(items, stage1, stage2, ...) - staged processing that feeds each stage's output into the next.
- parallel([fn, fn, ...]) - runs an array of functions at the same time.
The reason to care: when you lock an agent's output to a JSON schema, the next phase can trust the shape of what it receives. That is what turns a flaky multi-step prompt into something you would put in front of a paying client. The full primitive reference lives in the Claude Code docs (https://code.claude.com/docs/en/workflows).
Save It, Reuse It, Sell It
Here is where this stops being a neat demo and starts being margin. Once you get a run you are happy with, open /workflows, select it, and press s to save. Save to .claude/workflows in the repo and your whole team gets it. Save to ~/.claude/workflows and it is yours across every project. Either way you now call it like any command, for example /article-fact-check or /onboarding-audit.
Two more moves worth your time. Pair a workflow with /goal to set a hard completion bar and /loop to rerun it on an interval - that combination is how you get triage and verification that runs without a human babysitting it. And you can ship a workflow inside a skill: drop the JavaScript files in the skill folder and reference them in the SKILL file, which is how you hand a client a repeatable system instead of a one-time result.
That last point is the business case. A one-off run is a service. A saved, shareable workflow is a product. The shops that figure out which of their repeatable jobs - audits, migrations, research briefs - can be frozen into a workflow and sold as a fixed deliverable are the ones who stop trading hours for money. We broke down that pricing shift in our writeup on Claude Code workflows that get you paid (/blog/5-claude-code-workflows-that-get-you-paid), and the logic applies directly here.
Frequently asked questions
What version of Claude Code do I need for dynamic workflows?
Claude Code v2.1.154 or later. They are a research preview available on every paid plan, plus the Anthropic API, Amazon Bedrock, Google Cloud Vertex AI and Microsoft Foundry. Run claude --version to check, and note that before v2.1.160 the trigger keyword was workflow rather than ultracode.
How do I turn dynamic workflows on?
Open /config and enable the Dynamic workflows row. On Pro plans it is off by default, so that toggle is the only setup step. After that, trigger a workflow by asking for one in plain language or by typing the keyword ultracode in your prompt.
Do I have to write the JavaScript myself?
No. You describe the task and Claude authors the workflow script for you, including the phases and subagents. Knowing the primitives - phase, agent, pipeline, parallel - just helps you write a sharper prompt and read what Claude produced.
What is the difference between a workflow and a subagent?
A subagent is a single delegated task. A dynamic workflow is the script that spawns and coordinates many subagents across phases, runs in the background, and returns one result. Think of the workflow as the runbook and the subagents as the people running it.
Can I reuse a workflow across projects or share it with my team?
Yes. In the /workflows view, select a run and press s to save it. Save to .claude/workflows for the whole team in a repo, or ~/.claude/workflows for just you across projects. You can also bundle workflows inside a skill to distribute them.
Is this worth it for client work specifically?
That is the strongest use case. The repeatable multi-step jobs an agency runs - audits, research, migrations - are exactly what workflows freeze into a single command. Save one, pair it with /goal and /loop, and you can sell a repeatable system as a fixed deliverable instead of billing hours. See more from Duncan on his author page.
Last reviewed by Duncan Rogoff on June 8, 2026
