Anthropic just opened Claude Code Dynamic Workflows in research preview, and the headline is hard to ignore. A single run can fan out to up to 1,000 subagents, with 16 working in parallel, while a JavaScript script that Claude writes itself does all the orchestration. For teams already shipping mobile, automation, and agent products, this is the missing pattern between a single chat and a true swarm.
Most agent runs today stall at a few dozen steps. The model loses the plan, the tool log overflows the context, and a long task quietly ends with a half-finished output. Dynamic Workflows attack that problem by moving the loop out of the model entirely. Claude reads the task, writes a JS script that describes the plan, and a separate runtime executes the script in the background while your session stays free. The loop, the branching, and the intermediate results live in the script's variables, not in the model's memory.
The 30-Second Version
What Claude Code Dynamic Workflows Actually Do
A dynamic workflow is a small JavaScript program. Claude generates the program from your prompt, the runtime executes it, and each function call inside the script can spawn a subagent. Each subagent gets a clean context window, a task, and a set of tools. Results come back as plain JavaScript values, which means the parent script can branch, retry, filter, and converge without going through the model again.
- Fan-out — up to 16 subagents run in parallel, capped at 1,000 total per workflow.
- Verification built in — agents address a problem from independent angles, others try to refute the result, and the loop keeps running until the answers converge.
- Background runtime — the workflow keeps moving while your interactive Claude Code session stays responsive.
- Three surfaces — CLI, desktop, and the VS Code extension all hit the same workflow engine.
- Three clouds — runs on the Anthropic API, Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry.
The shape is the point. The model still does the hard reasoning, but the control flow is a script you can read, edit, and replay. That makes the whole run inspectable in a way a long single prompt is not. For more background on why this layer matters, see our piece on the orchestration era of agentic coding.
Why 1,000 Subagents Beat a Bigger Model
A larger context window helps a single run hold more state. A swarm helps a single run try more things. Those are different problems. Dynamic Workflows let the parent agent design a search rather than write a single answer. That changes the kind of work a team can send to the model.
| Task Shape | Single Prompt | Dynamic Workflow |
|---|---|---|
| Bug hunt across 2,000 files | Sampled, often incomplete | One subagent per slice, results merged |
| Framework migration | Manual file-by-file loop | Parallel rewrites with a verifier pass |
| Cross-checked research | One answer, no audit | Independent agents, adversarial review |
| Security audit | Skipped paths, drift | Bounded scope per subagent, evidence log |
| Long-running ops runbook | Drops after a few steps | Background run with checkpointed state |
The Bun Port: What 1,000 Subagents Looks Like in Practice
The most public test of Dynamic Workflows so far is the Bun runtime port from Zig to Rust. Jarred Sumner used a dynamic workflow to rewrite roughly 750,000 lines of Rust, with 99.8% of the existing test suite still passing, in eleven days from the first commit to the merge. That is not a chat-with-AI demo. That is a language port that would normally take a small team a quarter, run by a single engineer with a workflow that supervised itself.
Up to 16 subagents in parallel. Up to 1,000 subagents per run. Inspectable JS script as the plan.
The interesting part is not the line count. It is that the verification step held. The workflow could refute its own rewrites against the test suite, retry the failing slices, and only surface the final convergent diff to the human reviewer. That is the loop you cannot get out of a single long prompt, no matter how many tokens you give it.
Where This Fits the Mobile and Automation Stack
At Halmob we look at every new agent capability through the same three questions on our home page: does it survive on a phone, does it slot into an existing automation, and does it stay observable. Dynamic Workflows answer all three in a useful way, but the answer is not "use them everywhere."
The phone is still the approval surface
A 1,000-subagent run is not something a phone should host. It is something a phone should approve, watch, and stop. Pair Dynamic Workflows with the mobile orchestration pattern we covered in Hermes Workspace mobile and agent orchestration and the phone becomes the operator console, not the runtime.
n8n and the swarm sit at different layers
n8n triggers, gates, and routes. Dynamic Workflows fan out the deep work and converge it. The right shape is usually an n8n trigger that hands a scoped task to a dynamic workflow, then waits for the converged result before posting it downstream. The same layering shows up in the long-horizon pattern we wrote up for Kimi K2.6 agent swarms.
A conductor still helps
Dynamic Workflows orchestrate Claude subagents. Most real deployments mix models, tools, and humans. A higher conductor layer routes tasks to the right engine, which is exactly the role we described in Sakana Conductor multi-agent orchestration. Dynamic Workflows become one of the engines it routes to, not the whole stack.
How to Get Started Without Burning a Month of Spend
- 1Update Claude Code to v2.1.154 or later and turn on Dynamic Workflows. On Max and Team it is on by default. On Enterprise an admin enables it. On Pro you activate it manually. See the official Claude Code workflows documentation for the exact flag.
- 2Pick a task that today caps out around fifty tool calls or one hour. Codebase audits and migrations are the cheapest places to feel the value.
- 3Start with a budget of 50 subagents and 4 parallel. Do not jump to 1,000. A small swarm with clear boundaries teaches more in the first week than a big one that nobody can audit.
- 4Capture the script. The whole reason this design is interesting is that the plan is a file. Commit it, diff it, and treat it as part of your automation source.
- 5Wire the run into your existing review loop. The workflow can refute itself, but a human reviewer should still see the final convergent diff before it lands.
Risks and Guardrails
Three Costs You Should Plan For
- Token spend scales with the swarm. Set a per-workflow ceiling before you let it run unattended.
- Determinism is partial. The script is reproducible, but each subagent call is still a model call. Treat the workflow as a verifier, not a proof.
- Tool blast radius grows with parallelism. Sixteen agents calling the same write API can do real damage. Scope tools per subagent, not per workflow.
- Auditability needs deliberate logging. The script is readable; the subagent reasoning is not. Log the prompt, the result, and the deciding evidence on every fan-out.
The Bottom Line
Claude Code Dynamic Workflows turn the orchestration script into a readable artifact and the swarm into a default option. For mobile, automation, and agent teams, that closes the gap between a single prompt and a real long-running run. The right next move is not to port everything onto a 1,000-subagent workflow. It is to pick one task that today fails at scale, wrap it in a small dynamic workflow, and put a human review at the convergence point.
If you are still mapping out the agent layer below this, our OpenClaw 101 guide walks through the building blocks. Then come back here and decide which of those blocks deserves a script of its own.