Claude Dynamic Workflows — The Complete Guide (2026): ultracode and Enterprise Adoption After General Availability

Hello, this is Hamamoto from TIMEWELL.

On May 28, 2026, Anthropic released Claude Opus 4.8 and, at the same time, shipped "Dynamic Workflows." It launched as a research preview, but today both the official blog post "Introducing dynamic workflows in Claude Code" and the documentation state plainly that it is "generally available." That is the single most important revision in this article. In half a year, its position shifted from "a new feature you can afford to wait on" to "a standard capability anyone on a paid plan can use."

In this article, I use Anthropic's official blog and the Claude Code documentation as primary sources to organize how to actually put the now-generally-available Dynamic Workflows to work. That covers the launch keyword changing from workflow to ultracode, the real substance of scripts like agent() and pipeline(), the new levers for cost and governance, and the security question of which input paths can actually launch a workflow. I aim for a density that executives, DX leaders, and engineering managers who are building Claude into their operations can take straight into an internal decision-making meeting.

One note on rigor: for figures I could not fully corroborate from the body of the primary sources at this point — such as specific benchmark scores — I do not assert them here. I stay within what I could verify and flag anything unconfirmed as unconfirmed.

What Dynamic Workflows Is, and How It Reached General Availability

Let me first pin down the definition straight from the primary source. Anthropic's official documentation describes Dynamic Workflows like this: it is a JavaScript script for coordinating subagents at scale; Claude writes that script for the task the user describes, and a runtime executes it in the background — all while the user's session stays responsive.

A few terms, for newer readers. A subagent is a "spawned instance" that Claude creates to delegate a specific job; each runs with its own context and permissions and can operate in parallel. Orchestration is the work of controlling the execution order, branching, and concurrency across multiple agents. The runtime is the independent execution environment that runs the script — think of it as somewhere separate from the conversation itself.

What changed between half a year ago and now? Let's capture that in a table first.

Item	Then (May 2026)	Now (after GA)
Status	Research preview	Generally available
Available plans	Pro, Max, Team, Enterprise (some via admin enablement)	Available on every paid plan; Pro turns on "Dynamic workflows" in /config
Launch keyword	workflow (literal)	ultracode (workflow is a pre-v2.1.160 spec)
Minimum version	Claude Code v2.1.154 or later	Same, with per-feature additional requirements
Provider naming	Google Cloud Vertex AI	Google Cloud's Agent Platform (the Vertex AI name still appears on the blog and pricing page)

With general availability, the adoption decision moved from "use it or not" to "where do we start, and at what risk line." At the research-preview stage there was some logic to holding off on production because the spec wasn't frozen — but that premise no longer holds.

Relationship to Claude Opus 4.8

Claude Opus 4.8, announced the same day, is priced with the token-hungry nature of Dynamic Workflows in mind. Standard pricing stays at $5 input and $25 output per million tokens, held at the same level as Opus 4.7. Fast Mode is $10 / $50. That last one matters: Opus 4.7's Fast Mode was $30 / $150, so this is effectively one-third the price. And that Opus 4.7 Fast Mode is scheduled to be retired on July 24, 2026. Keep in mind that Fast Mode itself is still treated as a research preview, cannot be combined with the Batch API, and is not available on the Claude Platform on AWS.

Performance improvements on agentic coding tasks have been announced, but the benchmark scores such as SWE-bench Verified are deferred to the System Card and do not appear in the body of the primary sources I could retrieve this time. I will not assert those numbers. If you need specific scores for an adoption review, the surest path is to consult the Opus 4.8 System Card directly.

The Launch Method Changed: ultracode and /effort ultracode

The biggest technical error in the old edition of this article was how it described the launch keyword. It previously said to "include the word workflow in a prompt" and that "Claude Code highlights the word workflow" — that is an outdated spec. The official documentation explicitly states that "before v2.1.160 the launch keyword was workflow," and the current explicit keyword is ultracode.

Usage is straightforward. Include ultracode somewhere in your prompt and a one-off task gets orchestrated as a workflow. Natural-language requests such as "use a workflow" or "run a workflow" also continue to work. Even without memorizing the literal keyword, writing what you want in plain terms is enough to trigger it.

ultracode audit every API endpoint under src/routes/ and surface any missing auth checks

One level up is /effort ultracode. This setting combines xhigh reasoning effort with automatic workflow orchestration, and it is available from v2.1.203 onward. You can start the session with claude --effort ultracode, or set /effort ultracode inside a session. Once it's on, Claude will effectively plan a workflow automatically for each task — picture a single request branching into multiple "understand, change, verify" workflows. This setting is session-scoped and resets when you leave the session.

The bundled commands are alive and well, too. /deep-research runs Web searches in parallel from multiple angles, cross-checks the sources, and returns a cited report. This verification behavior was improved in v2.1.196: when a verification agent can't confirm a claim due to rate limits or API errors, rather than marking it "refuted" as before, it now lists the claim as "unverified" in the report. For fact-checking work, that difference quietly matters.

The Four Primitives: Subagents, Skills, Agent teams, and Workflows

This is where many people get confused. The old edition compared just three things — subagents, Skills, and workflows — but the current documentation expands the framing to four by adding Agent teams. Since Agent teams was entirely absent from the old edition, I'm replacing this section wholesale.

Agent teams is a setup where one lead agent supervises peer sessions of its own kind. They share a task list, and even if you cut in partway through to change instructions, your teammates keep running. It suits situations where you want to divide labor while staying in dialogue. Dynamic Workflows, by contrast, commits the plan to a script and runs the whole thing at once. With that distinction in mind, here are all four side by side.

Dimension	Subagents	Skills	Agent teams	Workflows
What it is	Workers Claude spawns	Instructions Claude follows	Peer sessions supervised by a lead	A script the runtime executes
Who decides the next move	Claude (turn by turn)	Claude (following the prompt)	The lead and teammates	The script
Where intermediate results live	Claude's context	Claude's context	A shared task list	Script variables
Behavior on interruption	The turn restarts from scratch	The turn restarts from scratch	Teammates keep running	Resumable within the same session
Scale it fits	A few per turn	Same as subagents	Parallel work while in dialogue	Tens to hundreds per run

The heart of the official documentation is one line: "the plan moves into code." With subagents and Skills, Claude decides what to spawn next at every conversational turn, and every result piles into the context. The context window has a hard ceiling, so once you exceed ten or so agents the conversation history swells and Claude begins to lose track of earlier results in later turns. Dynamic Workflows sidesteps that design bottleneck with script variables. Intermediate results are held as variables, and only the final answer returns to the conversational context. That's why you can run hundreds of agents and keep the conversation side clean.

Where It Fits Against the Agent SDK and Managed Agents

Two more similarly named mechanisms exist, so let's organize them in a separate table.

Type	Who runs it	Billing	Typical use case
Tool Use (Messages API)	The developer writes the loop	Token billing	The baseline pattern for custom tool calls
Agent SDK	The SDK abstracts the agent loop	Token billing	Embedding Claude Code-like behavior into your own app
Managed Agents	Anthropic manages the runtime	Tokens + $0.08 per session-hour of uptime	Production agents that run for hours or more
Dynamic Workflows	The runtime executes a script Claude wrote	Ordinary token billing	Coordinating dozens to hundreds of agents within a single run

Managed Agents is an independent layer billed by session uptime on top of tokens, and it is still offered today. The division of labor: if you want something running for a long time, use Managed Agents; if you want to knock out a complex one-shot task all at once, use Dynamic Workflows. One operational caveat: a Dynamic Workflows run does not honor the usual API modifiers such as Batch, Fast Mode, or data residency. If you were counting on Batch to optimize cost, that assumption breaks — so the cost controls described below have to be built from workflow-specific levers.

How It Works, and the Reality of the Scripts

What the old edition skimped on was the substance of the scripts themselves. Developers want to see concrete code, not concepts, so let's go deeper here.

A Dynamic Workflows script is plain JavaScript with top-level await available. There are two central functions. agent() launches a single subagent. pipeline() runs one agent per element of a list. You also declare a name and description in export const meta. Here is simplified code meant to convey the concept.

export const meta = {
  name: "auth-audit",
  description: "Audit src/routes for missing auth checks",
};

// Plain JavaScript where top-level await just works
const paths = await agent("List the endpoints under src/routes");

// Assign one agent per list element and run them in parallel
const findings = await pipeline(paths, (path) =>
  agent(`Verify ${path} for missing auth checks`)
);

// Results accumulate in script variables; only the final report returns to the conversation
const report = await agent(
  `Consolidate these verification results into a report: ${JSON.stringify(findings)}`
);

What's interesting is that this script is written out as a file for each run. The output lands under the session directory in ~/.claude/projects/, and that path is handed to Claude. So you can read the orchestration Claude wrote, review the diff, and fix it by hand before re-running if needed. Instead of a black box, the script remains in your hands as a reviewable artifact. For governance-conscious enterprises, I find this property quite significant.

The Exact Spec for Limits and Resumption

The limits are confirmed to be unchanged. The maximum running concurrently is 16 agents, and on machines with fewer CPU cores it drops further. The total per run is capped at 1,000 agents. That cap exists to stop runaway loops; everyday use lands in the tens to a few hundred.

The resume spec is worth understanding precisely. Completed agents return cached results, and only the unfinished ones actually run again. There's a pitfall, though: an agent that was mid-execution at the moment of the stop is not saved and has to start over. So rather than loading one agent with a heavy job in full, distributing across smaller agents leaves more progress intact when interrupted. One more thing: resumption only works within the same session. If you exit Claude Code, the next launch starts from zero.

New Equipment for Cost and Governance

With general availability, the concrete levers for cost control have grown. The old edition wrote abstractly about "token budget management" and "nested execution," but the current documentation names the actual features. Let me swap in the correct names.

The first is the "Dynamic workflow size" setting under /config (v2.1.202 onward). The default is unrestricted, but choosing small (fewer than 5 agents), medium (fewer than 15), or large (fewer than 50) advises Claude on a rough target scale. It's advice, not enforcement. The second is the "Large workflow" warning (v2.1.203 onward). If scheduled agents exceed 25, or if the projected total token count exceeds 1.5 million, a warning is shown. This too is advisory only and does not stop execution. Think of it as a brake that lets a human notice before things run away.

Let me also lay out the discount levers for cost itself. Prompt-cache reads cost 0.1x standard input — up to a 90% reduction — and are most effective for workflows that reuse a common system prompt. The Batch API cuts both input and output by 50%, so for Opus 4.8 the batch rate is $2.50 / $12.50. But as noted earlier, Batch does not apply to workflow runs, so treat this as something to use on the ordinary API-call side.

There's one easily overlooked new fact. Opus from 4.7 onward, plus Fable 5, Mythos 5, and Sonnet 5, adopt a new tokenizer that generates roughly 30% more tokens for the same text. When you estimate the cost of running many agents, failing to bake in that 30% uplift from the start will leave your projection too optimistic. Here is the model tier and pricing at a glance.

Model	Standard pricing (input / output, per million tokens)	Notes
Claude Fable 5	$10 / $50	Top-tier of the generally available lineup; the 1M context is included at the standard rate
Claude Mythos 5	Limited availability	Project Glasswing only
Claude Opus 4.8 / 4.7 / 4.6 / 4.5	$5 / $25	From 4.7 onward, the 1M context is included at the standard rate
Claude Sonnet 5	Introductory $2 / $10 (through 2026-08-31, then $3 / $15)	The 1M context is included at the standard rate
Claude Haiku 4.5	$1 / $5	A good landing spot for light work like verification and summarization

Staging within a workflow — "heavy planning on Opus 4.8, light verification and summarization on Haiku 4.5" — remains a valid go-to pattern.

Saving, Reuse, and args

A run you like can become an asset. In the /workflows view, press s to save that run's script as a command (the save-path display arrived in v2.1.208). There are two destinations: .claude/workflows/ if you want to share it in the repo, and ~/.claude/workflows/ if it's just for you. Once saved, you can invoke /<name> to call up the same orchestration as often as you like.

Reuse became much more practical with args. A saved workflow can receive structured input at run time. You pass things like a list of issue numbers, target paths, or a config object as args, and reference them inside the script as a global args. In other words, "routine work where only the arguments differ slightly each time" can now be run through a single workflow. As you build out a library of internal inspection tasks and report generation, this pulls its weight.

Disabling It at the Organization Level

The options for an enterprise administrator who wants to turn Dynamic Workflows off entirely are spelled out officially as well. The three individual means are: toggle it off in /config, add "disableWorkflows": true to settings.json, or set the environment variable CLAUDE_CODE_DISABLE_WORKFLOWS=1. To apply it across the whole organization, put the same flag in Managed Settings, or switch it off from the Admin settings page. For internal IT, having a hook for centralized control should be reassuring.

Security: Which Input Launches a Workflow

The part of the old edition that is now risky was its description around headless and the Agent SDK. It previously said "you can also run workflows via claude -p and the Agent SDK," but as of v2.1.210 this has changed substantially.

Now, launching a workflow via the keyword became an opt-in limited to input a human typed themselves. Specifically, prompts passed with -p, Agent SDK submissions without a human stamp, scheduled tasks, and input arriving via webhooks or PR comments no longer trigger a workflow. This is for security. I read it as a design meant to prevent accidents where instructions flowing in from outside spin up hundreds of agents on their own and rewrite the environment.

If you were considering running workflows in automation or CI/CD, you need to rebuild around this premise. "Include the keyword and it runs automatically" is no longer true, so if you fold it into a pipeline, you have to explicitly redesign an input path that satisfies the launch conditions. The old edition's explanation, which assumed automatic CI/CD execution, is wrong on this point.

One more thing to watch: the subagents a workflow launches basically run in auto-edit mode. Running them directly against a production repository presupposes a maintained tool allowlist and execution on a dedicated branch. Skip the up-front permission design and you're left with two bad outcomes — unexpected edits running, or a prompt on every action that erases the benefit of background execution.

Enterprise Adoption: Toward Post-GA Operational Governance

From here, on the basis of the official information, I'll organize the questions domestic executives and DX leaders should debate along four axes. The old edition made its fourth axis "the risk of it being a research preview," but now that it's generally available, the topic has shifted from "risk management while waiting" to "governance design for production operation."

Security and governance. First, translate the premise that subagents run in auto-edit mode into an internal standard. Codify execution on a dedicated branch, whitelist management of the tool allowlist, and the input-path restriction noted above (launch only from human-typed input) as operational rules. Organization-level on/off can be managed centrally via Managed Settings and the Admin dashboard, so a realistic approach is to enable it in a limited department first and expand once governance is in place.

Data sovereignty. Direct use of the Anthropic API routes through US regions by default. Google Cloud's Agent Platform (the former Vertex AI name still lingers), Amazon Bedrock, and Microsoft Foundry may let you choose domestic regions — but model availability needs individual confirmation. If you insert Dynamic Workflows into work that handles confidential data, which endpoint you route through directly decides where your data resides. In the boardroom, confirm that authority over the "which route do we take" decision is clearly assigned.

Operational overhead and cost. As the official documentation honestly states, Dynamic Workflows can consume considerably more tokens than a normal session. Starting from a limited task to get a feel for it is the safe path. Combine that with the size setting and the Large workflow warning discussed earlier, plus the roughly 30% uplift from the new tokenizer, to form your initial budget assumptions. Given that the agent count can be many times a conversation's, my gut sense is that setting the first budget at 5x to 10x normal operation makes it hard to miss badly.

Post-GA operational governance. With the research preview over, "the spec might change, so let's hold off" is no longer an available excuse. That said, putting it straight onto business-critical paths is a different risk. Run pilots on supporting work — documentation generation, code review, competitive research — and expand the scope while measuring KPIs. That ordering doesn't change after GA either.

---

Free Download: Enterprise AI Adoption Decision Framework

We publish a resource summarizing a decision framework — across four axes: security, cost, operational overhead, and data sovereignty — for evaluating 2026 AI agent foundations, including Dynamic Workflows, at your own company.

Download the resource for free

---

Use Cases Anthropic Itself Presents

To avoid speculation, here are the examples written in the official blog and documentation. The flagship is a bug sweep across an entire codebase. It explores the repository in parallel and spins up an independent verification agent for each finding, producing issues and patch proposals in bulk. Security audits follow the same idea — cross-checking from multiple independent vantage points yields higher confidence than a single reviewer. Profile-driven optimization audits and deep research via the bundled /deep-research are also among the official use cases.

As a real-world large-scale migration, the official blog cites Bun (the fast JavaScript runtime) porting from Zig to Rust. Its creator, Jarred Sumner, used Dynamic Workflows to generate roughly 750,000 lines of Rust and reach a state where 99.8% of the existing test suite passed. Eleven days from first commit to merge. What stands out is the substance: it's been shared that one workflow handled Rust lifetimes spanning struct fields, while follow-on agents assigned two reviewers per file and executed the port in parallel with identical behavior. Completing work spanning thousands of files within a single run, all while casting a net of review over it — this, I think, is the clearest showcase for Dynamic Workflows.

Options for Domestic Enterprises: Pairing ZEROCK with Dynamic Workflows

When you use Claude for work in Japan, you face a three-way choice: pipe Dynamic Workflows straight through the US-based Anthropic API, route it through Bedrock or a vendor's domestic region, or offload the part handling internal data onto a separate domestic foundation.

ZEROCK, the enterprise AI foundation TIMEWELL provides, is for companies that want the third option. It performs GraphRAG-based knowledge control on AWS servers in Japan and governs cross-functional instructions through a prompt library. You can build a hybrid setup that keeps highly sensitive information in Japan while using Dynamic Workflows' parallel-processing power for research and large-document work. Concretely: internal knowledge goes through GraphRAG search via ZEROCK, while external Web research and large codebase audits run on Dynamic Workflows. Or, within a workflow, you can stage things so that subagents touching confidential data go to the domestic foundation while Web searches and general verification go directly to the Anthropic API.

The optimal answer varies with your industry and the sensitivity profile of the work. Leaning everything onto a domestic foundation is not universally the right call. A realistic migration is to try it on supporting work first, then expand into core operations once governance has caught up.

"Dynamic Workflows Adoption Assessment" Supported by WARP NEXT

Judging whether to "use it at our company," "which work to start with if so," and "how to design governance" is a heavy lift for engineering managers and internal IT alone. It requires discussion that spans budget allocation, business-process redesign, and risk assessment.

TIMEWELL's WARP NEXT is an AI consulting service in which former enterprise DX and data strategy specialists ride along on a monthly basis. We help with sorting out which of your operations suit parallel processing, designing risk assessments and internal approval processes, selecting pilot work and its KPIs, combining ZEROCK, Managed Agents, and per-cloud routing, and translating it all into decision materials for the boardroom.

Now that it's generally available, there is almost no remaining reason to stay stuck at "let's wait and see." A competitor pulling ahead on operational efficiency six months later is the reality of the AI space since 2025. Watching and pilot adoption aren't a tradeoff — you need an operating structure that runs both at once.

Then vs. Now: The Arc of Claude's Feature Evolution

For reference, here is how Anthropic's agent-related features have evolved over the past year and a half.

Time	Feature	Position
Early 2024	Tool Use (Messages API)	The baseline pattern for custom tool calls
Mid 2024 onward	Computer Use	Screen-control automation
First half of 2025	Claude Code announced	Agentic coding CLI
Mid 2025	Agent SDK released	Claude Code-level capability as a library
Late 2025	Skills, Subagents, Managed Agents	Structuring agents and the operational foundation
May 28, 2026	Dynamic Workflows + Opus 4.8	Script-driven, large-scale parallel orchestration (research preview)
2026 (now)	Dynamic Workflows GA, Agent teams, ultracode	To every paid plan; launch via ultracode; Agent teams added

Starting from "define tool calls with Tool Use," it built up through "abstract the loop with the Agent SDK," "divide labor with Skills and Subagents," and "offload the operational foundation to Managed Agents," and then "script the orchestration itself with Dynamic Workflows." Now that has become generally available, and Agent teams — an interactive parallel-work mode — has been added. Seeing Dynamic Workflows not as a replacement for these but as an abstraction that rides on the top layer makes internal technology selection easier. For the latest feature status, check the official Claude Code documentation and the official Claude Platform documentation.

Summary

The key points:

• Dynamic Workflows is now generally available and works on every paid plan. Pro just turns on "Dynamic workflows" in /config.
• The launch keyword is ultracode. workflow is a pre-v2.1.160 spec. Natural-language requests also work, and /effort ultracode combines xhigh reasoning with automatic orchestration (v2.1.203 onward).
• The current comparison spans four things: subagents, Skills, Agent teams, and workflows. The plan moves into code, and intermediate results stay in script variables.
• The scripts are plain JavaScript with top-level await — agent(), pipeline(), and export const meta. Each run is written out to ~/.claude/projects/, so you can read, fix, and re-run it.
• Up to 16 concurrent, 1,000 agents total per run. Resume works only within the same session, and an agent mid-execution at the stop has to start over.
• Cost controls: the size setting, the Large workflow warning (over 25 agents or over 1.5 million tokens), a 90% cache reduction, and a 50% Batch reduction. Factor in the new tokenizer's roughly 30% uplift for the same text.
• As of v2.1.210, launch is opt-in and limited to human-typed input. -p, Agent SDK without a human stamp, scheduled tasks, and webhook/PR-comment input do not trigger it.
• For domestic enterprises, the practical answer is pairing with a domestic foundation like ZEROCK, or a per-cloud routing configuration. WARP NEXT supports the whole decision process.

In a single phrase — general availability — Dynamic Workflows shifted from "an experimental feature for those who can try it" to "standard equipment on paid plans." What the boardroom should debate is no longer "use it or not," but "which work do we start with, and at what risk line." The wait-and-see tone of half a year ago is something we can now let go of.

---

If You'd Like to Organize Your AI Strategy

Deciding which of the latest enterprise AI capabilities — like Dynamic Workflows — to bring into which work, and on what timeline, is exactly what WARP NEXT supports through monthly engagement led by former enterprise DX and data strategy specialists. If you want to use Claude safely on domestic servers, ZEROCK is the candidate to evaluate.

See what WARP NEXT covers　See what ZEROCK covers　Book a 30-minute free consultation

---

References

1. Anthropic. "Introducing dynamic workflows in Claude Code." (States general availability; the Bun case) https://claude.com/blog/introducing-dynamic-workflows-in-claude-code
2. Anthropic. "Orchestrate subagents at scale with dynamic workflows." Claude Code Documentation. https://code.claude.com/docs/en/workflows
3. Anthropic. "Introducing Claude Opus 4.8." May 28, 2026. https://www.anthropic.com/news/claude-opus-4-8
4. Anthropic. "Pricing." Claude Platform Documentation. (Opus 4.8 / Fast Mode / Batch / caching / new tokenizer) https://platform.claude.com/docs/en/about-claude/pricing
5. Anthropic. "Fast mode." Claude Platform Documentation. (Supported models; Opus 4.7 Fast Mode retirement date) https://platform.claude.com/docs/en/build-with-claude/fast-mode
6. Anthropic. "Create custom subagents." Claude Code Documentation. https://code.claude.com/docs/en/sub-agents