Multiagent orchestration in Claude took a large step on 9 October 2026, when Anthropic opened dynamic workflows in Claude Managed Agents as a public beta. The feature lets one agent write a plan, run it across many other agents in phases and combine what they return, while the server executes the whole job in the background. Anthropic calls it “a new type of multiagent orchestration, built for your most ambitious workloads.”
The scale is the headline. A single workflow run can start up to 1,000 agents over its life, with up to 64 working at once. In an internal test reported by The Decoder, Anthropic hid 70 bugs in a 116,000-line codebase: one agent found between 14 and 27 per run, while a dynamic workflow found 66 every time.
This article explains what the beta adds, how multiagent orchestration works on the Claude Platform, how to switch it on and what it costs. We also set out the limits behind the 1,000-agent figure, work through a token bill for a realistic job and list the safety and reliability points developers should check before letting a run loose on real systems.
Table of contents
- The Multiagent Orchestration Beta Anthropic Launched on 9 October
- How Multiagent Orchestration Works in Claude Managed Agents
- Turning On Multiagent Orchestration With Dynamic Workflows
- Multiagent Orchestration Limits Behind the 1,000-Agent Headline
- The 70-Bug Multiagent Orchestration Test and What It Shows
- What Multiagent Orchestration Costs
- Safety, Permissions and Reliability in Multiagent Orchestration
- Multiagent Orchestration From Claude Code to the Claude Platform
- Who Should Use Multiagent Orchestration Now
- The Bottom Line
- References and Further Reading
The Multiagent Orchestration Beta Anthropic Launched on 9 October
The announcement came in two places on the same day: a dated entry in the Claude Platform release notes and a short video from Anthropic’s ClaudeDevs account on X.
Dynamic workflows: multiagent orchestration in one sentence
A dynamic workflow is a program that an agent writes for a specific task. The program runs many agents in phases, passes their results from one phase to the next and combines them at the end. Anthropic’s server runs it as a “workflow run” while the main agent stays free to talk to the user or report progress.
The release note and the launch video
The release note reads: “You can now let a Claude Managed Agents agent use dynamic workflows, in beta with the managed-agents-2026-04-01 beta header. For work with many pieces, such as reviewing hundreds of documents, the agent can write a workflow.” To turn it on, developers set the agent’s multiagent field to the new multiagent_20261001 type.
The 58-second video shows the idea with a legal task. An agent is asked to find change-of-control clauses in 300 contracts. It writes a workflow with two phases, “Read the contracts” and “Reconcile the findings”, the server runs it in the background, and the combined answer comes back: “41 of the 300 contracts have one.” The video ends on budgets: runs pause when the session hits its spending cap and resume when it is raised.
How this differs from May’s multiagent orchestration
This is not Anthropic’s first multiagent orchestration feature on the platform. On 19 May 2026 it put multiagent orchestration, outcomes and webhooks into public beta in Managed Agents, and launched dreaming as a research preview. That version let a lead agent delegate pieces of a job to specialist subagents, each with its own model, prompt and tools.
The difference in multiagent orchestration is who coordinates. With subagents, the lead agent decides turn by turn what happens next and reads every report. With dynamic workflows, Claude writes the coordination as code, and the program moves context and results between agents “without Claude’s direct involvement,” in the words of Anthropic’s documentation. That frees the lead agent’s context window and lets a run grow far larger.
How Multiagent Orchestration Works in Claude Managed Agents
Anthropic’s multiagent orchestration documentation now describes three ways for the agent a session runs to get help with its work. The new type lets an agent use all three together.
Three ways to hand off work in multiagent orchestration
| Approach | What happens | Best for | Default |
|---|---|---|---|
| Subagents | The agent delegates tasks and reads each report; it can send follow-ups | Specialists you define, back-and-forth work | On |
| Dynamic workflows | The agent writes a program that runs many agents in phases in the background | Audits, migrations, deep research, cross-checking | On |
| Advisor | The main thread consults a stronger model mid-turn and keeps doing the work | One agent that needs judgment at key moments | Off |
Anthropic’s guidance is that dynamic workflows suit “most work that needs more than one agent”. Subagents remain the better choice when the lead agent needs to follow up with a specialist after it reports, because a subagent’s thread stays available until archived. A workflow run’s threads cannot receive follow-up messages and are archived by the server when the run ends.
Predefined and inline agents
Every agent in a run is one of two kinds. A predefined agent is one the developer has already created and listed, with its own model, system prompt, tools and skills. An inline agent is defined on the fly by the lead agent or the workflow, and uses the lead agent’s model and tools. Up to 20 predefined agents can be listed for subagents, and a separate 20 for workflows.
That detail has a cost consequence. An inline agent always runs on the same model as the lead agent, so a workflow led by an expensive model will, by default, run every worker on it too. To use a cheaper model for the bulk reading, developers must create those workers as predefined agents and list them in workflows.predefined_agents.
Shared sandbox, separate threads
All agents in a session share the same sandbox, filesystem and vault credentials, but each works in its own session thread with its own conversation history. The lead agent reports in the primary thread, and new threads appear as work is handed out. Delegation is one level deep: an agent that itself has multiagent orchestration enabled cannot be listed as another agent’s helper.
Turning On Multiagent Orchestration With Dynamic Workflows
Switching on this form of multiagent orchestration is a configuration change rather than a new API call. The harder part is telling the agent when a workflow is worth the tokens.
The multiagent block
With the new type, subagents and workflows are both on by default, so the smallest valid block is a single line. A developer who wants workflows only adds a line that disables subagents:
{
"multiagent": {
"type": "multiagent_20261001",
"workflows": { "type": "enabled" },
"subagents": { "type": "disabled" }
}
}The beta header managed-agents-2026-04-01 is required, as for the rest of Managed Agents. A session copies the setting when it is created, so changing the agent later does not affect sessions already running. The ant__ prefix is now reserved for tool names, and an agent with a custom tool using it will fail to update until that tool is renamed.
Telling the agent when to start a run
There is no “start workflow” endpoint. The developer describes the work in a user message, and the agent decides whether a run is needed. Anthropic’s example system prompt for a contract reviewer says: “When you’re asked to review more than a few contracts, start a workflow run that reads them in parallel and combines the findings. Review one or two contracts yourself, without a run.”
The documentation suggests going further, with instructions on how to split the work, what to do when an agent fails and how long a run may take. One example asks for a second agent to review every contract, “not only the ones where the first agent found something”, and for failures to be listed as not covered rather than ending the run.
Moving from the coordinator type
Agents built on the older coordinator type can delegate to listed subagents and consult an advisor, but cannot start workflow runs or define helpers themselves. Moving to the new type means sending the whole multiagent block in one update. Anything left out takes its default, so an update that omits the subagent list wipes it. Teams migrating existing agents should copy the list and advisor setting into the new block explicitly.
Multiagent Orchestration Limits Behind the 1,000-Agent Headline
The headline figure for multiagent orchestration, “up to 1,000 agents”, is accurate but easy to misread. The workflow runs documentation sets several separate limits, and only one of them is 1,000.
The published multiagent orchestration limits
| Limit | Managed Agents (hosted) | Claude Code (local) |
|---|---|---|
| Agents working at once in one run | 64 (not guaranteed) | 16, fewer on smaller machines |
| Agents started over a run’s life | 1,000 | 1,000 |
| Run lifetime | 24 hours by default | Tied to the local session |
| Runs open at once | 10 per session by default | Not stated |
| Subagent threads (for comparison) | 25 child threads at a time | Not applicable |
The Claude Code figures come from Anthropic’s Claude Code documentation as we reported them when covering Hub Mode, Anthropic’s unreleased task orchestrator. The hosted version’s main gain is concurrency: four times as many agents working at the same moment, without tying up a developer’s laptop.
What 1,000 agents really means
The chart sets the hosted limits side by side. The 1,000 figure is a lifetime ceiling on agents a run may start, not a measure of how many work in parallel.
Hosted dynamic workflow limits, as a share of the 1,000-agent lifetime cap
Simple arithmetic shows the shape of a full run. With 64 agents working at once, a run that uses all 1,000 needs at least 16 waves of work (1,000 divided by 64 is 15.6). If each wave takes ten minutes, that is over two and a half hours, comfortably inside the 24-hour lifetime.
Two more details matter. When a workflow asks for agent number 1,001, the server refuses and the run ends with a thread_limit_error. And because the server can rerun a failed agent on a new thread, a run can show more than 1,000 threads in total.
Rate limits still apply
A run’s model requests count against an organisation’s normal Messages API rate limits, alongside its other traffic. Sixty-four agents working at once can hit those limits quickly. When a request is rate limited, the server retries it; if retries are exhausted, that agent’s thread fails, and if the workflow lets the failure end the run, the run ends with a generic program_error.
The 70-Bug Multiagent Orchestration Test and What It Shows
The most quoted number from the launch did not appear in the release note, the documentation or the video. The Decoder reported it with Anthropic as the source, and other outlets repeated it with per-run figures.
The reported numbers
Anthropic planted 70 bugs in a 116,000-line codebase. Across three runs, a single agent found 14, 15 and 27. The dynamic workflow found 66 in each of its three runs.
Share of 70 planted bugs found, per run
On average the single agent found 18.7 bugs, so the workflow found about 3.5 times as many. Just as striking is the consistency: the single agent’s results varied by 13 bugs between runs, while the workflow’s did not vary at all.
What it leaves out
The multiagent orchestration test is Anthropic’s own, on planted bugs, and its details are not published. It says nothing about false positives, how many tokens each approach used, how long each took or which models ran. Planted bugs are also easier to define than real ones, which favours a method that inspects every file.
The Decoder also noted that a senior OpenAI engineer had recently called agent swarms a massive waste of tokens. The honest summary is that multiagent orchestration clearly improves coverage on a large, divisible search task, and that the cost of that coverage is the open question every team will need to answer for itself.
What Multiagent Orchestration Costs
Anthropic’s documentation is blunt about multiagent orchestration pricing: “A run has no price of its own.” There is no workflow fee, but every agent in a run uses tokens, and that is where the bill comes from.
Tokens, runtime and search
Managed Agents pricing has two parts. Tokens are billed at each model’s normal rates, with prompt caching discounts applied. Session runtime costs $0.08 per session-hour, measured to the millisecond and charged only while the session is running. Web searches cost $10 per 1,000.
Runtime is almost a rounding error. Even a run that used its full 24-hour lifetime would add $1.92 in runtime. The token bill depends on three choices: how many agents, how much each one reads and which model each one uses.
A worked example: 300 contracts
The table below estimates the reading phase of the job in Anthropic’s video. It assumes each of 300 worker agents reads 30,000 input tokens and writes 1,000 output tokens, which is 9 million input and 0.3 million output tokens in total, priced at current list rates without caching. These are our assumptions, not Anthropic figures.
| Worker model | Input price per million | Output price per million | Reading-phase cost |
|---|---|---|---|
| Opus 5.5 | $4.00 | $20.00 | $42.00 |
| Sonnet 5.5 | $2.00 | $10.00 | $21.00 |
| Haiku 5.5 | $0.10 | $0.50 | $1.05 |
The spread is 40 to one. Because inline agents inherit the lead agent’s model, a workflow led by Opus 5.5 would land on the top row by default. Listing a predefined Haiku 5.5 reader moves the same job to the bottom row, and the lead agent can still reconcile the findings on a stronger model. Adding the review pass Anthropic’s documentation suggests, a second agent per contract, roughly doubles the reading cost.
This is the same lever Spiral by Every described in May, running its lead agent on Haiku and its drafting subagents on Opus. Our guide to token cost control covers model routing and caching in more depth, and the pricing behind the cheapest row is explained in our coverage of the Claude Haiku 5.5 launch.
Budgets and the overshoot
The main cost control is a session budget, which caps the session’s spend with runs included. It has to be set when the session is created; Anthropic says “you can’t add one to an existing session.” When the budget is reached, every open run pauses, and raising or removing the budget resumes them.
The cap is not exact. Each thread finishes the model request it has already started, so “a run can pass the budget by one request for each working thread.” With 64 agents working, that is up to 64 extra requests. Teams should set the budget below their true ceiling by at least that margin.
Safety, Permissions and Reliability in Multiagent Orchestration
Multiagent orchestration against real systems multiplies every reliability and security problem a single agent has. The documentation flags several that developers should design for from the start.
Tools must be safe to call twice
“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,” the workflow runs page says. In practice that means any tool that sends an email, writes a record or moves money needs to detect and ignore duplicates. This is the same durability problem we covered in our report on Restate and durable execution for AI agents.
Credentials and MCP servers are shared
In multiagent orchestration, vault credentials are session-scoped, so every thread in a session can use them. MCP servers are declared per agent, which lets a developer give a research agent GitHub access without giving it to the lead agent. But inline agents use the lead agent’s MCP servers and tools, and cannot be restricted that way. To lock a run down to known agents, developers must turn inline agents off and list the ones allowed.
Web access got tighter on 7 October
Two days before the launch, Anthropic changed how web tools behave in Managed Agents. The web_fetch tool now fetches only URLs that have already appeared in the session, such as in a user message or a search result, which “reduces the risk of data exfiltration”. With limited networking, an environment’s allowed hosts now also apply to web search and web fetch.
For multiagent orchestration this matters in both directions. It limits what a compromised or confused worker can reach, and it means a workflow that needs particular sites must have those URLs or hosts supplied up front.
Knowing when a run is really done
A quiet session is not proof that the work is finished. “An idle by itself doesn’t mean that the work is done,” the documentation warns. The work is done only when every run has sent its workflow_run.status_ended event and, after that, the session goes idle with the stop reason end_turn. A run paused at the budget lets the session go idle while the run is still open, and the agent can start a new run when it reads a result, so client code has to keep checking. Developers should also read any failed threads’ events and check the output against the original task.
Multiagent Orchestration From Claude Code to the Claude Platform
Dynamic workflows, the newest form of multiagent orchestration, did not start on the platform. They began as a Claude Code feature and have moved outwards over four months.
The timeline so far
| Date | Milestone |
|---|---|
| 8 April 2026 | Claude Managed Agents opens in public beta |
| 19 May 2026 | Subagent multiagent orchestration, outcomes and webhooks enter public beta; dreaming in research preview |
| 28 May 2026 | Dynamic workflows arrive in Claude Code |
| 1 October 2026 | Dreams support Opus 5.5, Fable 5.1 and Sonnet 5.5 |
| 7 October 2026 | Tighter web fetch and allowed-host rules in Managed Agents |
| 9 October 2026 | Hosted dynamic workflows in public beta with multiagent_20261001 |
The Bun port as the showcase
Anthropic’s best-known example comes from the Claude Code launch. Jarred Sumner used dynamic workflows to port the Bun JavaScript runtime from Zig to Rust: roughly 750,000 lines of Rust, with 99.8% of the existing test suite passing, eleven days from first commit to merge. One workflow mapped Rust lifetimes for every struct field; the next ported every file in parallel, “with two reviewers on each file”; a fix loop then drove the build and tests until both ran clean.
Anthropic notes the port is “not yet in production”. It still shows the pattern the platform’s multiagent orchestration beta is built for: a huge, divisible job, independent workers, review by other agents and a loop that keeps going until checks pass.
Where this leaves Hub Mode
In August we reported on strings for an unreleased “Hub Mode” in Claude’s apps, a task board for sub-agents. The platform beta answers part of that story for developers, who can now follow a run by its phases and read each agent’s thread. A consumer-facing control surface for multiagent orchestration has still not been announced.
Who Should Use Multiagent Orchestration Now
The multiagent orchestration beta is aimed at developers building on the Claude Platform, not at people using the Claude apps. For them, the question is less whether the feature works than which jobs justify its token bill.
Good fits
Anthropic’s own list is audits, migrations, deep research and cross-checking. The common thread is work that splits into many independent pieces, where coverage matters more than speed and where a second agent can usefully check the first. Contract review, codebase-wide bug hunts, security reviews and large document collections all fit.
Poor fits
Small tasks are worse with multiagent orchestration, not better. Planning, handing out work and combining results all cost tokens and time, so a one-file change or a question that fits in one context window will usually be cheaper and faster with a single agent. Work with a single shared state that every step must update, such as a live booking, also divides badly.
A sensible first project
Anthropic recommends starting small, and Claude Code users can scaffold a starter agent with /claude-api managed-agents-onboard. A good first project is a job the team already does by hand, with a known answer to check against. Set a session budget, use a cheap predefined reader model, require a review phase and compare the result with a single-agent run on the same input.
Teams planning where agents fit in their operations may also want to read our analysis of how one stubborn agent can sway a multi-agent network, which shows why independent review matters.
The Bottom Line
The public beta turns multiagent orchestration in Claude from a delegation feature into something closer to a job runner. An agent can now write its own plan, run up to 1,000 helpers over a day-long run and hand back one combined answer, with budgets, phases and per-agent threads to keep it observable.
The evidence so far is promising but thin: one internal bug-hunting test and one showcase port. The economics of multiagent orchestration depend almost entirely on model choice, and the defaults point to the expensive end. Developers who list cheap predefined workers, set a budget with headroom and build tools that tolerate duplicates will get the most from the beta.
References and Further Reading
Multiagent orchestration (Claude Platform Docs)
Workflow runs (Claude Platform Docs)
Claude pricing, including Managed Agents
ClaudeDevs launch post and video (X)
Claude Managed Agents launch announcement
New in Claude Managed Agents: dreaming, outcomes and multiagent orchestration
Introducing dynamic workflows in Claude Code
Claude can now orchestrate up to 1,000 agents (The Decoder)
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.
