Most agentic coding still runs through a single conversation. Claude reads, edits, runs a command, reads the output, and decides what to do next, one turn at a time. That loop is great until the task outgrows it. When you need to touch 500 files, audit every API endpoint in a service, or cross-check a research question against dozens of sources, a single context window becomes the bottleneck. Every intermediate result has to pass through it, and the orchestration logic lives only in Claude's head for the length of the session.
Dynamic workflows change that. Instead of working the task turn by turn, Claude writes an orchestration script for it and hands that script to a runtime, which executes it in the background across many subagents while your session stays free. It shipped as a research preview during the week of May 25–29, 2026, alongside Claude Opus 4.8, and it is one of the clearer signs that Claude Code is becoming an agentic runtime rather than a single assistant you chat with.
What a dynamic workflow actually is
A dynamic workflow is a JavaScript script that orchestrates subagents at scale. You describe a task, Claude writes the script, and a separate runtime runs it in an isolated environment outside your conversation. The script holds the loop, the branching, and the intermediate results. Claude's context window holds only the final answer.
The "dynamic" part is the important word. The number and type of subagents are not hardcoded. The orchestrator decides at runtime, based on the task, how to fan the work out. A 30-file change and a 600-file migration produce very different scripts from the same starting prompt.
It helps to put it next to the other ways Claude can run a multi-step task. The official docs frame the difference as who holds the plan:
| Subagents | Skills | Agent teams | Workflows | |
|---|---|---|---|---|
| What it is | A worker Claude spawns | Instructions Claude follows | A lead supervising peer sessions | A script the runtime executes |
| Who decides what runs next | Claude, turn by turn | Claude, following the prompt | The lead agent, turn by turn | The script |
| Where intermediate results live | Claude's context | Claude's context | A shared task list | Script variables |
| Scale | A few tasks per turn | Same as subagents | A handful of peers | Dozens to hundreds of agents per run |
| Interruption | Restarts the turn | Restarts the turn | Teammates keep running | Resumable in the same session |
Why it matters: fan-out beats one context
The single-context model has a hard ceiling. Pour the output of 200 file reads into one conversation and you blow the budget, the model loses the thread, and quality degrades long before the task is done. A workflow sidesteps this by keeping intermediate results in script variables. Only the synthesized result comes back.
But raw parallelism is not the whole story. Moving the plan into code lets a workflow apply a repeatable quality pattern, not just run more agents. The script can have independent agents adversarially review each other's findings before anything is reported, or draft a plan from several angles and weigh them against each other. That is why the built-in /deep-research workflow votes on each claim and filters out the ones that did not survive cross-checking. You get a more trustworthy result than a single pass, because disagreement is designed into the run.
Where and who: plans, requirements, status
Dynamic workflows are a research preview and require Claude Code v2.1.154 or later. They are available on all paid Claude plans, with Anthropic API access, and on Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry. Higher tiers like Max, Team, and Enterprise have them on by default; on Pro you turn them on from the Dynamic workflows row in /config. Organizations can disable them centrally with "disableWorkflows": true in managed settings.
The runtime applies two limits worth knowing before you launch a large run:
- Up to 16 concurrent agents (fewer on machines with limited CPU cores), to bound local resource use.
- 1,000 agents total per run, to prevent a runaway loop.
A few permission details matter for an MSP context. The subagents a workflow spawns always run in acceptEdits mode and inherit your tool allowlist, regardless of your session's permission mode. File edits are auto-approved, but shell commands, web fetches, and MCP tools that are not in your allowlist can still prompt you mid-run. On a long unattended run, add the commands the agents need to your allowlist first.
How to use it
There are three ways in:
# 1. One-off: ask for a workflow in your prompt
ultracode: audit every API endpoint under src/routes/ for missing auth checks
# 2. Plain language works too
> create a workflow that migrates every internal fetch() call to the new HttpClient wrapper
# 3. Let Claude decide for the whole session
/effort ultracode
The ultracode keyword turns a single prompt into a workflow without changing the session's effort level; Claude highlights it in your input and writes the script. /effort ultracode combines xhigh reasoning with automatic orchestration, so Claude plans a workflow for every substantive task until you drop back with /effort high. (Before v2.1.160 the literal trigger was workflow; natural-language requests work in both versions.)
Before a run starts, Claude Code shows the planned phases and asks for approval. You can view the raw script, tweak the prompt, or open the script in your editor first. Once running, manage everything from /workflows:
/workflows
That view lists running and completed workflows. Drill into a phase to see its agent count, token total, and elapsed time, then into any individual agent to read its prompt, recent tool calls, and result. You can pause and resume (p), stop a single agent or the whole run (x), restart an agent (r), or save the run's script as a reusable command (s).
A concrete large task
Say you want to migrate every internal fetch() call in a large service to a new HttpClient wrapper. As a conversation, that is hundreds of edits dragging context through one window. As a workflow, Claude writes a script that fans out a discovery phase to find every call site, spawns a band of agents to perform the edits in parallel, and runs a verification phase where independent agents check the migrated code. Completed agents cache their results, so if you pause the run, resuming replays the cache and only the unfinished work runs live. Note that resume works within the same session — exit Claude Code while a workflow is running and the next session starts it fresh.
How it relates to nested subagents
Don't confuse dynamic workflows with nested subagents, a related capability that landed around the same time. Nested subagents let a subagent spawn its own subagents, up to five levels deep, so deep delegation chains can push noisy work further from the conversation you care about. Workflows are about script-driven fan-out at scale; nested subagents are about managing context in depth. They solve different problems and can be used together. If you are building your own orchestration outside Claude Code, the same primitives are exposed through the Claude Agent SDK.
The bottom line
Dynamic workflows are the answer to a real limit: a single conversation can only coordinate so much before its context window becomes the bottleneck. By having Claude write an orchestration script and run it across up to 1,000 subagents in the background, Claude Code can take on codebase-scale audits, migrations, and cross-checked research that were impractical turn by turn — and the resulting script is readable, savable, and rerunnable. It is still a research preview, so treat early runs with the same caution you would any new automation: scope them small, watch the token spend in /workflows, and lock down your tool allowlist before you walk away. For verifiable end-states inside a normal session, the /goal command remains the lighter-weight tool; reach for a workflow when the task genuinely outgrows one context.