Claude Code Dynamic Workflows: Orchestrating Hundreds of AI Agents in Parallel

Anthropic launched dynamic workflows in Claude Code on May 28, 2026, with Claude Opus 4.8. The idea: instead of a single agent processing a task linearly, Claude generates an orchestration plan and deploys dozens to hundreds of sub-agents in parallel within the same session, with adversarial agents assigned to verify and challenge results before they are accepted. This is a capability with no real precedent in mainstream AI coding tools. What it concretely changes for an engineering team, how the mechanism works, when it is useful, and when it is overkill: a pragmatic breakdown.

What dynamic workflows actually are

Before dynamic workflows, Claude Code operated as a single agent: it received an instruction, used tools (file read/write, command execution, API calls), progressed step by step, and returned to the user for validation or clarification. Useful, but structurally linear.

Dynamic workflows break that linearity. Claude no longer works alone, one step at a time: it first plans an orchestration architecture, then delegates sub-tasks to dozens or even hundreds of agents that run in parallel within the same session. Each agent has a precise scope, works independently of the others, and has its results submitted to adversarial verification agents before being integrated.

As Ken Takao, Lead Systems Engineer at Anthropic, put it: dynamic workflows fill the gap between launching a single sub-agent and building a full agent team. That gap was, until now, the primary bottleneck for handling truly large-scale engineering tasks.

To understand how this differs from conventional workflow tooling such as what teams build in n8n or Make, see our article on workflow vs AI agent: when to use which, which draws the foundational distinction.

How the orchestration works in practice

A dynamic workflow always follows the same four-stage loop.

Stage 1: plan generation

Claude analyzes the requested task and produces an explicit orchestration plan: which sub-tasks, what execution order or parallelization, which dependencies exist between outputs. This plan is visible to the user before execution when manual activation is chosen.

Stage 2: parallel sub-agent deployment

Sub-agents are launched simultaneously within the same session. Each has a targeted context, tools matched to its sub-task, and a precise objective. Coordination happens outside the main conversation thread: the user is not flooded with intermediate exchanges. Progress is saved continuously, allowing the session to resume after an interruption without starting over.

Stage 3: adversarial verification

Independent agents receive the results and have an explicit mandate to refute or validate them: find errors, test edge cases, detect regressions. This is the red-teaming principle applied to agent orchestration. If a result is rejected, the loop restarts on the relevant sub-task.

Stage 4: convergence and delivery

The system iterates until all sub-tasks pass adversarial validation. Claude then delivers a consolidated result, with a progress report if the task was long. Tasks spanning several hours or days benefit from automatic resumption.

This mechanism mirrors what engineering teams structure manually through code reviews, CI/CD pipelines, and automated tests. The difference: the entire cycle runs inside a Claude Code session, with no additional tooling to configure.

For a deeper look at how multi-agent systems are structured more broadly, see our multi-agent orchestration comparison, which covers the main frameworks and their trade-offs.

How to enable and configure dynamic workflows

Two activation modes are available.

Explicit mode: you ask Claude directly to create a workflow for the task. For example: "Create a workflow to migrate all v1 API calls to v2 across the repository." Claude presents its plan and waits for your confirmation before launching agents. This is the recommended mode for getting familiar with the feature and keeping control over what gets executed.

Ultracode mode (effort xhigh): by activating the ultracode setting in Claude Code, you let Claude judge on its own when a task warrants a workflow. It can then autonomously decide to deploy parallel agents if a task exceeds a certain complexity threshold. Convenient for advanced users, but it increases token consumption in a non-deterministic way.

Dynamic workflows work across the entire Claude Code ecosystem: CLI, Desktop application, VS Code extension, direct Claude API, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry. No environment switch is needed regardless of which platform you already use.

Enterprise use cases: what they are built for

Dynamic workflows are not an enhanced general-purpose AI assistant. They are designed for a specific class of tasks: high volume, parallelizable, with an error risk that justifies independent verification.

Large-scale code migrations

This is the most direct use case. Changing frameworks on a codebase of tens of thousands of lines, porting a service from one language version to another, updating hundreds of calls to a deprecated API: all of these tasks are repetitive, parallelizable by file or module, and critical (a migration error can go undetected for months).

With a workflow, Claude first maps dependencies, generates transformations in parallel, and submits each modified file to cross-validation before integrating it. Work that would take a team weeks of manual review can be scoped and executed in days.

Large-scale repository audits

Alessio Vallero, Senior Engineering Manager at Klarna, put it directly: dynamic workflows are very useful for discovery and review on large codebases, and help engineers move faster on maintenance and refactoring.

In practice: security audits across an entire repository (exposed secrets, potential injections, vulnerable dependencies), systematic bug hunting with cross-verification, dead-code detection on voluminous historical codebases. These are tasks where a single agent hits its context limits, and where a human team cannot work exhaustively without dedicated tooling.

For structured approaches to securing AI-adjacent workloads, see our article on EU AI Act compliance, which covers governance frameworks relevant to any engineering team deploying agentic systems.

Critical work requiring adversarial verification

Some tasks cannot settle for "probably correct." A language port going to production, a database architecture overhaul, a cryptographic library swap: errors carry serious consequences, and results must be verified independently, not just re-read by the same agent that produced them.

That is precisely the role of adversarial agents in a dynamic workflow: they have no access to the first agent's reasoning, they start from the output and attempt to break it. This is a form of separation of concerns applied to AI.

For the broader reasoning behind multi-agent design patterns, our article on AI agents vs chatbots covers the fundamentals useful for any engineering or product leader.

The Bun example: 750,000 lines of Rust in eleven days

The reference example published by Anthropic at launch is the migration of Bun (a high-performance JavaScript runtime) from Zig to Rust, carried out by Jarred Sumner using dynamic workflows.

The published figures:

• Approximately 750,000 lines of Rust generated
• 99.8% compatibility with the existing test suite
• First commit to merge: eleven days

The project used several successive parallel workflows, each with a precise objective:

• A workflow mapping Rust lifetimes (the language's memory management model)
• A workflow generating .rs files with independent reviewers on each module
• A continuous correction loop on build errors and failing tests
• An overnight optimization workflow launched during off-peak hours

What this example mostly demonstrates: the value of dynamic workflows is not in the raw speed of code generation, but in the ability to maintain coherence and catch errors at the scale of the entire project, not file by file.

Real token cost: what to plan for

Anthropic is explicit on this point and it would be misleading to downplay it: dynamic workflows consume far more tokens than a standard session. Launching dozens to hundreds of agents in parallel means that many contexts initialized, that many reasoning threads started, and that many results exchanged between agents.

A few reference points for calibration:

• A standard Claude Code session on a targeted refactoring task: a few thousand to a few tens of thousands of tokens.
• A dynamic workflow on a mid-size repository audit: several million tokens depending on repository size and agent count.
• A large-scale migration workflow running over several days: potentially tens of millions of tokens.

At Opus 4.8 pricing ($5 per million input tokens, $25 per million output tokens), a multi-million-token workflow amounts to roughly $100 to several hundred dollars depending on volume. Not negligible, but to be compared against the cost of one or more engineer-weeks on the same task.

Anthropic's recommendation is clear: start with well-scoped tasks and measure consumption before scaling up. The ultracode mode in particular can trigger unexpected workflows on tasks you considered simple.

For a fuller picture of how token costs fit into a complete AI project budget, see our guide on the cost of an internal AI assistant and our breakdown of RAG project total cost of ownership.

Justified or overkill: the decision grid

Dynamic workflows are not the right answer to every engineering problem. Here is the grid for deciding whether the feature fits your situation.

The clearest signal: if your task can be broken down into identical, parallelizable sub-tasks at scale, and if an error in one sub-task carries serious consequences, dynamic workflows are in their zone of value. If the task is one-off, modest in size, or does not require adversarial verification, a standard session or a classic agent will be faster and cheaper.

For typical enterprise AI use cases (document assistant, data processing, process automation), RAG remains the most direct and controllable path. Our article on agentic RAG explains why retrieval-augmented architectures are often sufficient before reaching for full multi-agent orchestration.

If you are evaluating multiple model and architecture options before deciding, our guide to Mistral vs OpenAI vs Anthropic provides a practical comparison across the main providers. And for structured outputs that tie agent results together cleanly, see our article on structured outputs for LLMs in production.

Dynamic workflows sit within the broader trajectory of Opus 4.8, whose agentic capabilities (69.2% on SWE-Bench Pro) and multi-level effort architecture form the foundation. For the full model portrait, see Claude Opus 4.8 for enterprise, which covers benchmarks, fast mode, and effort levels in full.

Finally, if you want to understand how Model Context Protocol fits into these agentic setups, our Model Context Protocol guide covers how tool exposure and context boundaries work across agent sessions.

Frequently asked questions

---

Further reading

• Claude Opus 4.8 for enterprise: the full model portrait covering dynamic workflows, benchmarks, fast mode, and effort levels.
• Workflow vs AI agent: when to use which: the foundational distinction between deterministic orchestration and agentic autonomy.
• AI agents vs chatbots: the orchestration logic behind agents, useful for any business leader before committing to a build.
• Multi-agent orchestration comparison: frameworks, trade-offs, and patterns for coordinating agents in parallel.
• Agentic RAG: the architecture best suited for document-centric enterprise use cases before reaching for dynamic workflows.
• Model Context Protocol guide: how tool exposure and context boundaries work in multi-agent Claude sessions.
• Structured outputs for LLMs in production: how to make agent outputs deterministic and composable across a workflow.
• Internal AI assistant cost: to place the token bill for dynamic workflows inside a full project budget.