Claude's Dynamic Workflows: when the agent writes its own orchestrator

What it is

A beta feature inside Claude Managed Agents where the lead agent writes a small program — a workflow — that spawns and coordinates other agents in phases, then merges their results. Anthropic put dynamic workflows for Claude Managed Agents into public beta on October 9, 2026: an agent writes a program that runs many agents in phases and combines their results, and the server runs it in the background. It sits on top of the existing Managed Agents multi-agent sessions primitive, so the loop isn't a graph you hand-wire — the model decides the fan-out.

The next-work-session test

You're a developer with a 100k-line repo and a vague ticket: "audit this service for auth bugs before Friday." Today you'd write a planner prompt, a worker prompt, a reducer prompt, and glue code to shard the files. With dynamic workflows you hand the lead agent the repo and the brief, and it writes the shard-and-merge program itself, kicks off a batch, and reports back when done. The thing that changes in your next session: you stop maintaining orchestration code and start writing evals against the merged output. That's a real shift — and also where it gets risky, which we'll come back to.

Pricing

Managed Agents itself is paid, and dynamic workflows don't appear to carry a separate line item — they bill through the same session. Claude Managed Agents, Anthropic's hosted agent runtime, bills two things: the model's standard token rates and $0.08 per session-hour of running time, according to Anthropic's pricing page. Claude Managed Agents bills model tokens plus $0.08 per session-hour of running time. That hourly rate is cheap; the token side is not. A long multi-agent run can quietly rack up a bill — a 4-hour research agent session on Opus 4.6 is different. That's $0.32 in runtime, but if the agent is actively reasoning through complex tool chains, you might burn through 200k+ input tokens and 50k+ output tokens. The token bill alone could exceed $1.25 before caching kicks in, and that's a single agent. Multiply by a 1,000-agent workflow and the napkin math gets uncomfortable fast. Treat these as the vendor's own session examples, not your workload.

What we'd actually use it for

Narrower than the pitch. The vendor example is a sweeping codebase audit — in a company-reported bug-finding test, a workflow found 66 of 70 planted bugs in a codebase with 116,000 lines. A single agent found between 14 and 27 per run. Impressive, but it's one benchmark Anthropic ran on itself. The honest use case is embarrassingly parallel batch jobs where you already know what "good" looks like per shard: triaging a backlog of error reports, running the same structured extraction over N documents, generating per-module test scaffolds. Anything where you can write a cheap eval on the per-agent output before trusting the merge.

Limits

A few things to know before you wire this into a product:

• The headline "1,000 agents" number is a run total, not simultaneous. Per community corrections to the docs, the limit is 1,000 total agent starts per run with 64 running concurrently. Fan-out is capped.
• Still beta. You can now let a Claude Managed Agents agent use dynamic workflows, in beta with the managed-agents-2026-04-01 beta header, and the overall product itself is beta too — behaviors can change.
• Compliance footnote worth catching: because sessions are stateful, Managed Agents is not currently eligible for Zero Data Retention. If your org requires ZDR, this is a non-starter today.
• The 66/70 bug-finding result is a single Anthropic-run test. That is a striking result, but it comes from one test; it does not establish that workflows will improve every kind of task. Treat it as a demo, not a benchmark you can quote to your team.
• You're giving the model orchestration authority. Debugging a run where the agent wrote and executed its own fan-out plan is harder than debugging a graph you authored. Observability and per-phase evals aren't optional.

Try it if

• You already have Managed Agents in your stack and a batch workload that's painful to shard by hand.
• Your "quality" check for the output is cheap and automatable (an eval, a schema, a test suite).
• You're comfortable paying for exploration — a few runs to feel out token costs before you commit.
• You want to spend your next sprint on evals, not on retry/backoff code.

Skip it if

• You need Zero Data Retention or run under strict data-residency rules.
• Your task is sequential or has tight inter-agent dependencies — this shines on parallel work, not pipelines.
• You can't afford variance in cost per run; dynamic plans mean dynamic bills.
• You don't have evals yet. Giving an agent orchestration authority without evals is how you get a confident, expensive, wrong answer.

Full release context is in the Claude Platform release notes and the Managed Agents overview.