Turning Multi‑Agent Orchestration into Reviewable Code with Claude Dynamic Workflows

Release overview

On 28 May Anthropic released Claude Opus 4.8 and introduced Dynamic Workflows in Claude Code. The announcement highlighted the ability to schedule hundreds of sub‑agents and cited a Bun migration case where ~750 k lines of Zig were rewritten to Rust, achieving 99.8 % test pass in 11 days.

Core engineering change

Agent orchestration moves from the chat context into a readable, auditable JavaScript script. Claude first generates a workflow script; the runtime then executes it, launching sub‑agents only at explicit agent() calls.

How Dynamic Workflows differ from existing primitives

Subagent : a single agent runs a task; plan lives in the main Claude context.

Skill : reusable operation manual stored in a separate file; plan lives in context + skill file.

Agent Teams : coordinated agents share state via lead + teammates; plan lives in shared state.

Dynamic Workflow : an executable JavaScript orchestration script; plan lives in the script and runtime, enabling parallelism, pipelines, loops, and explicit result aggregation.

Why the shift matters

When dozens or hundreds of agents run in parallel, keeping task splitting, file changes, evidence collection, conflict resolution, and stop conditions inside the conversation quickly exhausts context and attention. By moving the plan into code, teams obtain a concrete artifact that can be reviewed, version‑controlled, and reused.

Workflow execution model

The script can contain parallel, pipeline, loops, and conditional branches. The runtime executes the script step‑by‑step; only agent() invocations start a sub‑agent that performs code reads, command execution, or file edits. Intermediate results stay in script variables; only the final aggregated result is returned to Claude’s context.

Evidence collection pattern

One agent implements a change.

Two or more reviewer agents challenge the implementation from different angles.

Findings that survive verification proceed to the next stage.

A final build, test, or PR generation step runs.

This mirrors traditional engineering review but is expressed as explicit script stages, making the evidence package easier to audit.

Bun migration case study

Jarred Sumner used Dynamic Workflows to migrate the Bun runtime from Zig to Rust. The migration was broken into four work surfaces:

Lifetime mapping : a workflow stage handled struct field lifetimes before any code changes.

File‑level parallel migration : each .zig file was mapped to a corresponding .rs file; multiple agents processed files in parallel, each followed by a per‑file review.

Build‑and‑test driven fix loop : after initial translation, continuous compilation and testing surfaced defects, which were fixed in an iterative loop.

Long‑tail cleanup : an overnight workflow scanned unnecessary data copies and opened PRs for final human review.

The Rust codebase was not production‑ready at the time, illustrating that Dynamic Workflows can push a task far forward but “test‑passed”, “merge‑ready”, and “production‑ready” remain distinct milestones.

When Dynamic Workflows are appropriate

Full‑repo scans for auth checks, input validation, dangerous APIs, or duplicate logic.

Large‑scale migrations such as framework replacements, API deprecations, or language ports.

Code‑base inventory tasks (dead code, module boundaries, performance hotspots).

Adversarial, multi‑angle stress testing of high‑risk proposals.

Overnight long‑tail clean‑up that produces multiple PRs.

When they are not suitable

One‑ or two‑file tweaks.

Ill‑defined problems that require frequent human direction.

High‑risk actions (security, payment, data deletion) without pre‑written permission boundaries.

Budget‑sensitive tasks lacking token limits, stage splits, or stop conditions.

Attempts to “make the tool smarter” without clear acceptance evidence.

Runtime limits and cost

Dynamic Workflows is a research preview. Requirements and boundaries (as of Claude Code v2.1.154):

Enabled via /config for Pro plans; Enterprise users need admin activation.

Available on all paid Anthropic plans, the Anthropic API, Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry.

Scripts cannot directly access the file system or shell; all I/O and commands go through sub‑agents.

Maximum of 16 concurrent agents (lower on machines with few cores).

Maximum of 1 000 agents per run.

No mid‑run human input; only permission prompts can pause execution.

Paused runs can resume only within the same Claude Code session; a new session requires a fresh run.

Token consumption is noticeably higher because many agents run in parallel and each stage adds verification and cross‑validation overhead.

Activation commands

Two ways to start a workflow:

Explicitly ask Claude to create a workflow for a given task.

Use the shortcut /effort ultracode to let Claude automatically decide whether a workflow is needed (more token‑intensive).

Sample task card

请使用 workflow 处理这个任务。

目标：
扫描 src/api 下所有 endpoint，找出可能缺少认证或权限校验的位置。

工作面：
1. Inventory：列出所有 endpoint、文件路径、handler 名称。
2. Analyze：每个 endpoint 独立检查认证、权限、输入校验。
3. Verify：对每个发现安排两个 review agents，尝试反驳该发现。
4. Report：只保留通过验证的发现，输出文件、行号、证据、风险等级、建议修复方向。

权限：
- 只读代码和测试文件。
- 不修改文件。
- 不运行会改变状态的命令。
- 如果需要访问外部网络或敏感配置，先停止并说明原因。

停止条件：
- 找不到 endpoint 时停止。
- 发现权限不足时停止。
- 超出 src/api 范围时停止。

验收证据：
- 每条发现需要包含文件路径、相关函数、证据片段、为什么现有校验不足、反驳是否通过。
- 不确定的发现放到“需要人工复核”，不要写成已确认漏洞。

This example shows how to define work surfaces, permissions, stop conditions, and evidence requirements before the workflow runs.

Relation to the broader Claude Code runtime

Claude Code’s execution layer now comprises:

Context injection (CLAUDE.md, Rules, Commands, Hooks).

Process persistence (Skills, Worktrees).

Work‑surface isolation (Subagents, Agent Teams).

Multi‑agent collaboration.

Permission containment.

Evidence collection.

Long‑task continuation.

Failure recovery and replay.

Dynamic Workflows adds the orchestration piece, turning ad‑hoc, multi‑round scheduling into a stable script. The script itself is not intelligent; sub‑agents retain model intelligence for localized tasks. Together they approximate an engineering system capable of handling large‑scale tasks.

Key takeaways

Dynamic Workflows shifts planning from chat to code, providing a reviewable artifact.

It is valuable for tasks that can be split into many relatively independent units, each requiring verification.

Current limits (research preview) include concurrency caps, token cost, and no mid‑run human input.

Start with small, read‑only, low‑risk workflows to measure token usage, runtime duration, and report quality before scaling.

References

Anthropic release notes: https://www.anthropic.com/news/claude-opus-4-8

Claude blog introducing Dynamic Workflows: https://claude.com/blog/introducing-dynamic-workflows-in-claude-code

Claude Code documentation: https://code.claude.com/docs/en/workflows

Bun migration discussion (Jarred Sumner): https://digg.com/ai/rb5xj3bt

Cat Wu on workflow prompting: https://x.com/_catwu/status/2060054180379689074

Addy Osmani, Agent Harness Engineering: https://www.oreilly.com/radar/agent-harness-engineering/