Dynamic Workflows in Claude Managed Agents: Limits, Cost, and What to Check

Starting many agents is the easy part of multi-agent work. The hard part is splitting the work, passing results between agents, and knowing what actually finished. On 9 October 2026 Anthropic shipped a feature that moves that part into code: dynamic workflows in Claude Managed Agents.

Disclosure: This is a tool read, not a measurement. I have not run dynamic workflows myself yet. Every limit, price, and behavior below comes from Anthropic's documentation, checked on 11 October 2026, and the feature is in beta, so check the links before you rely on a number.

What a dynamic workflow is

Claude Managed Agents is Anthropic's hosted agent runner. You define an agent, start a session, and talk to it through events. Anthropic runs the agent loop. The sandbox runs in Anthropic's cloud or on your own infrastructure.

A dynamic workflow is, in Anthropic's words, "a program that an agent writes to run many agents and combine what they return". The server runs that program in the background as a workflow run. The program can:

1. Run many agents at the same time.
2. Pass one agent's result to another agent.
3. Decide which agents run next, and write their prompts.
4. Repeat work, for example revising a draft until a review passes.
5. Handle a failed agent, or let the failure end the run.

Anthropic's own example is a contract review. You ask which of 300 contracts have a change-of-control clause. The agent starts a run with two phases, "Read the contracts" and "Reconcile the findings". When the run ends, the agent answers: "41 of the 300 contracts have one."

The important line in that picture is the dashed one at the bottom. Your agent does not read every agent's output. The program collects the results and passes them on. Your agent gets one turn at the end to read what the run did.

Turning it on

You set the agent's multiagent field to the new type:

{
  "multiagent": {
    "type": "multiagent_20261001",
    "workflows": { "type": "enabled" }
  }
}

With this type, subagents and workflows are both on by default. If you want workflows only, add "subagents": {"type": "disabled"}. The older coordinator type can delegate to subagents, but it cannot start workflow runs.

There is no API call that starts a run. You describe the work in a user.message, and the agent decides whether and when to start one. So the system prompt is where you steer it. Something like:

For any task that covers more than 20 documents, start a workflow run.
Split the documents into batches. If an agent fails, retry it once,
then report the failure instead of ending the run.

Permission policies apply to the tools the run's agents call, not to starting the run. If a tool needs approval, that approval still happens.

Subagents or a workflow?

The same agent can use both, so the question is which one fits the task.

With subagents, your agent hands out each task and reads each report itself. A subagent's thread stays until you archive it, so your agent can send it follow-up questions. Delegation is one level deep, and a session can have at most 25 child threads at a time.

With a workflow, a program hands out the work. Results pass from agent to agent in code. Your agent cannot send follow-up messages to a run's threads, and the server archives them by the end of the run. Only the agent on the main thread can start a run, so runs do not nest.

My rule of thumb: if you need a conversation with a specialist, use a subagent. If you have a pile of similar pieces, such as documents, files, or tickets, use a workflow.

The limits in beta

The docs also say the server has other limits on workflows "that aren't listed here". A session can start any number of runs over its life, but only 10 can be open at the same time.

A run is either running or idle until it ends. It goes idle when it pauses, for example at the session budget. The five ways it can end are completed, stopped, timeout_error, program_error, and thread_limit_error.

What a run costs

A run has no price of its own. Its agents use tokens, billed like any other tokens in the session at each model's rate. On top of that, Claude Managed Agents bills session runtime at $0.08 per session-hour, counted while the session is in the running state.

The control is a session budget: an optional hard cap on the session's spend, priced at public list rates. Two details matter:

• You can only attach a budget when you create the session. Adding one to a session that has no budget is refused with a 400 error.
• At the budget, every open run pauses. Each working thread finishes the request it already started, so a run can go over the budget by one request per working thread. Raising or removing the budget resumes the runs.

One trap: a paused run's lifetime keeps passing. A run that stays paused at the budget for a day ends with timeout_error.

Seven things I would check before trusting a run

These are the parts of the docs that are easy to miss, and they are the ones that would hurt in client work.

1. completed does not mean the work passed. A run can end completed even when work on some threads failed, or a thread could not be created. To find failed work, you read each of the run's threads. A finished job is not the same as a correct job, which is the same idea as treating uncertain as a state, not an error.

2. Tools must be safe to call twice. The server can run a failed agent again on a new thread. The docs say it plainly: a run can create more than one thread for the same piece of work, so make the tools your agents call safe to call twice. If a tool sends an email, writes a record, or moves money, it needs an idempotency key. I wrote about that boundary in one authorization, one commit boundary.

3. Runtime keeps billing while nothing happens. While a run is running, the session stays running, even when none of its threads is working. Session runtime is billed by that status. A long run that mostly waits still costs runtime.

4. Rate limits are shared. A run's model calls count toward your normal Messages API rate limits, together with your other traffic. 64 agents at once can use up those limits quickly, and the server also limits how much all of your organization's sessions do each minute. If a thread runs out of retries, the workflow may end the run with program_error, which does not name the cause. Retries and backoff still matter, even when the platform does some of them for you.

5. Runs do not nest. Only the agent on the main thread starts runs. If your design needs a run inside a run, it needs a different shape.

6. You can read the program it wrote. After a run ends and the session is idle, you can ask the agent to print the workflow it started the run with, word for word. I would save that for every run that matters. It is the closest thing to an audit trail for how the work was split.

7. You can limit which agents a workflow uses. By default a workflow can define its own agents. You can turn off these "inline agents" and give the workflow a list of predefined agents instead. If you turn inline agents off with an empty list, the request fails with a 400 error.

Where I would use it, and where I would not

Good fit: work with many similar pieces. Contract review, document extraction across a large folder, audits, migrations across many files, research that fans out and then needs one summary. This is the shape Anthropic built it for.

Not yet for: daily work in your own repository, where you want to see and steer each step. And not for regulated data with strict retention rules: sessions store conversation history, sandbox state, and outputs on Anthropic's side, and Managed Agents is not currently eligible for Zero Data Retention or HIPAA BAA coverage.

Not as your only control. The budget caps spend, but it does not check correctness. The checks in the previous section are still your job.

If you try it

• Create a test agent with the multiagent_20261001 type.
• Create the session with a small budget. You cannot add one later.
• In the system prompt, say when to start a run and what to do when an agent fails.
• Follow the workflow_run.* events on the session's event stream instead of polling.
• When the run ends, read each thread's events, not only the run's result.
• Add up the run's real usage: list the session's threads and sum usage for the threads with that run's workflow_run_id.
• Ask the agent to print the workflow it wrote, and keep it.

Sources, all checked on 11 October 2026: the Claude Managed Agents overview, workflow runs, multiagent orchestration, session budgets, pricing, and the platform release notes.