Claude Code Dynamic Workflows: How to Actually Drive Them

Anthropic’s Dynamic Workflows announcement landed with real engagement on Hacker News, and the conceptual explainers showed up fast. But most of them skip the part that actually matters when you sit down to use the feature: there’s no SDK to import and no orchestration script you write. That’s the whole point. With Dynamic Workflows, Claude writes the orchestration — and your job is to drive it well.

This post is the practical version: what a Dynamic Workflow actually is, how to turn it on, and how to get a real branching one running.

What you need

Claude Code, on a plan that has the feature. Per the announcement, workflows are available in the Claude Code CLI, Desktop, and the VS Code extension. They’re on by default for Max and Team plans and off by default for Enterprise (an admin can enable them). No SDK, no extra install.

What a Dynamic Workflow actually is

Straight from the announcement: “Claude dynamically writes orchestration scripts that run tens to hundreds of parallel subagents in a single session, checking its work before anything reaches you.” Claude “plans dynamically based on your prompt, breaks it into subtasks, and fans the work out across subagents running in parallel.”

The mental model that matters: this is not a workflow engine you program. It’s Claude deciding — for a big enough task — to write its own orchestration, spin up many subagents at once, and reconcile their output before handing you a result. The “branching” is real, but Claude authors the branches; you author the prompt and the guardrails.

Step 1: Turn it on

Two ways in.

If you’re on Max or Team, workflows are already on — you can just ask for one (Step 2). To make Claude reach for a workflow more readily, the announcement points to one Claude Code-specific setting: ultracode. Enabling it “sets the effort level to xhigh, while letting Claude decide automatically when to use a workflow.”

So ultracode is the “lean into it” switch: max effort, and Claude picks when fanning out is worth it. If you’d rather stay in control, leave it off and invoke workflows explicitly per task instead.

Step 2: Invoke a branching workflow

There’s no command to memorize. You ask. Per the announcement, you “ask Claude to create a dynamic workflow directly” — e.g. “Create a workflow.”

To get branching specifically, describe the fork in the task itself. The router shape — classify, then send each item down a different path — is a good first one because you can see the fan-out clearly:

“Create a workflow that takes my inbox/ of support tickets, classifies each as bug, billing, or feature request, and for each class drafts a different response: bugs get a reproduction-steps template, billing gets routed to a refund-policy summary, feature requests get a thanks-plus-roadmap note. Run them in parallel and show me the drafts grouped by class before writing anything.”

That prompt does the work the old “decision node + two subagents” framing was reaching for — a classification step, divergent handling per branch, parallel execution — except Claude builds the orchestration, not you. The two things you actually control are the branch definitions (be explicit about the classes and what each should produce) and the checkpoint (“show me before writing anything”), which keeps a human in the loop before any side effect.

Step 3: Keep a human in the loop, and scope it

The announcement is explicit that Claude “check[s] its work before anything reaches you,” but you should still gate side effects yourself — hence the “show me the drafts before writing anything” clause above. For a branching workflow, the failure you care about isn’t one subagent erroring; it’s a misclassification sending an item down the wrong branch. Asking to see the grouped output before any write is the cheapest guard against that.

And scope your first run deliberately. Anthropic’s own guidance is to start “on a scoped task to get a feel for usage in your work” — because Dynamic Workflows “can consume substantially more tokens than a typical Claude Code session.” Ten tickets, not a thousand, on the first pass.

Where this breaks

Token cost. The announcement gives no multiplier, but it’s direct that workflows can use substantially more tokens than a normal session — fanning out across many parallel subagents is the reason. The honest control here isn’t a config flag; it’s task scope. Branching multiplies subagents, so a wide or deep fork is exactly where cost climbs. Start small and watch usage before you point it at a big batch.

It’s off for Enterprise by default. If you’re on an Enterprise plan and the feature seems absent, that’s expected — an admin disables or enables it through managed settings. That’s a permissions question, not a bug to debug.

Next steps

The shift to internalize: you don’t build a Dynamic Workflow, you direct one. Get the most out of that by being precise about branches and explicit about checkpoints in the prompt itself, flip on ultracode when you want Claude to fan out aggressively, and keep early runs scoped while you learn how many tokens your real tasks burn. From there, the natural next step is more branches — more classes, richer per-branch handling — described in the same plain-English way, with Claude doing the orchestration each time.