Anthropic replaced the old agent pattern because one-level subagents stopped scaling. Delegation was one level deep, capped at 25 child threads, and everything beyond that had to be faked by the main conversation relaying between rounds.
Dynamic Workflows, in beta for Claude Managed Agents since October 9, 2026, lets Claude write an orchestration program that starts sub-agents, chains stages and combines results. A single run can start up to 1,000 agents over its life.
That does not delete the hard problems. It moves them: into launches nothing approves, 24-hour lifetimes, ten session slots, tool-level permissions, budget caps that overshoot and a Claude-only stack.
By the end you will know which limits the old pattern actually hit, where control lives now, and whether your next pipeline should migrate at all.
| Decision point | Old way: one-level subagents | Dynamic Workflows |
|---|---|---|
| Delegation depth | One level deep, no second level | Claude writes a program that chains stages |
| Concurrency | At most 25 child threads at a time | Up to 1,000 agents per run, 64 threads at once (not guaranteed) |
| Who starts a run | Developer code or an explicit call | The agent decides, no approval step |
| Run lifetime | Bound to the request | 24 hours by default or an agent-set lifetime |
| Session slots | Not a tracked resource | 10 open runs by default, idle runs included |
| Permissions | Attached to the calling code | Attached to the tools a run's agents call |
| Billing | Session tokens | Session tokens plus $0.08 per session-hour, $10 per 1K web searches |
| Self-improvement | None | None built in yet |
| Model choice | Whatever you wired in | Claude only; Bedrock and Vertex endpoints |
The ceiling was 25 child threads, and the old pattern could not see past it
The old pattern handled small jobs fine and stalled on broad ones. Delegation ran one level deep, with no more than 25 child threads at a time.
A job that needed a second round had to fake it, with the main conversation relaying results between waves.
Dynamic Workflows moves those two numbers. One run can start up to 1,000 agents over its life, with no more than 64 working at once.
That 64 is not a promise: the API does not guarantee it. That's the interface the software exposes to other software, and it can change a limit without warning.
The gap shows on a 1,000-item scan. At 64 threads it runs about 16 waves. The old ceiling of 25 needed 40.
The old pattern also could not chain a second level at all, so items that needed their own helper agents ran one at a time.
Two numbers, not one: total agents for the run and concurrent threads at once. Size against both. Any job that fits a single agent never touched 25, and does not need this.
Orchestration moved out of the chat transcript and into code
The planning logic left the conversation. Under the old one-level pattern, each subagent's result landed back in the main chat and the lead agent relayed it to the next round. Orchestration state was chat state, and you read it as a scrollback.
Dynamic Workflows replaces that loop with software Claude writes itself. The program starts sub-agents, chains stages and combines results, while the main agent stays free to talk to the user. The beta launched October 9, 2026 for Claude Managed Agents.
That program is a new artifact to inspect and debug. Failures move, and not always for the better: a loop that never exits, a stage fed the wrong input, results joined in the wrong order. You now read code to find it, not a transcript.
Version it and review it like any service. A workflow whose logic lives only in a chat log cannot be diffed, rolled back or handed to the next engineer when it breaks on a Sunday.
💡 PRO TIP
Write the launch policy before you enable it
Agent-initiated runs mean the launch path has no human in it. List which tasks may run unattended and which must stay single-agent, then put that list in the repo beside the orchestration code.
Nothing in the launch path asks a human anymore
The agent decides. It reads the task in front of it and chooses whether and when to start a run. There is no extra API call and no developer approval step, so nothing in the launch path asks a human.
That makes the launch a model judgment, not a gate. The old pattern put a developer between a request and its fan-out, even if only by building the call.
Now the moment a session carries the capability, the review is gone and a decision takes its place.
The catch is quiet. The first workflow you did not plan can start while someone is typing an unrelated question into the same session. It bills at token rates like everything else, and nobody clicked approve.
Write the list first: which tasks may run unattended, and which stay single-agent. Keep it next to the orchestration code. Capability is not permission, and the system treats them as if they were.
Dynamic Workflows — At a Glance
🧵 Threads at once
64 (not guaranteed)
🤖 Agents per run
Up to 1,000
🕒 Default lifetime
24 hours
📂 Open runs per session
10 by default
💵 Session-hour rate
$0.08
The one you forget
Idle runs hold a session slot for their whole lifetime, so ten forgotten runs block the next job.
Run lifetimes and ten session slots are the limits you now design around
A run lives 24 hours by default, or for whatever lifetime the agent itself sets. No event reports which lifetime was chosen. Stale runs are therefore hard to spot from outside, because nothing announces that a run is sitting past its useful life.
A session holds 10 open runs by default, and idle runs count against that number. Anthropic says the server enforces other workflow limits it does not publish. Those belong in Anthropic's own docs, not in a number anyone guesses at.
The consequence is blunt. An idle run keeps its slot for its whole lifetime. Ten forgotten runs and the session cannot start the next job, which is a capacity failure with no error that points at the cause.
Cleanup habit: list every run ID with its start time and expected expiry, then kill idle runs on a schedule. Do this before scaling concurrent work, not after the first jam.
Permissions attach to tools, so the toolset is where safety lives
Permission policies attach to the tools a run's agents call, not to starting the run. Combine that with agent-initiated launches and the picture is clear. The launch is not where safety lives. The toolset is.
The practical control is least-privilege access per specialist agent. The lead agent may hold write scope; the research agent reading a slice of sources should not inherit it. Split the toolsets so a specialist can only reach what its slice of the job needs.
That audit has to cover everything a workflow can call. Some tools arrive as MCP servers. MCP is a standard way to plug outside tools and data into an agent. Skills count too, since they load instructions the agents act on.
Before anything runs unattended: walk the full list of tools each agent can reach, confirm none grants delete or write scope it does not need, and revoke the rest. A tool policy you have read beats one you have assumed.
The vocabulary of the new pattern
Code orchestration traces better and debugs worse, unless you log
Code orchestration leaves a better record than a chat did. In the old pattern, stage results landed back in the main conversation, where they were easy to lose and slow to inspect later.
Now stages and combined outputs sit in a program you can read in order.
It also gives you a new place to break. The orchestration program is fresh code, and it can loop, mis-chain a stage or merge two results wrongly.
Worse, no endpoint lists runs. A run can only be found if its ID was written down at launch.
Log at creation: the run ID, every stage output and the orchestration version that produced them. Do it at launch time, because there is no later lookup to fall back on.
With those three recorded, any run traces straight back to the code behind it. That flips the task from archaeology in a transcript to a diff against a known version.
Your budget cap can overshoot by one request per working thread
A workflow run has no price tag of its own. Every stage along the trace bills as tokens, the chunks of text the models read and write, charged at each model's own rate like everything else in the session.
The meter runs from the first agent to the last.
Managed Agents adds a platform charge on top, per the research write-up: standard token rates plus $0.08 per session-hour and $10 per 1K web searches, as of November 2026.
The cap itself is where the surprise sits. When a session reaches its budget, open runs pause and report budget_reached. Each working thread still finishes the model request it already started, so at 64 threads up to 64 requests land after the line.
Set the cap below the ceiling you can actually absorb, and check token spend stage by stage. Then that overshoot stays a rounding error instead of the bill itself.
Where a workflow earns its extra spend
Run it as a workflow
- Broad scans across many sources
- Jobs that decompose into independent slices
- Stage outputs you need to inspect one by one
- Work where extra detail is the deliverable
Keep it single-agent
- Jobs that fit one agent's context
- Tight cost ceilings with little slack
- Work needing tools you have not audited
- Anything a failure would make expensive
The extra spend buys detail, and one stock scan showed where
They also uncover more detail. The demo was a stock watchlist scan, run on site as a workflow rather than by one agent.
That points to the jobs where the spend pays back. Broad scans. Many sources. Research that splits cleanly, where each specialist reads a different slice of the material and reports back.
A bounded question with one answer does not fit. Run it on one agent, compare outputs, and see whether the extra slices found anything the single agent missed. If they did not, skip the workflow.
Baseline first: pilot one high-detail job head to head against a single-agent run. Expand only where the workflow's output shows detail worth the tokens.
🧭 A migration you can defend later
Inventory the tools
List every tool, MCP server and skill a workflow could call, and mark which ones can write or delete.
Write the launch policy
Name the tasks allowed to run unattended and the ones that stay single-agent.
Log at creation
Record run ID, orchestration version and stage outputs the moment a run starts.
Set the cap low
Pick a session budget below your true ceiling so the in-flight overshoot stays trivial.
Run one read-only job
Scan one high-detail dataset and compare the output against a single-agent baseline.
Assign the owner
Put one named person on the orchestration code, the cleanup schedule and the spend review.
No built-in self-improvement means runs repeat their own mistakes
The workflow will not learn from its own runs. Dynamic Workflows has no built-in self-improvement today, so it cannot adjust itself based on how earlier runs went.
A wrong stage order or a bad combine rule repeats until a person edits the code or the prompts.
Managed Agents has adjacent machinery, not the same thing. Its memory captures what an agent learns as it works, and dreaming refines that memory between sessions. Dreaming is a research preview, and neither feature rewrites your orchestration program.
That leaves the learning manual and on you. Version the prompts and the orchestration code together, and prompt Claude differently on a schedule, so each fix is a deliberate change with a record behind it.
Score your migration before you flip it
Claude-only SDK turns portability into a real trade
A workflow can be versioned and reviewed and still run only Claude models, whatever endpoint carries the call. The Claude Agent SDK reaches Bedrock and Vertex, both of which serve Claude.
Neither will run a non-Claude model. For a team deciding where control lives, that is the last control the team does not hold: the vendor does.
OpenAI Agents SDK, LangGraph and CrewAI allow other vendors' models, according to the research. Swapping models there is a configuration change, not a rewrite of the orchestration.
If multi-model is a hard requirement, a thin framework layer kept beneath the workflow is the cheaper insurance now, before the code settles.
On the hosted side, Managed Agents bills each agent's tokens at standard model rates, then adds $0.08 per session-hour and $10 per 1K web searches, per the research write-up.
A wide scan spanning many session-hours in one month adds up fast. Price a representative month before you commit, not a single run.
So weigh it directly: choose Dynamic Workflows when Claude's capability and Managed Agents' operations are worth more than model portability. Keep a framework abstraction when running another vendor's model is non-negotiable. Both are defensible. Only the unexamined default is not.
⚠️ COMMON MISTAKE
Do not paste client files into a chat to test the workflow
Test orchestration on synthetic or public data first. A workflow's agents read whatever tools they are given, and a scan of real client material turns a debug run into a disclosure.
Frequently Asked Questions
Do I need to write code to use Dynamic Workflows?
Claude writes the orchestration program, so you are not authoring it line by line. You do need to read it, version it and review it, which means someone on the team should be comfortable reviewing scripts in Python or TypeScript.
How much does a workflow run cost?
A run has no separate price. Its agents' tokens bill at each model's rates, and Managed Agents adds $0.08 per session-hour and $10 per 1K web searches per the research write-up. Check Anthropic's pricing page for current rates before you commit a budget.
Can a workflow run past my budget cap?
Yes, slightly. When a session hits its cap, open runs pause with budget_reached, but each working thread finishes the request it already started. With 64 threads, expect up to 64 extra requests past the line.
Why did my session stop accepting new runs?
A session holds 10 open runs by default, idle ones included, and an idle run keeps its slot for its whole lifetime. Kill idle runs on a schedule and alert when you reach nine.
Does the Claude Agent SDK work with models other than Claude?
No. It supports Bedrock and Vertex endpoints but not non-Claude models. If you need multi-model routing, look at OpenAI Agents SDK, LangGraph or CrewAI instead.
Will my workflows improve on their own over time?
Not today. Dynamic Workflows has no built-in self-improvement, so the orchestration only gets better when a person changes the code or prompts. Memory and dreaming are adjacent research work, not built-in learning.
Migrate the scan, not the whole platform
Keep one-level subagents for small, bounded jobs where cost and tool permissions are easy to review. Choose Dynamic Workflows for broad parallel scans where the extra detail justifies the token spend.
Start with one read-only workflow, a hard budget cap set below your true ceiling, and a named owner for the orchestration code. Log run IDs at launch and clean up idle runs on a schedule.
If the first scan does not change a decision, stop there. If it does, you have a case for a second one, and a baseline to prove it against.