Claude Managed Agents Dynamic Workflows: Limits, Pricing and Setup

Anthropic released dynamic workflows for Claude Managed Agents in public beta on October 9. A lead agent can now write a program that coordinates other agents in stages and combines their results. Each run can launch up to 1,000 agents over its lifetime, with 64 threads working concurrently under the current limits.

That gives developers a hosted way to handle jobs such as reviewing a large document collection. The release also introduces some practical questions: how much work should be delegated, how to control the bill, and how an application knows the job actually succeeded.

What changed in Claude Managed Agents?

The October 9 launch thread describes a lead agent planning work across several phases. Anthropic handles the background execution through Managed Agents. Dynamic workflows already existed in Claude Code; this release extends the capability to agents developers deploy through the hosted service.

The orchestration is written as a program. It can pass one worker's result to another without asking the lead agent to coordinate every exchange. That leaves the main session available to communicate with the user while the larger job continues.

For a document review product, this suggests a useful structure: examine documents individually, reconcile disagreements, then produce a report that points back to the source material. The developer still needs to define what a satisfactory review includes. Splitting the work does not establish that every important passage was understood.

How to enable dynamic workflows

The multiagent configuration guide uses the managed-agents-2026-04-01 beta header and the multiagent_20261001 configuration type. Workflows are enabled by default with that type; developers can also set workflows.type to enabled explicitly.

The agent decides when to start a run. Its instructions should identify the workloads that justify one. A small question about a single file and a review of an entire archive have different coordination costs, even if both arrive through the same chat box.

Developers can provide predefined specialist agents or let the workflow define workers as it goes. Predefined agents allow a team to choose another model for particular steps. Existing sessions retain their original configuration, so an updated agent needs a new session to use the changed settings.

What the 1,000-agent limit means

The workflow-run documentation separates total agents from concurrency. A run can start 1,000 agents across its lifetime, while the current simultaneous-thread limit is 64. Anthropic says that concurrency figure can change.

A run lasts 24 hours by default, and a session can keep 10 runs open by default. Paused runs remain open. Waiting also consumes the run's lifetime, which matters when a workflow stops for an approval that nobody sees until the next morning.

Those limits make workload design worth doing before a large trial. A batch of independent files can use parallel workers productively. A task whose next step depends on the previous answer has less work available to distribute. Starting more workers can also create more results for the final reviewer to reconcile.

Pricing and budget controls

There is no separate workflow-run fee. Its model usage counts toward the session's token bill. The Managed Agents pricing documentation also lists runtime at $0.08 per session-hour while the session is running, alongside applicable model and tool charges.

A session budget pauses open runs when reached, although requests already underway can finish and take spending beyond that threshold. Budget headroom therefore matters when many workers are active together.

Anthropic's launch thread reports a test with 70 planted bugs in a 116,000-line codebase. A single agent found 14, 15 and 27 across three attempts; workflows found 66 in each of three attempts. Those are company-reported results from one test. The figures alone cannot establish the cost per useful finding or the improvement on a different repository.

Check the work behind the completion event

A run marked completed can still contain failed worker tasks. The client needs to inspect thread errors and check the output against the requested work. Reconnecting clients must also retrieve missed events, because a new event-stream connection only delivers new events.

For an initial rollout, a bounded, read-only review is a sensible test. Give it a fixed set of inputs and compare its report with a known answer or human review. Record omitted items and false positives alongside runtime and spending. That makes it possible to judge whether the added coverage is worth the extra coordination before letting the workflow modify systems.

I’m Paras. I work at the intersection of AI, engineering and distribution.

If you’re building an AI product and want help turning launches, technical updates or product thinking into content that developers and founders actually read and share, I’d be happy to work with you.

Book a 30-minute call.