When a Task Is Too Big for One Conversation
On May 28, 2026, Anthropic released Claude Opus 4.8 and, alongside it, a research-preview feature called Dynamic Workflows. The most jaw-dropping demo came from Jarred Sumner, the creator of Bun—he used it to migrate 750,000 lines of Zig to Rust in 11 days, with a 99.8% test pass rate.
The feature tackles an old problem: some tasks are simply too big for a single agent in a single conversation. Org-wide bug sweeps, cross-language megamigrations, multi-round adversarial validation… In these scenarios you don't need "one smart brain"—you need "a coordinated team."
Dynamic Workflows takes a novel approach: have Claude write the orchestration logic as an executable JavaScript script. Instead of Claude deciding the next step round by round, it writes the "playbook" upfront, and the playbook automatically dispatches dozens or even hundreds of sub-agents to do the work.
From Solo to Assembly Line
To appreciate what makes Workflows unique, it helps to look at how collaboration evolved before it.
The earliest approach was a single Claude session—everything crammed into one context window, one task at a time. Then came Subagents: Claude could spin off a few helpers to search, read code, and so on, but the scheduling was still Claude deciding round by round, and every result had to flow back into the main context. Scale it up and it falls apart. Later, Agent Teams let a few agents discuss in parallel—good for multi-perspective collaboration—but the team size stayed in the single digits.
Workflows takes a completely different path: the script is the brain; Claude is only hired temporarily at each node to do the work. The main agent literally "sleeps" while the script runs, only waking up at the end to read the final results. Because intermediate state doesn't eat into the context window, you can naturally orchestrate hundreds of agents.
Put simply: Subagents are "the boss hands out tasks one by one," Agent Teams are "a group discussion," and Workflows are "write the assembly-line script and let the workers run it themselves."
How It Actually Runs
A running Workflow needs four things: an orchestration script, an isolated runtime, a pool of sub-agents, and script variables.
The orchestration script is JS code that Claude generates automatically—it defines loops, branches, and dispatch logic. This is the "brain." The isolated runtime executes the script locally without blocking your terminal. Sub-agents are spawned by the script and handle the actual code reads/writes and command execution. Script variables store intermediate results without polluting the main agent's context window.
A few core primitives in the script are worth highlighting. agent(prompt) spawns a sub-agent; you can add a schema for structured output. pipeline and parallel are an interesting pair: pipeline(items, stage1, stage2, ...) is barrier-free parallelism—each item flows through all stages independently, first-come-first-served, no waiting for others. parallel(thunks) is barriered parallelism—every task must finish before moving on, which is ideal when you need to aggregate results. One is like an assembly line; the other is like "meet, then proceed." phase(title) and log(msg) are progress indicators for the user—worth knowing but straightforward.
One easily overlooked detail: the script is Turing-complete. It supports while loops and dynamic branching, which means it can do things like "compile, test, fix, repeat until convergence"—something a static DAG workflow simply cannot express.
How to Trigger, Where They Live
There are three ways to trigger a Workflow. The most direct: mention the "workflow" keyword in a conversation. You can also enable Ultracode mode (type /effort ultracode) and let Claude decide whether to spin up a workflow. A third option is running a saved Workflow via a slash command, e.g. /deep-research <question>.
Saved locations come in two tiers: project-level lives in .claude/workflows/ (shareable with the team), and personal-level lives in ~/.claude/workflows/ (for your own reuse).
Some Hard Constraints
A few limits to keep in mind: the concurrency cap is 16 sub-agents running simultaneously (bounded by CPU cores), and a single run can spawn at most 1,000 agents. Sub-agents default to acceptEdits mode, but sensitive operations still require you to click confirm. The script itself has no filesystem access—everything goes through sub-agents. A handy feature is resumability: each run gets a runId, and if you modify the script and rerun, unchanged parts hit the cache and only the deltas re-execute. However, resumability does not persist across sessions—close your terminal and it's gone.
Two Real-World Stories
Bun's Zig-to-Rust migration is the case that best showcases Workflows' power. The whole process had three phases: first a global analysis that mapped Zig lifetimes to Rust; then parallel migration of hundreds of files, each with a dual review; and finally a "compile → test → fix" while loop that ran until all tests converged and passed. This "run a round, fix, run again" loop logic is only possible because the script is Turing-complete.
Another case analyzed 133 historical conversation logs (a 130 MB jsonl file). The main agent preprocessed the data, then a Workflow analyzed 10 batches in parallel, and a final synthesis agent rolled up the report. 11 agents, 818K tokens, done in 254 seconds. This "divide and conquer, then merge" pattern is a classic Workflow play.
How Is This Different from n8n / Dify?
On the surface they all "orchestrate," but the fundamental difference is huge.
Tools like n8n, Dify, and Coze have you drag nodes onto a canvas, wire them up, and hit run. Node capabilities are fixed (HTTP requests, data transforms, etc.), and the whole flow is a static DAG. The moment you hit a scenario like "decide the next branch based on the previous step's result," you end up bolting on conditional nodes until the diagram becomes a mess.
Claude Code Workflows flip this entirely: the flow is written by the model on the spot for the current task, not pre-designed by a human. The vehicle is imperative JS code, not a visual node graph, so loops and dynamic fan-out come naturally. Each node isn't a fixed operation but an autonomous sub-agent that can do anything. And it lives right inside your coding session—no extra platform needed.
One-sentence summary: Workflow ≈ swap n8n's graph for model-generated code on the fly. You don't just get automated orchestration; because the carrier is code, you also gain the ability to handle complex logic.
When Should You Use It?
Good fits: repo-wide batch sweeps, large-scale migrations, adversarial validation for critical decisions, long-tail cleanup. In short—"lots of work, a repeatable pattern, no need for frequent human sign-off."
Bad fits: small patches that take a step or two—using Workflows here is overkill; exploratory work that needs constant human judgment—the pipeline will just keep stalling waiting for you; high-risk scenarios where hundreds of agents are editing code simultaneously and pinpointing problems gets painful.
A simple rule of thumb: need a "runner"? Use Subagent. Need a "group discussion"? Use Agent Teams. Need an "assembly line"? Use Workflow.
Also watch the cost—token consumption is significantly higher than a normal conversation. Start with smaller tasks to get a feel, and consider using a smaller model for non-critical stages. Another thing: once running, a Workflow basically doesn't accept human input (permission confirms excepted). If you change your mind mid-run, your only option is to stop and rerun.
Closing Thoughts
Dynamic Workflows represents an interesting direction: codifying orchestration logic. It turns what used to be ad-hoc model-driven coordination into controllable, auditable, reusable code assets. Combined with Opus 4.8's improvements in honesty and reliability, this "model writes scripts to command an agent fleet" pattern could well become a standard feature of future coding assistants.
Of course, it's still a research preview—cross-session resumability and mid-run intervention are still limited. But the direction is clear: as AI coding goes from "help me write a function" to "help me ship the whole project," deterministic orchestration becomes a hard requirement. Workflows is Anthropic's answer.