Claude Code Dynamic Workflows: Run Hundreds of AI Agents in Parallel
Introduction
What if you could hand Claude a task that normally takes your team a quarter to finish — and get it done in days? That is the promise behind dynamic workflows, the most significant Claude Code feature to ship in 2026 so far. Now generally available across the CLI, Desktop app, and VS Code extension, dynamic workflows let Claude write its own orchestration scripts, spin up tens to hundreds of parallel subagents, verify its own output through adversarial checking, and deliver a single coordinated result back to your session.
This is not incremental improvement. It is a fundamentally different way of using Claude for engineering work. In this guide, we will break down exactly how dynamic workflows operate, when they shine, what to watch out for, and how to start using them today.
What Are Dynamic Workflows?
At their core, dynamic workflows are JavaScript orchestration scripts that Claude writes on the fly to coordinate parallel subagent execution. Instead of Claude handling your request in a single linear pass — reading files one at a time, making changes sequentially — a dynamic workflow decomposes your task into independent subtasks and fans them out across many agents running simultaneously.
Think of it as the difference between one developer working through a backlog alone versus a well-coordinated team of dozens tackling every piece at once, with a lead engineer reviewing and reconciling everything before handing it back to you.
The key distinction from previous Claude Code capabilities like simple subagent spawning is the planning and verification layer. Claude does not just split work arbitrarily. It analyzes your prompt, designs a multi-phase execution plan, determines dependencies between phases, and builds in adversarial verification steps where independent agents try to break or refute findings before they reach you.
How Dynamic Workflows Actually Operate
Understanding the mechanics helps you get much better results. A dynamic workflow unfolds in three distinct phases.
Phase 1: Planning
When you trigger a workflow, Claude first analyzes your request and writes a JavaScript orchestration script. This script encodes the full execution plan: which phases exist, how many agents run in each phase, whether items flow in parallel or through a pipeline, and what verification logic runs before returning results. You see the plan before it executes and can approve or adjust it.
The critical insight here is that Claude is not following a rigid template. The plan is generated dynamically based on the specific shape of your task. A security audit produces a very different orchestration script than a framework migration, even though both use the same underlying workflow engine.
Phase 2: Parallel Execution
Once approved, the workflow runtime runs the script in a background process. Subagents do the actual work — reading files, running shell commands, making web requests, calling MCP tools. Each agent call returns its result as a JavaScript value, and those values accumulate in script variables rather than in Claude's context window.
This is an important architectural detail. Because intermediate results live in script variables, not in the conversation context, the workflow can scale to hundreds of agents without hitting context limits. Your session stays responsive while potentially massive computation happens in the background. Progress is saved incrementally, so if a run gets interrupted, it picks up where it left off rather than starting over.
Phase 3: Verification and Convergence
This is where dynamic workflows really differentiate themselves. Results are not simply collected and returned. Instead, independent agents address the problem from different angles, other agents actively try to refute what was found, and the run keeps iterating until answers converge. Only then does the verified, reconciled result come back to you.
For high-stakes work — production migrations, security audits, architectural decisions — this adversarial verification layer is what makes the difference between a rough draft you need to manually validate and a result you can trust.
Real-World Use Cases That Showcase the Power
The Bun Rewrite: 750,000 Lines in Eleven Days
The most dramatic example of dynamic workflows in action is the Bun runtime rewrite. Jarred Sumner used dynamic workflows to port Bun from Zig to Rust, producing roughly 750,000 lines of Rust with 99.8 percent of the existing test suite passing — in eleven days from first commit to merge.
The process used multiple chained workflows. One workflow mapped the correct Rust lifetime annotations for every struct field in the Zig codebase. The next wrote every Rust file as a behavior-identical port of its Zig counterpart, with hundreds of agents working in parallel and two reviewer agents on each file. A fix loop then drove the build and test suite until both ran clean. After the port landed, an overnight workflow identified unnecessary data copies and opened a pull request for each one.
While not yet in production, this demonstrates the scale of work dynamic workflows can handle — tasks that would traditionally require a team of engineers working for months.
Codebase-Wide Bug Hunts and Security Audits
Dynamic workflows excel at comprehensive codebase analysis. Claude searches an entire service or repository in parallel, with independent verification on every finding, so the final report surfaces real issues rather than false positives. The same pattern works for security hardening: auth checks, input validation, and unsafe patterns across an entire codebase, all verified before they reach you.
Klarna's engineering team has reported strong results using dynamic workflows for discovery and review tasks across large codebases, particularly for identifying dead code and surfacing cleanup opportunities that traditional static analysis missed.
Large Migrations and Modernization
Framework swaps, API deprecations, and language ports that span thousands of files are natural fits for dynamic workflows. The parallel execution handles the breadth, while the verification layer ensures consistency across the changes. What makes this particularly powerful is that Claude can run the build and test suite as part of the workflow, iterating on fixes until everything passes.
Cross-Checked Critical Work
When the cost of a wrong answer is high, dynamic workflows give Claude multiple independent attempts at the problem. Adversarial agents work to break the result before you see it. This is invaluable for architectural decisions, performance optimization recommendations, or any analysis where confidence matters.
How to Get Started
Dynamic workflows are available on Pro, Max, Team, and Enterprise plans, as well as through the Claude API on Amazon Bedrock, Vertex AI, and Microsoft Foundry.
There are two ways to trigger a workflow. The first is explicit: simply ask Claude to create a dynamic workflow for your task. Be specific about what you want accomplished, and Claude will generate and present the orchestration plan for your approval.
The second approach uses the ultracode setting, accessible through the effort menu in Claude Code. When enabled, ultracode sets the effort level to extra-high and lets Claude decide automatically when a workflow is the right tool for your task. This is the recommended approach for experienced users who want Claude to make the call on when parallel orchestration will help.
For the best experience, Anthropic recommends turning on auto mode when using dynamic workflows. This gives Claude the permissions it needs to execute the multi-step plans without requiring approval at every intermediate step.
Pro plan users need to explicitly enable dynamic workflows in the configuration settings using the slash config command. For Max, Team, and Enterprise plans, they are enabled by default. Organization admins can manage availability through managed settings.
What to Watch Out For
Token Consumption
This is the most important caveat. Dynamic workflows consume meaningfully more tokens than a typical Claude Code session. Running hundreds of parallel agents, each doing file reads, shell commands, and verification passes, adds up fast. Anthropic recommends starting with a scoped task to get a feel for usage before running large-scale workflows.
The first time a workflow triggers, Claude Code shows you what is about to run and asks for confirmation. This is your chance to review the scope and make sure the plan matches your expectations before committing the resources.
Task Scoping
Dynamic workflows are not the right tool for every task. They shine when work is naturally parallelizable — many files to analyze, many components to migrate, many angles to investigate. For sequential, deeply contextual work where each step depends heavily on the previous one, a standard Claude Code session may be more efficient.
The general rule: use a dynamic workflow when stage N's output determines stage N+1, and when you need to route, score, filter, loop, retry, generate, verify, or build across many items simultaneously.
Verification Is Not Infallible
While the adversarial verification layer significantly improves result quality, it is not a substitute for human review on critical changes. Treat workflow output the way you would treat a thorough pull request from a capable colleague — review the key decisions and spot-check the details, but you should not need to redo the work from scratch.
Tips for Getting the Best Results
Be specific in your prompts. The quality of the orchestration plan directly depends on how well Claude understands your goal. Instead of asking Claude to "fix all the bugs," specify the category of issues you care about, the scope of the codebase to examine, and what a successful outcome looks like.
Start small, then scale up. Run your first workflow on a contained subtask — a single service, a specific module, one category of migration — before pointing it at your entire monorepo. This helps you calibrate both the quality of results and the token cost.
Use ultracode mode for recurring workflows. Once you are comfortable with how dynamic workflows behave, enabling ultracode lets Claude decide when orchestration will help. This avoids the overhead of manually requesting workflows for every task.
Leverage headless mode for large runs. For workflows you expect to run for hours, the headless mode (claude -p) combined with scoped prompts and max-turns limits gives you fine-grained control over long-running executions.
Review the plan before execution. Claude presents the orchestration plan before running it. Take a moment to verify the number of phases, the parallelism level, and the verification strategy match your expectations. Adjusting the plan upfront is much cheaper than rerunning an entire workflow.
The Bigger Picture
Dynamic workflows represent a shift in what AI-assisted development means. We are moving from a model where Claude helps with individual tasks — write this function, review this PR, explain this error — to one where Claude can own entire engineering initiatives end-to-end. The Bun rewrite is an extreme example, but the everyday reality is just as compelling: security audits that would take a team a week, migrations that would take a sprint, analysis that would take days of manual review — all completed in a single session.
The key enabler is not raw model capability but the orchestration layer. By letting Claude plan, parallelize, verify, and iterate, dynamic workflows unlock a class of work that was simply impractical for a single agent pass.
For Claude power users who want to stay on top of how their usage scales with features like dynamic workflows, tools like Gaugr can help you monitor token consumption and track usage patterns across models in real-time.