Anthropic's Claude Now Orchestrates 1,000 Agents, Finding 66 of 70 Bugs
Claude's dynamic workflows exit research preview with a new multiagent API type, letting a lead agent plan and orchestrate up to 1,000 subagents per run.
- Claude Managed Agents dynamic workflows are now in public beta on the Claude Platform.
- Enable with multiagent type
multiagent_20261001; Claude writes the plan and orchestrates phases. - A single run can orchestrate up to 1,000 subagents, with results merged at the end.
- In a 70-bug test on 116k lines, workflows found 66/70 across three runs vs 14-27 for a single agent.
- Best for repo-wide bug hunts, migrations, security audits, performance reviews, and architecture analysis.
- Start scoped: Claude Code users can run
/claude-api managed-agents-onboard bug-hunter.
Claude’s managed workflows can now orchestrate up to 1,000 agents
Anthropic has moved Claude Managed Agents dynamic workflows from research preview to public beta on the Claude Platform. A lead agent can plan a task, divide it among specialized subagents, run those assignments in phases, verify the findings, and merge the results. Developers enable the feature with the versioned multi-agent type multiagent_20261001.
The public beta raises the per-run ceiling to 1,000 managed agents. The earlier local research preview supported about 16 concurrent subagents because of resource constraints. Those figures describe different limits: the new ceiling covers agents orchestrated during a managed run and does not imply that all 1,000 execute simultaneously.
| Detail | Public beta |
|---|---|
| Orchestration model | Lead agent with phased subagents |
| Maximum scale | Up to 1,000 agents per run |
| Configuration type | multiagent_20261001 |
| Execution | Managed background workflow |
| Primary trade-off | Higher token use and longer runtime |
A 70-bug test shows the gain
Anthropic evaluated the system by planting 70 bugs in a 116,000-line codebase. A single agent found 14, 15, and 27 bugs across three runs, while the dynamic workflow found 66 bugs in each run.
| Approach | Run 1 | Run 2 | Run 3 | Recall range |
|---|---|---|---|---|
| Single agent | 14 | 15 | 27 | 20.0% to 38.6% |
| Dynamic workflow | 66 | 66 | 66 | 94.3% |
The workflow produced higher recall and lower run-to-run variance in this synthetic benchmark. Parallel agents can inspect separate areas of a repository, compare overlapping findings, and verify suspected defects before the lead agent assembles the report.
The published results do not establish performance on every codebase. They also leave open questions about precision, token consumption, latency, duplicate findings, and the effort required to validate proposed fixes. Teams should measure those factors against their own repositories and defect sets.
Claude writes the runtime plan
A dynamic workflow is a JavaScript orchestration program that Claude generates for the requested task. The managed runtime executes that program in the background, allowing the main session to remain available while subagents work through their assignments.
Each subagent receives a bounded part of the larger objective and its own working context. The lead agent can organize those assignments into phases, use later agents to review earlier output, and revise the plan as evidence accumulates. This structure extends effective coverage beyond the material one agent can inspect closely in a single context window.
The generated plan deserves the same scrutiny as other automated execution logic. Developers should inspect task boundaries, permitted tools, expected artifacts, and verification criteria before assigning a large budget or broad repository access.
Where parallel agents fit
Managed workflows suit tasks that divide into many independent or partially overlapping investigations. Strong candidates include:
- Repository-wide bug hunts that require file-by-file inspection
- Framework, language, or API migrations divided by package or module
- Security audits using independent reviewers and verification passes
- Performance investigations spanning services, traces, and configuration
- Dependency upgrades with separate compatibility checks
- Research projects that compare many sources or competing explanations
Small, tightly scoped changes usually favor a single agent because orchestration adds planning time, synthesis work, and token consumption. A one-file edit or a question that fits within one context can cost more and finish later when distributed across a workflow.
Token budgets and permissions need limits
Token use can grow with the number of agents, the size of their contexts, the number of phases, and the amount of cross-checking. Anthropic recommends beginning with a narrowly defined task and increasing scope after measuring cost, runtime, and output quality.
The earlier preview spawned subagents in acceptEdits mode and passed them the parent agent’s tool allowlist, regardless of the session’s permission mode. File edits could therefore proceed automatically, while shell commands, web requests, and MCP tools outside the allowlist could still pause execution for approval.
Public-beta behavior may change, so teams should confirm current permission semantics before unattended runs. A restricted allowlist, isolated credentials, repository backups, branch protection, spending caps, and execution logs reduce the impact of an incorrect plan or an overbroad task.
Starting with a bounded run
Claude Code users can scaffold Anthropic’s bug-hunter template with the onboarding command:
/claude-api managed-agents-onboard bug-hunterDevelopers integrating through the API can use the multi-agent configuration shown below as the core of a request. Required surrounding fields may vary by SDK or endpoint, so the current Agent quickstart remains the source for complete request and authentication details.
{
"agent": {
"multiagent": {
"type": "multiagent_20261001"
}
},
"task": "Audit this repository for SQL injection vulnerabilities"
}Claude then generates the orchestration script, chooses how to divide the work, runs the subagents in phases, and returns a synthesized result. A useful first run should define the repository scope, excluded paths, permitted tools, output format, verification standard, and token budget.
Public beta turns Claude into a job runner
The release gives developers a managed orchestration layer for work that exceeds one agent’s practical coverage. The 1,000-agent ceiling expands the size of a single run, while the versioned configuration provides a repeatable integration point for testing.
Public beta still carries operational uncertainty around API changes, cost, permissions, and workload-specific accuracy. Teams evaluating the feature should compare it with single-agent runs on the same tasks and track recall, precision, latency, token use, and reviewer time. Those measurements determine whether parallel orchestration earns its additional complexity.