Claude Dynamic Workflows in Practice: Parallel Subagents at Scale

May 31, 2026 Updated Jun 22, 2026

Shiori

Introduction

Anthropic announced Dynamic Workflows on May 28, 2026. The feature lets Claude Code create orchestration scripts and distribute work across many subagents. It moved to general availability after the announcement and, as of June 14, 2026, is available in the Claude Code CLI, Desktop, VS Code extension, Claude API, and other supported platforms.[1]

In an official example, a workflow helped port Bun from Zig to Rust, producing roughly 750,000 lines of Rust and reaching a state where 99.8% of the existing tests passed in eleven days.[1] This article focuses not only on that scale, but also on the task structures that make workflows effective.

This article covers the feature specification, suitable task structures, and constraints. I keep the concrete code-review application in Running Code Reviews in Parallel with Subagents.

What Dynamic Workflows are

Dynamic Workflows are a Claude Code mechanism that generates a JavaScript workflow to decompose a task, run multiple subagents in parallel, and verify and combine their results.

In a normal conversation, Claude manages tool calls and intermediate results through the conversation context. A dynamic workflow runs orchestration in a separate environment and keeps intermediate results in script variables.[2]

How they differ from a normal conversation

Item	Normal Claude Code conversation	Dynamic Workflows
Processing	Proceeds sequentially in the conversation	Coordinates multiple agents in parallel
Intermediate results	Often enter conversation context	Stay in workflow variables
Suitable scale	Small to medium tasks	Large investigations, migrations, and verification
Pause and resume	Resumes from session history	Reuses completed results within the same session
Cost	Standard session usage	Usually higher because multiple agents run

How the architecture works

1. Orchestration through a JavaScript script

When the user requests a workflow, Claude divides the task into phases and generates a JavaScript script. The user can review the planned phases before execution and open the raw script in the CLI.[2]

User describes the task
      ↓
Claude generates a workflow script
      ↓
User reviews the plan and starts the run
      ↓
Subagents work in parallel
      ↓
Results are verified and combined
      ↓
The final result returns to the conversation

Because intermediate results can remain in the script instead of being pasted into the conversation one by one, large exploration outputs are easier to manage.

2. Parallel execution limits

The official documentation allows up to 16 concurrent agents and 1,000 total agents in one workflow run. Machines with fewer CPU resources may run fewer than 16 concurrently.[2]

Reaching the limit is not the goal. The important design choice is to create only the independent work units and verification agents the task requires.

3. Independent attempts and verification

Dynamic Workflows can assign a problem to agents working from independent angles and then use other agents to challenge or verify the results.[1]

Agent A investigates the problem
Agent B investigates using a different hypothesis
A verification agent checks both results
The orchestrator combines the findings

This structure is useful for codebase-wide bug hunts and security audits, where the cost of missing an issue is high.

4. Resume behavior within one session

A stopped workflow can resume within the same Claude Code session. Results from completed agents are reused, and only unfinished work runs again. If Claude Code exits, the workflow starts fresh in the next session.[2]

For long-running work, check completion state before ending the session.

Official example: porting Bun from Zig to Rust

Anthropic’s official blog describes how Bun creator Jarred Sumner used Dynamic Workflows to port Bun from Zig to Rust.[1]

Project summary

Task: Port Bun’s core from Zig to Rust
Output: Roughly 750,000 lines of Rust
Duration: Eleven days from first commit to merge
Tests: 99.8% of the existing test suite passed
Status: Not yet in production when the official article was published

How the work was divided

According to the official article, the workflows separated the work as follows.[1]

Map an appropriate Rust lifetime for each struct field in the Zig codebase
Create a corresponding .rs file for each .zig file in parallel
Assign two reviewers to each file
Run a fix loop until the build and tests passed
Investigate unnecessary data copies after the port and open corrective pull requests

The important property is that files could be processed independently and results could be checked with tests. A task of similar size is not automatically suitable if it cannot be divided or verified.

Tasks that fit and tasks that do not

Tasks that fit Dynamic Workflows:

Large code investigations: Search for bugs, security issues, or dead code in parallel
Migration and modernization: Apply consistent changes across many independent files
Multi-perspective review: Combine independent hypotheses and adversarial checks
Test expansion: Separate test generation and verification by target
Independent document processing: Transform many files under the same quality criteria

Tasks where another approach is preferable:

Strong sequential dependencies: One decision substantially changes the next stage
Edits concentrated in one file: Parallel changes are likely to conflict
Small fixes: Workflow generation and coordination cost more than the task
Work requiring user decisions mid-run: A workflow cannot accept normal user input during execution

How to describe an effective task

A workflow request should define the target scope, the independent unit of work, and the verification method.

Improve this:
Improve this codebase.

Recommended:
For each Python file under src/, run these steps independently:
1. Add type hints where they can be inferred
2. Add Google-style docstrings
3. Remove unused imports

After each file changes, run mypy --strict and repair only the failing files.
Finally, assign a separate agent to review the changes and type-check results.

When the request explains what can run in parallel and what counts as complete, Claude can design phases and verification roles more effectively.

Cost and operational limits

Dynamic Workflows use more tokens than a normal Claude Code session. The official material recommends starting with one directory or a narrowly scoped question.[1][2]

Run a small scope and inspect the agent count and token usage
Monitor each agent’s progress and usage in /workflows
Stop unnecessary work and reuse completed results
Save repeatable processes as reusable workflows

The workflow script itself does not directly access the filesystem or shell. Subagents perform reads, writes, and command execution. Normal user input is unavailable during a run, so stages that require human approval should be separate workflows.[2]

Conclusion

The main characteristics of Dynamic Workflows are:

Parallelization: Distribute independent work across multiple subagents
Context separation: Keep intermediate results in the workflow runtime
Verification: Combine independent attempts with adversarial checks
Scale: Run up to 16 agents concurrently and 1,000 in total
Resume behavior: Reuse completed results within the same session

Effectiveness depends less on the number of agents than on whether the task can be divided into independent units and checked automatically. Start with a narrow scope, measure usage and results, and save only repeatable processes as reusable workflows.

References

Anthropic, Introducing dynamic workflows in Claude Code, May 28, 2026
Anthropic, Orchestrate subagents at scale with dynamic workflows, Claude Code Docs