Claude Code Dynamic Workflows：把编排逻辑搬进代码的新原语

When a task is too big to fit in a single conversation, let Claude write the orchestration as a script.

On May 28, Anthropic released Claude Opus 4.8, alongside a new feature—Dynamic Workflows.

First, a number: 11 days, ~750,000 lines of Rust, 99.8% of existing tests passing. This is the report card delivered by Bun creator Jarred Sumner after migrating the entire Bun runtime from Zig to Rust, and the main force behind this migration was Dynamic Workflows.

Released as a research preview, it targets jobs that a single agent cannot finish in one run. The official blog post describes it like this:

Some problems are too big for one pass by a single agent, especially in complex, legacy codebases: a bug hunt across an entire service, a migration that touches hundreds of files, a plan you want stress-tested from every angle before you commit to it.

Bug hunts spanning an entire service, migrations that touch hundreds of files, a plan that needs to be scrutinized from every angle before you dare commit—the common thread is that the scale exceeds what a single conversation can coordinate. The answer Dynamic Workflows provides is to have Claude write the orchestration process as an executable script.

To understand where Workflow fits, it helps to review the collaboration layers already present in Claude Code.

At the bottom is a single session: one agent instance works serially from start to finish. One level up are subagents—the main agent spawns several helpers to search files, read code, run commands, and report the results back. Higher still are Agent Teams, launched earlier this year, where multiple independent Claude Code instances collaborate in parallel like a team, and the members can communicate with each other.

These layers share a bottleneck: the orchestrator is always Claude itself. It decides turn by turn what to spawn next, and every subagent’s result must first land in Claude’s context window before it can plan the next move. This mechanism is flexible for modest workloads, but when you need to coordinate dozens or hundreds of parallel tasks, problems arise: the context window cannot hold that many intermediate results, and Claude’s attention gets diluted by a flood of process data.

Workflow takes a different approach. This time Claude no longer schedules each turn manually; it first writes the entire orchestration process as a JavaScript script—loops, branches, and intermediate result collection are all baked into the code—then hands it to a separate runtime for execution. The official documentation captures this shift concisely:

A workflow moves the plan into code. With subagents and skills, Claude is the orchestrator: it decides turn by turn what to spawn next, and every result lands in Claude's context. A workflow script holds the loop, the branching, and the intermediate results itself, so Claude's context holds only the final answer.

The plan has been moved into code. The script itself owns the loops, branches, and intermediate results; Claude’s context holds only the final answer. This is a continuation of the same line of thinking as “squeezing a large codebase into a limited context window”—the former addresses “how to use context sparingly,” while Workflow tackles “what to do when the workload is so large it simply cannot fit in context.”

Placing Agent Teams and Dynamic Workflows side by side:

Image from Anthropic PM Cat Wu’s tweet announcing Dynamic Workflows. On the left, Agent Teams form a mesh; on the right, Dynamic Workflows adopt a tree structure: “one Claude fans out to hundreds of tasks, each task goes through implementer → two verifiers → fixer, then fans back in.” The later Bun example, where each file gets two reviewers, is already visible here in embryo.

Before dissecting the architecture, let’s dispel a common misconception: many assume that Workflow is an orchestration engine running on Anthropic’s servers, so they go looking for its API protocol and worry about third‑party proxy compatibility.

The reality: the Workflow tool itself makes no server‑side requests. It is a JavaScript orchestration script that Claude Code runs locally on your machine—agent(), parallel(), pipeline() are control flows executing on your computer. The only parts that actually “call the server” are the subagents spawned by agent() calls inside the script, and those subagents call the model exactly the same way your main conversation does.

A direct corollary: if your Workflow fails while using a third‑party API proxy, it’s not the Workflow’s fault—it uses the exact same API that Claude Code has always used for model calls, i.e., Anthropic’s native Messages API (not OpenAI’s /v1/chat/completions):

POST {ANTHROPIC_BASE_URL}/v1/messages

Headers:
  x-api-key: <key>                         # or the common third‑party Authorization: Bearer <key>
  anthropic-version: 2023-06-01
  anthropic-beta: context-1m-2025-08-07    # 1M context carries this beta flag
  content-type: application/json

Body:
  {
    "model": "claude-opus-4-8",   # raw model id; [1m] is only a local marker, not in body
    "system": [ {... cache_control ...} ],  # system is an array with prompt caching
    "messages": [...],
    "tools": [...],               # Claude Code packs dozens of tool definitions
    "stream": true                # streaming by default
  }

Once this relationship is clear, Workflow’s runtime model becomes obvious: a brain‑dead, deterministic JavaScript runtime acts as the conductor—it merely loops, concatenates strings, and awaits, containing no LLM whatsoever. Only when execution reaches an agent(...) line does the runtime temporarily hire an LLM subagent to do the work. Meanwhile, the “real Agent”—the main Claude you are chatting with—is not running at all during script execution: its turn ends right after issuing the Workflow call; the script runs independently in the background, and when it finishes, a notification wakes the main agent to read the final result.

POST {ANTHROPIC_BASE_URL}/v1/messages

Headers:
  x-api-key: <key>                         # 或第三方常用的 Authorization: Bearer <key>
  anthropic-version: 2023-06-01
  anthropic-beta: context-1m-2025-08-07    # 1M context 会带这个 beta flag
  content-type: application/json

Body:
  {
    "model": "claude-opus-4-8",   # 裸 model id，[1m] 只是本地标识，不会进 body
    "system": [ {... cache_control ...} ],  # system 是数组，带 prompt caching
    "messages": [...],
    "tools": [...],               # Claude Code 会塞几十个 tool 定义
    "stream": true                # 默认流式
  }

When a Workflow runs, four components work together:

The most critical path in these diagrams is that subagent results flow into script variables first; the runtime handles loops and validations internally, and only the aggregated answer returns to Claude. This is fundamentally different from the subagent model, where “every result passes through Claude’s brain.”

The official documentation provides a three‑way comparison table that clearly lays out the positioning differences among Workflows, Subagents, and Skills:

When reading this table, pay attention to the “What is reusable?” row. Subagents and Skills reuse “a worker” or “an instruction,” while Workflows reuse the entire orchestration logic—meaning a complex workflow that schedules hundreds of agents for cross‑validation can be written once, saved, and rerun repeatedly. This is what sets Workflows apart from the other primitives.

Since a Workflow is a JS script, what does it actually look like? Let’s dissect the skeleton.

Every script must start with export const meta = {...}, and meta must be a pure literal—no variables, function calls, or template interpolations. It defines the script’s name, a one‑line description (displayed in the permission popup), and the phases:

export const meta = {
  name: 'find-flaky-tests',
  description: 'Find flaky tests and propose fixes',   // one‑line, shown in permission popup
  phases: [                                            // each phase() call corresponds to one entry
    { title: 'Scan', detail: 'grep test logs for retries' },
    { title: 'Fix',  detail: 'one agent per flaky test' },
  ],
}
// script body starts here
phase('Scan')
const flaky = await agent('grep CI logs for retry markers', { schema: FLAKY_SCHEMA })
phase('Fix')
// ...

After meta comes the script body. There aren’t many core primitives; a single table captures them:

The prompt for each agent() is written right in the script as a plain JS string. To feed different inputs to different agents, a common pattern is to write the prompt as a “function returning a string” and use .map() to insert loop variables at call time. Data flows between agents through plain string concatenation—there is no message bus: per‑item data is injected into each agent’s prompt with .map(), and cross‑phase data is JSON.stringify‑ed from the previous phase’s return value and concatenated into the next phase’s prompt.

export const meta = {
  name: 'find-flaky-tests',
  description: 'Find flaky tests and propose fixes',   // 一行，显示在权限弹窗
  phases: [                                            // 每个 phase() 调用对应一条
    { title: 'Scan', detail: 'grep test logs for retries' },
    { title: 'Fix',  detail: 'one agent per flaky test' },
  ],
}
// 脚本体从这里开始
phase('Scan')
const flaky = await agent('grep CI logs for retry markers', { schema: FLAKY_SCHEMA })
phase('Fix')
// ...

The easiest pitfall in a Workflow script is confusing pipeline with parallel. The essential difference is whether there is a barrier: parallel waits for the entire batch to finish before proceeding, while pipeline lets each item flow through all stages independently, without waiting for others. The following pattern is a typical waste:

const a = await parallel(...)   // ❌ barrier: waits for all to finish
const b = transform(a)          // only flatten / map / filter, no cross‑item dependency
const c = await parallel(b.map(...))

If five tasks vary in speed, the barrier makes the fast ones wait for the slow ones. The correct approach is to embed the transform into a pipeline stage, so that each piece of data flows to the next step as soon as it is ready:

// ✅ findings for dimension 'bugs' can start verification while 'perf' is still under review
const results = await pipeline(
  DIMENSIONS,
  d => agent(d.prompt, { label: `review:${d.key}`, phase: 'Review', schema: FINDINGS }),
  review => parallel(review.findings.map(f => () =>
    agent(`Adversarial verification: ${f.title}`, { phase: 'Verify', schema: VERDICT })
      .then(v => ({ ...f, verdict: v }))
  ))
)

You truly need a barrier only in three situations: when the next phase requires deduplication or merging across the entire set; when you need an early exit based on a total count (e.g., “0 bugs? skip the whole verification phase”); or when the next phase’s prompt needs to reference “all other findings” for cross‑comparison. Otherwise, when in doubt, use pipeline.

const a = await parallel(...)   // ❌ 屏障：等全部跑完
const b = transform(a)          // 只是 flatten / map / filter，没有跨 item 依赖
const c = await parallel(b.map(...))

// ✅ 维度 'bugs' 的发现可以在 'perf' 还在 review 时就开始 verify
const results = await pipeline(
  DIMENSIONS,
  d => agent(d.prompt, { label: `review:${d.key}`, phase: 'Review', schema: FINDINGS }),
  review => parallel(review.findings.map(f => () =>
    agent(`对抗性验证: ${f.title}`, { phase: 'Verify', schema: VERDICT })
      .then(v => ({ ...f, verdict: v }))
  ))
)

There are three ways to launch a Workflow from Claude.

First, simply include the word “workflow” in your prompt. Claude Code highlights it to indicate that the request might trigger a workflow:

Run a workflow to audit every API endpoint under src/routes/ for missing auth checks

If you casually mentioned “workflow” without intending to trigger one, press alt+w to dismiss the highlight.

Second, enable ultracode mode and let Claude decide on its own:

/effort ultracode

Third, run an already saved Workflow, which appears as a slash command:

/deep-research What changed in the Node.js permission model between v20 and v22?

Saved Workflows live in two locations, which determine their visibility:

.claude/workflows/      # project‑level, available to anyone who clones the repo — team sharing
~/.claude/workflows/    # user‑level, visible only to you but available in every project

When saving, press Tab to toggle between these two locations. If a project‑level and user‑level Workflow have the same name, the project‑level one takes precedence. Once saved, it becomes a /<name> command that appears in the slash autocomplete menu alongside regular slash commands.

After the script is generated—before it actually runs—you have a chance to review what it intends to do. While it is running, you can press Ctrl+G to open the script in the editor and inspect the code Claude wrote. This “visible and reviewable code” trait is what makes Workflows more reassuring than black‑box automation.

Run a workflow to audit every API endpoint under src/routes/ for missing auth checks

/effort ultracode

/deep-research What changed in the Node.js permission model between v20 and v22?

.claude/workflows/      # 项目级，克隆仓库的人都能用，跟团队共享
~/.claude/workflows/    # 个人级，只有你能看到，但在每个项目里都能用

The Workflow runtime is isolated from your conversation—the script executes in an independent environment, and your session remains responsive while it runs. This isolation mechanism also imposes a set of hard constraints you must understand.

Concurrency is capped: at most 16 subagents can run simultaneously (actually min(16, CPU cores − 2); machines with fewer cores will see a lower cap), and a single run allows a maximum of 1,000 agents. The latter acts as a fuse to prevent runaway scripts from burning money in an infinite loop.

Regarding permissions, all subagents spawned inside a Workflow automatically run in acceptEdits mode—file edits no longer produce per‑action confirmation dialogs—and they inherit the tool allowlist of your current session. However, one class of action will still interrupt execution: shell commands, web scraping, and MCP tools that are not on the allowlist will pop up a confirmation dialog mid‑run. Hence the official recommendation: before a large‑scale run, add the commands your agents need to the allowlist so you don’t get stuck on a permission popup partway through.

Another easy‑to‑miss detail: the script itself has no direct filesystem or shell access; all reading, writing, and execution must happen through subagents. The script is purely the “orchestrating brain”; the limbs are all attached to the subagents.

Resumability is a capability unique to Workflows among subagents and Agent Teams. Each run leaves a journal; after modifying the script, you can re‑run it with resumeFromRunId. Unchanged agent() calls hit a cache, and only the changed parts and everything after them are re‑executed. This is very handy for debugging orchestration logic—change one prompt line and re‑run; the agents that previously succeeded hit the cache, saving both money and time. But note one critical boundary: resumption only works within the same session. If you pause mid‑run you can resume and completed work is not lost; however, once you exit Claude Code, the next time you run that Workflow it must start from scratch.

Concepts can feel abstract, so Anthropic built a ready‑to‑use Workflow for you to try: /deep-research.

Its usage is simple—follow it with a question:

/deep-research <question>

When it runs, it does three things: first, it fans out a batch of web searches from multiple angles; then it fetches and cross‑checks those sources; next it votes on each claim; finally it produces a report with citations, discarding any claims that fail cross‑verification.

It requires the WebSearch tool to be available. The value of this built‑in Workflow is that it bakes “counter‑hallucination” directly into the orchestration. A single agent searching is easily led astray by one source, whereas multi‑path search plus cross‑voting essentially uses a structured process to converge on the truth. If you want a taste of what Workflows feel like, running /deep-research is the lowest‑cost entry point.

/deep-research <question>

If you don’t want to manually decide whether a task warrants a Workflow every time, you can hand that decision to Claude—enable ultracode.

/effort ultracode

This command does two things: it raises the reasoning effort to xhigh, and it allows Claude to automatically decide when to use a Workflow to handle your task. Once enabled, a single request may be broken into several successive Workflows—for instance, one to understand the code, one to make changes, and one to verify. This setting applies to every task within the current session; new sessions reset it.

The cost is straightforward: the official docs clearly state that ultracode mode consumes significantly more tokens and takes more time per request than lower effort levels. To return to everyday mode, just dial it back:

/effort high

This design of “letting the model decide its own scheduling scale” takes a different path from Codex’s Goals (persistent objectives)—more on that at the end.

/effort ultracode

/effort high

When people talk about orchestration, the first thought is often a DAG—Airflow, Argo, GitHub Actions’ needs: — where a static dependency graph is drawn up front and then executed. Is a Workflow the same?

The answer depends on which graph you’re asking about: as a program, it is not necessarily a DAG; but the trace of any single execution is always a DAG.

Let’s start at the program level. Claude Code’s Workflow is a piece of Turing‑complete imperative JavaScript; unlike traditional orchestrators, the dependency graph is not frozen before execution. It can express things that a DAG cannot—the most typical being a loop, for example: “keep finding bugs until two consecutive rounds produce no new ones”:

let dry = 0
while (dry < 2) {                            // ← a back‑edge; a cycle in the control‑flow graph
  const fresh = (await parallel(FINDERS.map(...))).filter(isNew)
  if (!fresh.length) { dry++; continue }
  dry = 0
  confirmed.push(...await verify(fresh))
}

Beyond loops, it can also write branches decided at runtime (if (bugs.length === 0) return—which path you take depends on the previous LLM output), and dynamic fan‑out (how many agents the next stage launches depends on how many results the previous stage returned)—the shape of the graph is not known in advance. At the “program structure” level, it has cycles and data‑dependent branches, making it strictly more powerful than a DAG.

But if you focus on “one specific execution,” it is always a DAG. Two reasons: data flows only forward in time—a value cannot depend on something produced later; and loops get unrolled—the agents in iteration N+1 of a while are different nodes from those in iteration N. The cycle exists in the “program,” but when unrolled into a “trace” it gets straightened into a chain.

A one‑line takeaway: a program with while is not a DAG, but the execution trace of a single run is always a DAG. This is precisely why it’s more flexible than traditional DAG‑based orchestrators—their graph is fixed before the run, whereas a Workflow’s topology is produced by the imperative script and determined only at runtime.

let dry = 0
while (dry < 2) {                            // ← 这是一条回边，控制流图里的环
  const fresh = (await parallel(FINDERS.map(...))).filter(isNew)
  if (!fresh.length) { dry++; continue }
  dry = 0
  confirmed.push(...await verify(fresh))
}

All the concepts so far pale in comparison to the Bun case study. Let’s revisit those opening numbers: 11 days, ~750,000 lines of Rust, 99.8% of original tests passing, from first commit to merge.

Bun is a JavaScript runtime written in Zig; performance is its calling card. Migrating such a large runtime wholesale from Zig to Rust is the kind of engineering that sounds hair‑raising—just Rust’s borrow checker with its strict ownership rules would make a manual migration extremely painful. Jarred Sumner pulled it off with three chained Workflows.

Phase one was lifetime mapping. The first Workflow did exactly one thing: for every struct field in the Zig codebase, compute its correct Rust lifetime. This step was extracted because it serves as the foundation for all subsequent porting—Rust’s memory safety is built on lifetime annotations; if this layer is wrong, the generated .rs files won’t even compile.

Phase two was parallel file porting—the part that best demonstrates Workflow’s scale advantage. The next Workflow converted each .zig file into a behaviorally equivalent .rs file, with hundreds of agents working in parallel and two reviewers per file for cross‑review. Comparing this volume with Agent Teams makes the gap clear—Agent Teams max out at a handful of members before coordination becomes unwieldy, whereas here hundreds of agents ran in parallel with dual review.

Phase three was the compile‑and‑test fix loop. Having files ported is only half‑baked; the real battle is getting them to compile and pass tests. The third Workflow drove the entire build and test suite, looping to fix failures until both ran clean. This is a classic example of the while‑loop pattern discussed earlier—relying on the script’s looping logic for many iterations, without Claude supervising each turn.

A table summarizes the characteristics of each phase:

But it didn’t end there. After the port was merged, an overnight workflow was run specifically for cleanup—scanning the code for unnecessary data copies and opening a separate PR for each optimization for human final review. This “run overnight by itself handling long‑tail cleanup and produce a pile of PRs to review” is a fascinating side of Workflows.

To be clear, the official note states that this Rust version of Bun had not yet entered production—the whole pipeline ran and passed tests, but it still had some distance to go before going live. Jarred himself said he’ll write a dedicated article with more details.

Bun is an extreme case; most people won’t get to run a cross‑language mega‑migration. I tried a more down‑to‑earth task myself: using a Workflow to create a “usage profile” of my own Claude Code chat history.

The task: the ~/.claude directory held 133 sessions, 130MB of jsonl records. I wanted to extract usage patterns, recurring pain points, and automation candidates. The job’s hallmarks were large data volume and multiple dimensions—a perfect fit for fan‑out.

I split the task into “main agent preprocessing + Workflow orchestration.” The main agent first did reconnaissance and cleanup: the jsonl was clogged with tool‑call noise; feeding it directly to an agent would waste context. So it first wrote a script to compress 133 sessions into “title + real user input + metadata,” yielding 601 genuine human inputs, then split them into 10 batches. Then the Workflow took over: 10 analysis agents worked in parallel, each chewing on one batch (extracting domain distribution, sticking points, automation candidates according to a unified schema); finally one synthesis agent cross‑batch aggregated and deduplicated, producing a prioritized report.

The execution skeleton, with declarations stripped out, looked roughly like this:

phase('Analyze')
const batches = Array.from({ length: 10 }, (_, i) =>
  `${DIR}/batch_${String(i + 1).padStart(2, '0')}.md`)

const findings = await parallel(batches.map((path, i) => () =>
  agent(ANALYZE_PROMPT(path), {                 // ANALYZE_PROMPT is a function returning a string
    label: `Analyze:batch_${String(i + 1).padStart(2, '0')}`,
    phase: 'Analyze',
    schema: FINDING_SCHEMA,                      // forced structured output; auto‑retry on mismatch
  })
))

const ok = findings.filter(Boolean)              // discard failures (skipped agents return null)
log(`Analysis done: ${ok.length}/${batches.length} batches returned valid results`)

phase('Synthesize')
const corpus = JSON.stringify(ok, null, 1)       // stuff all 10 findings into the synthesis prompt
const report = await agent(SYNTH_PROMPT, { label: 'Synthesis Report', phase: 'Synthesize' })
return report                                    // this return value is the only thing that re‑enters main context

The bill for this run: 11 agents, 818k tokens, 254 seconds. I also hit a pitfall—the first run crashed with TypeError: undefined is not an object (evaluating 'batches.map') because args weren’t passed correctly and got treated as a string. The fix perfectly illustrates the value of Workflows as “script as file, iterable”: I didn’t resend the entire script; I simply edited the on‑disk script file, hard‑coded the paths to be self‑contained, and re‑ran with scriptPath.

This case also answers a question many ask: “Couldn’t you just use a few subagents for this? What’s the difference?” Yes, you could—the difference is not about “can it be done?,” but about “where does the orchestration logic live, and where do intermediate results go?” If you spawned 10 subagents with the Agent tool, all 10 results would come back into main context as tool results; then in the next turn you’d have to read them with your own brain and decide how to combine them; the orchestration logic is improvised on the spot, and every coordination step burns main‑context tokens. With a Workflow, the orchestration is written in code; the 10 intermediate results never enter the main context, only the final report does; schema validation and concurrency control are automatic.

Honestly, I must add: for this particular “one‑shot map‑reduce,” the gap isn’t that large—10‑way parallel with one merge, subagents suffice. The real win of Workflows multiplies with complexity: when you have more stages, need loops (keep going until N consecutive rounds yield nothing new), need multiple rounds of adversarial verification, or need to fan‑out to dozens of units, manual coordination via subagents becomes painful, while scripting it is natural.

phase('分析')
const batches = Array.from({ length: 10 }, (_, i) =>
  `${DIR}/batch_${String(i + 1).padStart(2, '0')}.md`)

const findings = await parallel(batches.map((path, i) => () =>
  agent(ANALYZE_PROMPT(path), {                 // ANALYZE_PROMPT 是返回字符串的函数
    label: `分析:batch_${String(i + 1).padStart(2, '0')}`,
    phase: '分析',
    schema: FINDING_SCHEMA,                      // 强制结构化输出，不匹配自动重试
  })
))

const ok = findings.filter(Boolean)              // 丢掉跑挂的（被跳过的 agent 返回 null）
log(`分析完成：${ok.length}/${batches.length} 批返回有效结果`)

phase('综合')
const corpus = JSON.stringify(ok, null, 1)       // 把 10 份发现整个塞进综合 prompt
const report = await agent(SYNTH_PROMPT, { label: '综合报告', phase: '综合' })
return report                                    // 这个返回值就是唯一回到主上下文的东西

Seeing “code‑based multi‑step orchestration with LLMs in each step” easily prompts the thought: isn’t this just n8n, Coze, Dify? Only now the model does the orchestration automatically.

This intuition captures the key commonality, but the “only difference is AI‑auto‑orchestration” needs some tempering.

First, the commonality—and it’s stronger than expected. Anthropic’s “Building Effective Agents” gives an authoritative definition: Workflows are systems where LLMs and tools are orchestrated through “predefined code paths”; by contrast, Agents are systems where the LLM dynamically directs its own process at runtime. Under this definition, Dynamic Workflows and n8n/Dify/Coze are in the same category—their control flow is deterministic; the LLM never decides “which edge to take next” at runtime. Once the script is written, a dumb runtime executes it; the LLM only works inside each node. What falls outside this category is the main conversation’s ReAct‑style agent (that’s where the model really decides the next step on the fly). This judgment is completely valid.

But “the only difference” misses two harder distinctions. Laying them out:

Condensing the table into one sentence: Workflow ≈ taking n8n’s graph and replacing it with code generated on‑the‑fly by the model. It swaps two things—the author (human → model) and the medium (visual DAG → imperative code). The first brings immediacy and custom‑tailoring (no need for a human to pre‑build; generated specifically for the current task); the second brings greater expressiveness (can write loops and dynamic fan‑out, which a visual DAG cannot).

As for the most eye‑catching difference, “AI‑auto‑orchestration,” we need to be more precise: AI intervention happens at “code‑writing time,” not at “process‑running time.” In n8n, a human writes the orchestration, and the runtime deterministically executes it; in Workflow, the model writes the orchestration, and the runtime deterministically executes it—while it runs, the model is asleep. How the process runs is the same; the only difference is who authored the orchestration script.

Notably, both sides are converging: Coze and Dify are adding agent nodes (nodes themselves become autonomous) and code nodes (allowing JS/Python), moving toward “code + autonomous nodes”; meanwhile, Workflow scripts can be saved into .claude/workflows/ as reusable artifacts, moving toward “build once, reuse many times.” So a more precise conclusion is: your essential judgment holds—both are deterministic process orchestration with LLMs as steps—but the differences go beyond “AI‑auto‑orchestration” to include the medium being Turing‑complete code rather than a visual DAG, and each node being an autonomous agent rather than a fixed connector.

Since a Workflow is essentially “deterministic script + LLM calls at nodes,” it was completely feasible to roll your own before the official launch. The single core ingredient: claude -p.

claude -p (--print, headless mode) runs an entire agent loop non‑interactively—thinking, invoking tools, editing files—and exits when done. It reads from stdin, writes to stdout, and can be pipelined like any ordinary CLI tool. Treat each step as a claude -p invocation, wrap an orchestration loop in shell or Python around it, and you have a DIY Workflow:

# fan-out: 10 batches in parallel, each launching a claude -p
for f in batch_*.md; do
  claude -p "Analyze this batch: $(cat $f)" --output-format json > "out_$f.json" &
done
wait                                    # ← barrier, wait for all to finish, analogous to parallel()

# reduce: concatenate the 10 results and run one more claude -p to synthesize
claude -p "Synthesize these findings: $(cat out_*.json)" > report.md

A quick comparison shows structural isomorphism with the 133‑session Workflow: & plus wait is the barrier of parallel(), and $(cat ...) string concatenation is variable interpolation in the prompt. There are plenty of community practices like this; the futuresearch.ai post built an 18‑way parallel scanning pipeline using claude -p plus filesystem polling—subagents wrote results to disk (.json for success, .error for failure), and the orchestrator only polled filenames without pulling the output into context, reducing complexity from O(n × output size) to O(n × filename).

So what does the official Workflow add over the DIY version? Answer: the model is unchanged; what it saves is all the engineering grunt work.

In one sentence: Workflow productizes this DIY harness, saving the dirty work of engineering, not changing the model. Once you internalize this, you’ll have a solid grasp of its capability boundary—it’s not magic; it’s a runtime that polishes “claude -p + orchestration loop” into a smooth experience.

# fan-out：10 个批次并行，每个起一个 claude -p
for f in batch_*.md; do
  claude -p "分析这个批次：$(cat $f)" --output-format json > "out_$f.json" &
done
wait                                    # ← 屏障，等全部跑完，对应 parallel()

# reduce：把 10 份结果拼起来，再起一个 claude -p 综合
claude -p "综合这些发现：$(cat out_*.json)" > report.md

Not every task needs a Workflow. At its core, it trades many parallel agents for efficiency, and those parallel agents burn tokens for real. So when is that trade‑off worth it?

The official docs focus on four categories.

First, codebase‑wide batch audits—repo‑wide bug scans, profiling‑guided optimization audits, security audits. The common thread is “search plus independent verification”: Claude searches the entire service in parallel, then individually verifies each finding to ensure only real issues surface in the report. Check authorization gaps, input validation, or hardening dangerous patterns across the codebase—all share this shape.

Second, large‑scale migrations and modernization—framework replacements, deprecated API migrations, cross‑language ports, with Bun being the most extreme example.

Third, high‑stakes decisions that need heavy deliberation. When the cost of a wrong answer is high, have Claude approach the problem from several independent angles, then deploy adversarial agents to try to overturn the results, iterating until the answers converge—this adversarial verification can approach a quality level that a single pass cannot achieve.

Fourth, long‑tail cleanup, like Bun’s overnight workflow that automatically scans for issues and opens PRs one by one.

Conversely, these tasks make a Workflow overkill: small fixes that take one or two steps, exploratory work that requires frequent human decisions mid‑stream, or changes touching high‑risk code like security or payments.

Placing Claude Code’s existing collaboration primitives side by side, the selection logic roughly looks like this:

One‑line differentiation: if you need “legwork,” use subagents; if you need a “meeting discussion,” use Agent Teams; if you need a “pipeline job,” use Workflows.

Dynamic Workflows are currently a research preview with requirements for both version and plan.

You need Claude Code v2.1.154 or later. Platform coverage is broad: CLI, Desktop, VS Code extension, Claude API, plus the three major clouds Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry.

Plan differences are important: on Max, Team, and API‑based usage, Workflows are enabled by default; on Pro they are off by default—you must manually enable them under /config’s Dynamic workflows line; on Enterprise plans they are also off by default at launch, requiring an admin to toggle them on from settings. The first time a Workflow would be triggered, Claude Code shows you what it’s about to run and asks for confirmation—it never runs blindly.

If you want to disable it entirely, there are several layers of control:

// ~/.claude/settings.json
{
  "disableWorkflows": true
}

Or via an environment variable at launch:

export CLAUDE_CODE_DISABLE_WORKFLOWS=1

Individuals can also toggle it directly in /config; organizations can disable it uniformly through managed settings or the admin dashboard.

// ~/.claude/settings.json
{
  "disableWorkflows": true
}

export CLAUDE_CODE_DISABLE_WORKFLOWS=1

The official docs are unusually candid here: a single Workflow consumes significantly more tokens than a normal Claude Code conversation. The reason is straightforward—dozens or hundreds of subagents running simultaneously, each burning tokens, compounded by “extra redundancy” like cross‑validation and adversarial reviews. The 133‑session case used 11 agents and 818k tokens—and that was just a lightweight 10‑way parallel run. All this consumption counts against your plan’s usage and rate limits.

A few practical tips from the docs are worth jotting down. First, start with a small, well‑scoped task to gauge how much it costs in your own workflow before letting it loose on bigger jobs. Second, before a large run, verify with /model that you’re on the right model, and you can ask Claude to switch to a smaller model for phases that don’t need the strongest capabilities—not every step requires the most expensive brain. Third, as mentioned earlier, add the necessary commands to the allowlist ahead of time to avoid getting stuck with a permission popup hours into a run.

Thankfully, a Workflow can be stopped at any time without losing the work that has already completed.

During the research preview, several boundaries are worth noting up front so you don’t have to look them up after encountering them:

• No mid‑run human input: aside from permission popups, a running Workflow won’t pause for your approval. Processes that need staged sign‑offs must be split into multiple independent Workflows.
• The script itself has no file or shell access: all reading, writing, and execution go through subagents; the script only coordinates.
• Concurrent and total caps: maximum 16 concurrent subagents, up to 1,000 agents per run.
• Not recoverable across sessions: after you exit Claude Code, the next time you open it the Workflow starts from scratch.
• How to pass parameters to custom Workflows: the built‑in /deep-research accepts a question parameter, but the docs are still vague about how to pass parameters to your own saved Workflows.
• The entire feature is still a research preview—behavior and constraints may change with version updates.

At this point, we can step back and view all of Claude Code’s extension primitives in one table:

From top to bottom, the orchestration authority shifts step by step from “you” to “Claude” to “code.” Workflow sits at the far right—you give a single task description, the orchestration work is handed to a script written by Claude, and the scale reaches hundreds of agents.

This brings us back to the earlier foreshadowing: why Dynamic Workflows launched on the same day as Opus 4.8. When you have hundreds of agents working in parallel and reviewing each other’s conclusions, the reliability of each node becomes magnified—each node is a probabilistic LLM, the same question can yield inconsistent answers from different angles, and uncertainty compounds over multi‑step processes. Opus 4.8 specifically strengthened this area: the official word is that “it lets code defects slip through unnoticed roughly four times less often than the previous generation,” and it’s more inclined to proactively flag uncertainties. This honesty boost is exactly what makes the “hundred‑agent cross‑validation” approach viable—for cross‑validation to work, the reviewer must actually point out problems, not just nod along. A strong model isn’t optional for Workflows; it’s the load‑bearing wall.

Finally, let’s place Workflows in a larger picture. Making “code‑fied orchestration logic” an explicit product choice is itself intriguing: orchestration moves from a spontaneous, on‑the‑fly model behavior to a code asset that can be read, reviewed, saved, and rerun. Placed alongside Codex’s Goals, an interesting divergence emerges. Both aim to solve “how to keep a large task moving forward,” but the paths are opposite: Codex Goals bet on goal persistence—nailing the objective in place and letting the model figure out how to approach it step by step; Claude Code Workflows take the code‑fied orchestration route—writing the process as a script and relying on that script to prevent drift. One governs “where to go,” the other governs “how to go”; they are two different engineering philosophies. It’s too early to say which will go further, but the fact that two leading products are simultaneously attacking the problem of “carrying super‑scale workloads” tells us this is the next major battleground in AI coding.

Let me offer my own judgment. I find dynamic workflows incredibly powerful and likely representative of the future direction. It stands on two tightly interlocking pieces: one, solidifying “orchestration” from the model’s ad‑hoc improvisation into controllable code; the other, a sufficiently honest and strong frontier model capable of supporting hundreds of agents cross‑validating each other—exactly why it had to launch alongside Opus 4.8. The frontier model is the foundation; code‑fied orchestration is what makes “hundreds of agents collaborating without going off the rails” possible. Neither can be absent.

Precisely because it depends so deeply on frontier model capability, my prediction is: within a year, this approach of “model writes an orchestration script on‑the‑fly and dispatches an agent fleet” will grow from one company’s research preview into a standard feature of nearly all coding agents.

As a side note, the research behind this article was itself run by a Workflow: fifteen agents worked in parallel—closely reading primary conversation logs, cross‑referencing industry materials—270k tokens, 169 seconds, finally returning a consolidated set of materials. Using a Workflow to explain Workflows is probably the most direct trial of it.