What Are Claude Code Dynamic Workflows? Moving Plans into Code and Running Subagents in Parallel¶
For / Key Points
For: Engineers using Claude Code in real projects who need to decide when to use subagents, Skills, agent teams, or Dynamic Workflows.
Key Points:
- Dynamic Workflows let Claude generate JavaScript that coordinates many subagents in parallel
- The core difference is that the plan and intermediate state live in the script, not in Claude's context window
- They are powerful for large audits and migrations, but token usage, permissions, and resume limits need upfront design
Repository-wide bug hunts, hundreds of file migrations, adversarial review of a design proposal. These are exactly the tasks where conversational orchestration starts dropping details.
The question in this article is when to move from ordinary subagents to Dynamic Workflows. The short answer: when the plan itself needs to become an executable asset.
Code Holds the Plan¶
With Dynamic Workflows, Claude generates a JavaScript orchestration script for the task. Claude Code's dedicated runtime executes that script in the background and launches subagents in parallel1.
The loop is straightforward. Claude writes the script. The runtime executes it. Subagents divide the investigation, edits, or verification. Only the integrated result returns to the conversation.
The value is not just speed. Loops, branches, target lists, and intermediate results stay in script variables, so Claude's main context window is less likely to fill up with every partial result. Steps such as "check all 50 items" or "have a separate agent try to disprove each finding" become code that can be inspected rather than momentum in a chat thread.
How This Differs from Subagents¶
The key difference is who decides the next step and where intermediate results live1.
| Approach | Who decides the next step | Where intermediate results live |
|---|---|---|
| Subagents | Main Claude session | Claude's context window |
| Skills | Main Claude session | Claude's context window |
| Agent teams | Lead agent | Shared task list |
| Dynamic Workflows | JavaScript script | Script variables |
With ordinary subagents, Claude decides turn by turn which agent to call and what to ask. With a Workflow, much of that control moves into the script. The workflow becomes something you can read, modify, rerun, and save.
That distinction matters. Scripted execution makes it easier to see whether every item was processed, but it does not prove that the final synthesis is correct. Correctness still needs separate tests, specifications, and review criteria.
Where Workflows Help¶
Anthropic describes three major use cases for Dynamic Workflows2.
- Codebase-wide audits: authentication gaps, input validation, security boundaries, and performance regressions across many files
- Large migrations: framework swaps, deprecated API cleanup, language ports, and other changes that span many files
- High-stakes double checks: independent attempts combined with adversarial agents that try to break the conclusion
The most visible example is Bun's port from Zig to Rust. Anthropic says Jarred Sumner used Dynamic Workflows to produce roughly 750,000 lines of Rust, pass 99.8% of existing tests, and go from first commit to merge in 11 days2.
That example is impressive, but Anthropic also notes it was not yet in production. The lesson is not that workflows remove quality gates. It is that orchestration and verification need to scale together.
Three Ways to Start¶
The simplest entry point is the built-in /deep-research workflow. It investigates a question from multiple angles, cross-checks sources, and returns a cited report.
/deep-research What changed in Node.js permission model between v20 and v22?
To run your own task as a workflow, include ultracode in the prompt or ask for a workflow in natural language. That request can be handled as a workflow for this one run.
ultracode: audit every API endpoint under src/routes for missing authentication checks
For a whole session, set /effort ultracode. This raises reasoning effort and lets Claude decide when a task should become a workflow. You can inspect running workflows with /workflows, and successful runs can be saved under .claude/workflows/ for reuse1.
Costs and Limits to Check First¶
The biggest operational issue is token usage. Workflows can launch many subagents, so they can consume far more usage and rate limit budget than a normal conversation. The official docs recommend starting with a narrow scope first1.
The runtime limits are also important.
- Maximum concurrent execution is 16 agents, or fewer on machines with fewer CPU cores
- A single workflow run can launch up to 1,000 agents
- Workflows cannot accept user input mid-run, so approval checkpoints should be split into separate workflow stages
- Resume works only within the same session; quitting Claude Code means starting over
Availability matters too.
- Dynamic Workflows require Claude Code v2.1.154 or later
- They are available on Pro, Max, Team, Enterprise, API, Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry1
- They are enabled by default on Max, Team, Enterprise, and API, while Pro users enable them from
/config - Admins can disable the feature in managed settings
Permissions deserve the same attention. Workflow-launched subagents always run in acceptEdits mode1. File edits are automatically approved, while shell commands and MCP tools outside the allowlist may still request confirmation. For long runs, define the allowed commands and file scope before starting.
Summary¶
Dynamic Workflows are not mainly about adding more agents. They turn orchestration from a chat-time judgment into code that can be read, rerun, reviewed, and versioned.
That makes them especially useful in larger organizations. Scripts saved under .claude/workflows/ can become reviewed assets. Branch audits and migration checks can move from tribal procedure to executable workflow.
But workflows do not own the definition of correctness. Humans still need to provide tests, specifications, and review criteria. Used that way, Dynamic Workflows are less a "go faster" button and more a mechanism for parallelizing large work while reducing omissions.