On October 9, 2026, Anthropic added hosted dynamic workflows to Claude Managed Agents in beta. The idea is deceptively simple and, for anyone running document-heavy operations, genuinely new: a Claude agent writes a small program, that program sends work to other agents in phases, checks what comes back, and combines the results into one deliverable, all while the main conversation stays free. Per Anthropic's documented limits, a single workflow run can call on up to 1,000 agents over its lifetime, with as many as 64 running at the same time, executed on Anthropic's servers as a background workflow run.
Managed Agents itself is not new. Anthropic launched the hosted agent infrastructure on April 8, 2026, as Wired reported at the time, letting businesses deploy long-running Claude agents without building the plumbing themselves. The October 9 beta is the next layer: instead of one agent doing one thing, one agent now coordinated many.
What actually shipped on October 9
Three things distinguish dynamic workflows from ordinary delegation, according to Anthropic's release notes and multiagent orchestration documentation, reviewed in detail by Kingy AI on October 9, 2026:
- The coordinator is a program, not a conversation. With subagents, the main agent delegates tasks and reads their reports. With dynamic workflows, a generated program passes context and results between worker agents and decides what happens next.
- The main thread stays free. Because the workflow runs server-side in the background, the end user can keep talking to the lead agent, ask progress questions, and get answers while the fan-out is still running.
- Phased execution with real limits. Up to 1,000 agents over the lifetime of a workflow run, with up to 64 concurrent, running in phases with results merged at each stage.
Technically, this is a Claude Platform API beta. Access requires the anthropic-beta: managed-agents-2026-04-01 header, and workflows are enabled through the agent definition's multiagent configuration (multiagent_20261001), where both workflows and ordinary subagents default to enabled. The lead agent still decides when to start a run, so prompts should specify the circumstances for using one, a detail that matters more than it sounds like it would.
Subagents vs. dynamic workflows: who coordinates the work
| Dimension | Ordinary subagents | Dynamic workflows |
|---|---|---|
| Coordinator | The lead agent, inline in conversation | A generated program, run server-side |
| Context passing | Reports read back into the main thread | Structured handoffs between phases |
| Main conversation | Busy while work runs | Free; progress questions anytime |
| Scale | A handful of task-specific agents | Up to 1,000 agent calls, 64 concurrent |
| Best for | Small, serial decompositions | Large, parallelizable, verifiable work |
The honest reading of that table: for most small jobs, ordinary subagents remain the right tool. Dynamic workflows earn their keep when the unit of work is clear, the documents are numerous, and the results need to survive a source check.
Where fan-out genuinely wins: extract, verify, write
The pattern Anthropic's documentation keeps pointing at is three-stage work: extract atomic facts from many sources, verify each fact against its original source with a separate worker, then write a synthesis that only uses what survived verification. Kingy AI's October 9 analysis proposes a concrete version of this test: give a run 12 public product documents (four products, three documents each), require a separate verification pass per document, and ask for a source-linked brief. That arithmetic produces 25 logical tasks, 12 extractions, 12 verifications, one synthesis. The same outlet is explicit that its cost examples are calculations, not measured results, a distinction we appreciate, since a faster answer with invented pricing is a failed answer.
For businesses, the transferable cases are easy to name:
- Audits and compliance reviews, where every claim in the final report should trace to a source document
- Migrations and RFPs, where dozens of vendor pages must be read, cross-checked, and compared
- Research briefs, where a single writer agent would otherwise rediscover every detail inside one long, expensive conversation
The verification stage is the part most teams will skip and most regret skipping. Parallel extraction without parallel verification just produces faster, more confident errors.
What it costs
Anthropic's Managed Agents pricing lists $0.08 per session-hour while an agent is in the running state, metered to the millisecond, per the pricing documentation reviewed on October 9, 2026. Web searches cost $10 per 1,000 searches, and every worker agent consumes tokens at its model's normal rates. There is no separate workflow-specific fee, but that is colder comfort than it sounds: runtime is cheap, tokens are not. At $0.08 per hour, 30 minutes of running time costs about $0.04 before any tokens are counted; a 25-task fan-out with strong models doing real reading can consume far more in model usage than in runtime.
Two operational details are worth knowing before you design around this. First, per Anthropic's October 7 release notes, web fetching requires a URL to have appeared in qualifying prior context, meaning a URL that exists only in an attached document or system prompt does not qualify. Second, session-level usage counts overlapping thread activity once, so budget from session totals, not by adding per-thread numbers.
The economic question to ask is total dollars per acceptable brief, not dollars per hour. If a verification pass raises cost by 30 percent but prevents the expensive errors that parallel extraction invites, that is a good trade. If the workflow merely re-reads the same cached documents four times, it is a bad one.
When an SMB shouldn't bother
This is where we disagree with the inevitable hype cycle. If your working day involves fewer than a few dozen documents, one well-prompted agent with a human reviewer will beat a 64-worker fan-out on cost, simplicity, and debuggability. Dynamic workflows pay off when three conditions hold: the work is genuinely parallel, the unit of output is verifiable against a source, and a failed run is expensive enough to justify the orchestration. Most marketing and operations work at small and mid-size companies meets none of the three yet.
The companies who should be paying close attention are those already past the automation threshold: running document-heavy audits, handling multi-vendor comparisons, or maintaining compliance evidence across hundreds of pages. For them, the significant change is not the 1,000-agent number. It is that the lead agent's program, not a human architect, now decides the shape of the work.
There is also a governance angle our own coverage keeps surfacing. More autonomous agents executing in the background mean more activity your access reviews need to cover, the same unregistered-agent risk we described in our shadow AI agents analysis. A fan-out of 64 concurrent workers with tool access is exactly the kind of thing that should appear in an inventory.
How to evaluate it before trusting it
Before running production work through the beta, we would want answers to the same scorecard any orchestration claims get measured against: time to final brief, total session cost, count of unsupported claims per source check, and document coverage. Pre-declared pass criteria, repeated runs, and a reviewer who grades outputs without knowing which arm produced them. Anthropic's beta makes all of that easier to test than it was a month ago, which is itself the point: the hard part of building agent systems was never the fan-out, it was knowing whether the merged result is true.
If you're weighing whether fan-out workflows fit the way your team handles research, audits, or document operations, that's exactly the kind of decision we help with.
Read next:
