Every few months a feature lands that gets screenshotted more than it gets used. Right now that's dynamic workflows in Claude Code — the thing that lets Claude fan a single request out across hundreds of subagents running in parallel, then hand you back one answer.

The demo everyone's passing around is the Bun rewrite. Jarred Sumner used dynamic workflows to port Bun from Zig to Rust: roughly 750,000 lines of Rust, 99.8% of the existing test suite passing, eleven days from first commit to merge (Anthropic). One workflow mapped the right Rust lifetime for every struct field. The next wrote each .rs file as a behavior-identical port of its .zig counterpart — hundreds of agents in parallel, two reviewers on every file. A fix loop drove the build until it ran clean.

That's a real result and it's genuinely impressive. It's also not your Tuesday.

If you're a founder or a two-person team, the interesting question isn't "can it rewrite Bun." It's narrower and more boring: which of my actual tasks parallelize, what checks the work when I'm not in the loop, and how do I keep one run from eating a week of usage. This post is the answer we give clients when they ask whether to turn it on.

What a dynamic workflow actually is

A dynamic workflow is a JavaScript orchestration script that Claude writes for the task you describe, then runs in the background across many subagents at once — while your session stays free (Claude Code docs).

That definition has three parts worth slowing down on, because each one changes how you should use it.

Claude writes the script, not you. You describe the task in plain language. Claude decides how to break it up, writes the orchestration in code, and shows you the plan before it runs. The two building blocks it uses are agent() (spawn one subagent) and pipeline() (run one agent per item in a list). You can read the script, save it, and rerun it — but you don't author it.

The plan lives in code, not in the chat. With plain subagents, skills, or agent teams, Claude is the orchestrator: it decides turn by turn what to spawn next, and every intermediate result lands back in its context window. A workflow moves the loop and the branching into a script, so the intermediate results sit in script variables and only the final answer returns to your conversation. That's the actual unlock — the plan doesn't drift as the task gets bigger, because the coordination happens outside the context window.

It runs in the background and it's bounded. Up to 16 agents run concurrently (fewer on machines with limited CPU), capped at 1,000 agents total per run — a guardrail against runaway loops (Claude Code docs). It shipped May 28, 2026 alongside Opus 4.8, and it's on by default for Max, Team, and Enterprise plans; Pro users flip it on in /config. You trigger one by saying "use a workflow," typing the ultracode keyword, or setting /effort ultracode and letting Claude decide when a task warrants one.

The part that matters more than the parallelism

The headline is "hundreds of agents." The thing that actually makes the output trustworthy is the verification, not the volume.

When a workflow fans work out, it doesn't just collect what the agents found and staple it together. Agents attack the problem from independent angles, other agents try to refute those findings, and the run keeps iterating until the answers converge. The bundled /deep-research workflow makes this concrete: it fans readers across sources, votes on each claim, and filters out claims that didn't survive cross-checking before you ever see the report.

This is the shift that's easy to miss. A single agent doing a security sweep gives you a list and a vibe. A workflow gives you a list where every finding was independently checked by an agent that didn't make it — and the noise was dropped before it reached you. Anthropic ships a rubric-style grader on the same idea: you say what "done" means ("all tests pass, no new TODOs, no public API changes") and each result gets graded in a separate context, sent back to revise until it clears the bar.

For a small team, that's the real value. You don't have a second engineer to review the first one's work. The verification lane is the closest thing to hiring that reviewer for a run. If you take one idea from this post, take that: fan out when the task benefits from being checked by something other than the thing that did it. The parallelism is how it goes fast. The cross-check is why you can trust the result.

When to fan out

Reach for a workflow when a task is bigger than one agent can hold in its head, or when the same step has to run across many items and each result is worth verifying. In practice that's:

• The same check across many files. Audit every route handler under src/routes/ for missing auth checks, one agent per file, each finding adversarially verified. This is the shape that pays off most often for small teams — a hardening pass, a dead-code sweep, a "where do we still call the deprecated API" hunt. Klarna's engineering team called out exactly this: surfacing cleanup and dead code that static analysis missed (Anthropic).
• A migration that touches too many files to babysit. Framework swaps, API deprecations, styled-components to Tailwind across a whole component directory — each file transformed in its own isolated copy so edits don't collide, each result checked.
• A fix loop with a clear pass condition. "Run tsc --noEmit and keep fixing errors until the type check passes or two rounds make no progress." The stop condition is objective, so the loop can run without you.
• Research that needs sources cross-checked, not just collected. Comparing how three competitors handle something, reading their docs and changelogs in parallel, then reconciling — the verification is the point, not the reading speed.
• A high-stakes decision worth stress-testing from several angles before you commit. Draft the plan three independent ways, have agents argue against each, and see what survives.

The common thread: many independent units of work, and an objective way to tell good output from bad. When both are true, fanning out is the right tool.

When not to fan out

Skip the workflow when the task is small, sequential, or fuzzy about what "correct" means — you'll pay for orchestration you didn't need and sometimes get a worse answer than a single focused pass.

• It fits in one agent's context. Fixing one file, answering one question, writing one function. Orchestration is pure overhead here. Just ask.
• The steps depend on each other. If step two can't start until you see step one, there's nothing to parallelize. A workflow's own script can't stop mid-run for your input — only agent permission prompts pause it — so anything needing a human decision between stages should be separate runs, not one workflow.
• There's no objective check. If "good" is a matter of taste and you're the only judge, the verification lane has nothing to verify against. You'll get convergence on something, but convergence isn't correctness.
• You're exploring, not executing. Early, ambiguous work where you're still figuring out what you want benefits from a tight back-and-forth. Fanning out an unclear task just produces a lot of confident wrong work, faster.
• You haven't scoped the cost. More on this next — but never point a fresh workflow at your whole repo. That's how you find out about the bill afterward.

The bill

A workflow spawns many agents, so a single run can use meaningfully more tokens than doing the same task in a normal conversation — Anthropic says as much in both the launch post and the docs, and recommends starting scoped.

This is the part that bites small teams, because the failure mode is invisible until the usage report. The move is to treat a workflow like any other expensive operation: run it on a slice first. One directory instead of the whole repo. A narrow question instead of a broad one. The /workflows view shows each agent's token usage as the run goes, and you can stop it there without losing completed work. Once you've seen what a slice costs, you can multiply.

Two more levers worth knowing. Every agent in a run uses your session's model unless the script routes a stage elsewhere, so check /model before a big run and ask Claude to use a cheaper model for the stages that don't need the strongest one. And the agent caps — 16 concurrent, 1,000 total — are your backstop against a script that loops forever. They bound the worst case, not the typical one.

We wrote a whole piece on keeping Claude Agent SDK credit costs under control; dynamic workflows are the same discipline with a bigger multiplier. The tool that can do a week of work in a day can also spend a week of budget in an hour if you point it at everything at once.

Where this fits in an operator stack

A dynamic workflow is a coordination primitive, not a memory or knowledge one — it's very good at running a bounded job across many agents, and it forgets everything the moment the run ends.

That's worth being clear about, because it's easy to mistake "I can fan out 1,000 agents" for "I have a multi-agent system." You don't. A workflow is stateless by design: intermediate results live in script variables and evaporate when the run finishes. It doesn't know what last week's run found. It doesn't carry your team's decisions or your project history into the next task. That's not a flaw — it's the right shape for a job runner — but it means the workflow sits on top of the substrate, it doesn't replace it.

This is the distinction we keep coming back to in what we mean by an operator stack: memory is where context persists, the vault is where your operator knowledge lives, and coordination is what routes the right work to the right place. A dynamic workflow is a sharp new coordination tool. It gets sharper when the agents it spawns can read from Agent Memory and Operator Vault instead of starting cold every run, and when something like Org-Desk decides which jobs are worth fanning out in the first place. The workflow is the muscle. The stack is what points it at the right thing and remembers what it found.

If you're getting AI-built work to production, this is also where the demo-to-production reliability gap shows up again: a workflow that passes its own rubric is not the same as a workflow you'd trust unattended on main. Wire the check to something real — your test suite, your linter, your acceptance criteria — not to the model's own opinion of "done."

A small-team playbook

If you're turning this on this week, here's the order we'd do it in:

1. Start with a read-only audit, not a migration. Point a workflow at one directory and ask it to find something — missing auth checks, dead code, TODOs that lie. Read-only means the worst case is a wasted run, not a broken branch.
2. Watch the token counter on that first run. Open /workflows, drill into a phase, see what a slice costs. Now you can estimate the whole.
3. Give it an objective stop condition. "Until tests pass," "until two rounds find nothing new." Objective conditions are what let a run finish without you.
4. Save the ones that work. When a run does what you wanted, save its script to .claude/workflows/. A review you run on every branch becomes /review-branch and does the same orchestration every time.
5. Keep a human on the merge. Let the workflow do the fan-out and the cross-check. You still own the decision to ship. The verification lane raises the floor; it doesn't remove the last checkpoint.

That's the whole method: scope small, verify against something real, keep the last call human, and reuse what works.

FAQ

What are dynamic workflows in Claude Code? Dynamic workflows are a Claude Code feature where Claude writes a JavaScript orchestration script for a task you describe, then runs it in the background across many subagents in parallel — up to 16 at once and 1,000 total per run — and returns a single verified answer instead of a turn-by-turn transcript. They shipped May 28, 2026 alongside Opus 4.8.

When should I use a workflow instead of a single agent or subagent? Use a workflow when the task is bigger than one agent can hold in context, or when the same step runs across many items and each result is worth checking — codebase-wide audits, large migrations, fix loops with an objective stop condition, and research that needs sources cross-checked. Use a single agent for anything small, sequential, or where "correct" is a matter of taste.

How do I turn on dynamic workflows? They're on by default for Max, Team, and Enterprise plans and via the Claude API. Pro users enable them in /config. To run one, say "use a workflow," include the ultracode keyword in your prompt, or set /effort ultracode and let Claude decide when a task needs one. It requires Claude Code v2.1.154 or later.

Do dynamic workflows cost more? Yes — meaningfully. A workflow spawns many agents, so one run can use far more tokens than doing the task in a normal conversation, and it counts toward your plan's usage and rate limits. Scope it first: run it on one directory or a narrow question, watch the per-agent token usage in the /workflows view, then decide whether to run the whole thing.

Is a dynamic workflow the same as a multi-agent system? No. A workflow is a stateless job runner — its intermediate results live in script variables and disappear when the run ends. It doesn't remember previous runs or carry your team's context between tasks. A durable multi-agent system adds a memory layer, a knowledge vault, and a coordination layer that decides what to run; the workflow is one coordination tool that sits on top of that substrate.

---

Trying to figure out which of your workflows are worth handing to an agent — and which will just spend your budget faster? That's exactly what a Workflow Audit is for: we map what you're actually doing, flag what parallelizes safely, and hand you a plan. Or tell us what's breaking. Receipts over slideware.