How Claude Code’s Dynamic Workflows Scripted a 750k‑line Rust Migration

On May 28, Anthropic released Dynamic Workflows as a new primitive for Claude Code, allowing the model to write an executable JavaScript script that orchestrates large‑scale tasks which cannot fit in a single conversation turn.

When a single‑agent round cannot contain the whole task, let Claude write the scheduling process as an executable script.

Dynamic Workflows targets problems such as whole‑service bug hunts, migrations affecting hundreds of files, or plans that need exhaustive stress‑testing. The solution is to have Claude generate a script that contains loops, branches, and result aggregation, then hand it to an independent runtime.

Position in the Collaboration Stack

Claude Code has three layers of collaboration:

Session – a single agent runs serially.

Subagent – the main agent spawns helper agents that report back.

Agent Teams – multiple Claude Code instances run in parallel and can communicate.

All three share a bottleneck: Claude must decide the next step and ingest each subagent’s result, which quickly exhausts the context window when coordinating dozens or hundreds of parallel tasks.

Dynamic Workflows changes the model’s role: instead of deciding each step live, Claude writes a JavaScript script that encodes the entire plan. The script then runs in a deterministic runtime, only invoking agent() when a subagent is needed.

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.

This isolates the heavy lifting from Claude’s context, allowing the runtime to handle thousands of subagents without blowing the token budget.

Execution Model

The workflow script runs entirely on the user’s machine; it does not call any Anthropic server‑side engine. The only LLM calls happen inside agent(), which uses the same Messages API as a normal Claude conversation.

If a third‑party API is used as a proxy and the workflow fails, the failure is unrelated to the workflow itself because the LLM calls still go through Anthropic’s native endpoint.

During execution, the main Claude instance is idle after launching the workflow; it is awakened only to read the final answer.

Four Core Components

A running workflow consists of four cooperating parts (illustrated in the original diagrams): the script metadata, the loop/branch primitives ( agent(), parallel(), pipeline()), the subagents that perform LLM calls, and the runtime that drives the control flow.

The script must start with export const meta = {...}, which is a pure literal defining name, description, and stages. After the metadata, the body uses a small set of primitives: agent() – spawns a subagent with a prompt string. parallel() – runs a batch of agents concurrently and waits for all to finish (a barrier). pipeline() – streams items through stages without waiting for the whole batch.

The most common pitfall is confusing parallel with pipeline. Use pipeline unless you need a barrier for deduplication, early exit, or cross‑item comparison.

Creating a Workflow

There are three ways to start a workflow:

Type the word “workflow” in a prompt; Claude highlights it and you can press alt+w to ignore.

Enable ultracode mode so Claude decides automatically when a workflow is appropriate.

Run a saved workflow via a slash command (e.g., /my‑workflow).

Saved workflows are stored either at the project level or personal level; project‑level versions take precedence when names clash.

Isolation Constraints

Maximum 16 concurrent subagents (or min(16, CPU‑cores‑2) on low‑core machines).

Hard limit of 1 000 agents per run to prevent runaway loops.

All subagents run with acceptEdits mode and inherit the current tool allowlist; commands not on the list will trigger a permission prompt.

The script itself has no direct file‑system or shell access; all I/O must go through subagents.

Each run creates a journal; you can resume from a run ID with resumeFromRunId, but only within the same session.

Built‑in Example: /deep‑research

The built‑in /deep‑research workflow demonstrates multi‑angle web search, cross‑verification, claim voting, and a final sourced report. It showcases how the workflow mitigates hallucination by aggregating independent searches and voting.

Comparison with n8n / Coze / Dify

All these tools provide deterministic pipelines, but Dynamic Workflows differs in two ways:

The author of the pipeline is an LLM (Claude) rather than a human.

The pipeline is expressed as Turing‑complete JavaScript instead of a visual DAG, enabling loops and dynamic fan‑out.

Thus the core distinction is “AI‑generated code vs. human‑written visual DAG”.

Pre‑release Community Hacks

Before the official feature, users could approximate the same behavior with the headless CLI command claude -p (or --print) and orchestrate loops in a shell or Python script, effectively recreating parallel() with && wait.

When to Use a Workflow

Four scenarios are recommended:

Large‑scale code‑base analysis (bug scans, performance audits, security reviews).

Massive migrations or modernizations (e.g., Bun’s Zig‑to‑Rust rewrite).

Critical decisions that require repeated cross‑validation.

Long‑tail clean‑up tasks that can run unattended.

Tasks that are simple, require frequent human intervention, or involve high‑risk code changes are better suited to subagents or Agent Teams.

Availability and Configuration

Dynamic Workflows is in research preview and requires Claude Code v2.1.154 or newer. It is available on CLI, Desktop, VS Code extension, Claude API, and the three major clouds (Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry).

Plan defaults:

Max, Team, and API usage have it enabled by default.

Pro and Enterprise have it disabled; enable via /config → “Dynamic workflows”.

Workflows can be disabled per‑environment via environment variables, per‑user via /config, or organization‑wide via managed settings.

Token Cost Considerations

Each workflow consumes more tokens than a normal Claude conversation because many subagents run in parallel and may perform redundant verification. The 133‑session example used 11 agents, 818 k tokens, and 254 seconds.

Recommendations:

Start with a small, well‑scoped task to gauge token usage.

Use cheaper models for low‑risk stages via /model.

Pre‑populate the tool allowlist to avoid permission interruptions.

Research‑Preview Limitations

No mid‑run human input except permission dialogs; long approval chains must be split into multiple workflows.

Scripts lack direct file or shell access; all I/O goes through subagents.

Concurrency capped at 16 subagents; total agents capped at 1 000 per run.

Workflows cannot be resumed across sessions.

Custom workflow parameter passing is not fully documented.

Behavior may change as the feature matures.

Case Study 1: Bun Migration

Jarred Sumner migrated the entire Bun runtime from Zig to Rust in 11 days, writing ~750 k lines of Rust and achieving 99.8 % test pass rate. The migration used three chained workflows:

Stage 1: Compute Rust lifetimes for every Zig struct field.

Stage 2: Parallel file‑by‑file translation with two reviewers per file, scaling to hundreds of concurrent agents.

Stage 3: Compile‑and‑test fix loop that repeatedly runs while until the build and test suite are clean.

An overnight workflow performed post‑merge clean‑up, opening PRs for each unnecessary data copy it discovered.

Case Study 2: Profiling 133 Claude Sessions

The author used a workflow to profile 133 historical Claude sessions (~130 MB JSONL). The pipeline:

Pre‑process the JSONL to extract titles, user inputs, and metadata, yielding 601 real inputs split into 10 batches.

Parallel analysis agents process each batch, extracting domain distribution, pain points, and automation candidates.

A final aggregator de‑duplicates and produces a prioritized report.

A bug with missing arguments caused a TypeError; fixing it required editing the persisted script and re‑running with scriptPath, illustrating the “script as file” advantage.

Conclusion

Dynamic Workflows turns Claude Code’s orchestration into deterministic JavaScript that runs locally, enabling massive parallelism while keeping the LLM’s context small. It bridges the gap between subagents (small “run‑leg” tasks) and Agent Teams (collaborative discussion), offering a scalable pipeline for code‑base‑wide analysis, large migrations, rigorous decision‑making, and long‑tail automation.

References

Dynamic Workflows official documentation

Introducing Dynamic Workflows in Claude Code (official blog)

Claude Opus 4.8 release notes

Run agents in parallel (official comparison)

Building Effective Agents (Anthropic definition)

Headless claude -p documentation

Bun “Rewrite Bun in Rust” PR (oven‑sh/bun #30412)