Dynamic Workflows in Claude Managed Agents: When to Fan Out, What It Costs and How to Watch a Run

Claude Managed Agents can now write and run dynamic workflows, in beta since October 9, 2026. An agent writes a small program that runs many agents in phases and combines their results. Anthropic’s server runs that program in the background as a workflow run.

Two more platform changes landed the same week. On October 14, scheduled deployments for Claude Managed Agents reached Claude Platform on AWS, alongside the OpenTelemetry export beta. On October 15, fast mode for Claude Opus 5.5 left research preview. This post explains workflows in plain terms, when an agency would use one, what it costs, its limits, and how to watch a run. It ends with fast mode and how OpenAI and Google compare.

The short version: a workflow is for jobs with many similar pieces, such as reading 300 documents or auditing 400 pages. There is no separate fee. You pay tokens for every agent plus $0.08 per session-hour, so set a session budget when you create the session. You cannot add one later. Small jobs still belong to a single agent.

What dynamic workflows in Claude Managed Agents do

A normal agent works through a task turn by turn. With a workflow, the agent writes a plan as code instead. The code starts agents, groups them into named phases, passes results between them and decides the next step.

Anthropic’s multiagent orchestration guide lists three ways one agent can hand off work:

The key difference is who runs the show. With subagents, the agent decides each step. With a workflow, the program does, so the main agent stays free to talk to the user. The agent cannot send follow-ups to a run’s agents, and the server archives each one when the run ends.

The agent decides when to start a run, based on the user’s message and its system prompt. No separate API call starts one.

Turning workflows on

Everything sits under the managed-agents-2026-04-01 beta header. The release notes say to set the agent’s multiagent field like this:

{
  "multiagent": {
    "type": "multiagent_20261001",
    "workflows": { "type": "enabled" }
  }
}

One detail matters for agencies. The guide says subagents and workflows are both on by default under the multiagent_20261001 type. So an agent moved from the older coordinator type can start runs without anyone asking for it. To block that, send "workflows": {"type": "disabled"} in the same update.

Then tell the agent in its system prompt when to start a run. Anthropic’s example tells a contract reviewer to run a workflow for more than a few contracts and handle one or two itself. The guide suggests rules on failures, a time limit, and a plan-first step. It also notes there is no enforced approval step. "Describe the plan and wait" is only an instruction in the prompt.

When an agency should use a workflow

A workflow fits when the same step repeats across many items, or when findings need a second pass. Agency examples:

• Content audits. One agent per page across a 400-page association site, then a phase that merges and ranks the findings.
• Migration prep. Map every old content type and field before a CMS move, then have a second phase check the map.
• Document review. Read every grant report or vendor contract for one clause, then reconcile what the first pass missed.
• Research. Read many sources in parallel and cross-check claims before writing one summary.

A single agent is still the better choice for short tasks, steps that depend on each other, and anything where the user needs to steer midway. Anthropic’s guide says to keep runs for tasks that need them, since every agent in a run uses tokens.

Inline agents a workflow defines use the session agent’s model. To run a cheap model for the reading phase, create that agent separately and list it under workflows.predefined_agents. Anthropic’s own example lists a claude-haiku-5-5 researcher.

Workflow run limits in Claude Managed Agents

Anthropic’s workflow runs page lists these limits:

Only the main agent starts runs, and runs do not nest. When an agent fails, the server usually reruns it once on a new thread. That means a run can do the same work twice, so tools that write data should be safe to call twice.

Model requests from a run count toward your normal Messages API rate limits. A run of 64 agents can hit them quickly. A thread that runs out of retries fails, and the run may end with a program_error that does not name the cause.

What a workflow run costs

A run has no separate price. Anthropic’s pricing page bills Claude Managed Agents on two lines: tokens at each model’s normal rate, and session runtime at $0.08 per session-hour while the session is running. Web search adds $10 per 1,000 searches. The Batch API discount does not apply.

Here is our own rough math, not Anthropic’s. Say a run reads 300 documents, and each agent uses 20,000 input tokens and 1,500 output tokens. On Opus 5.5 at $4 and $20 per million, that is about $33 in tokens. On Haiku 5.5 at $0.10 and $0.50, it is under $1. Thinking tokens, retries and the merge phase add to both.

The budgets guide says the cap is checked between model requests. At the cap, every open run pauses, and spend can pass the cap by one request per working agent. Raising or removing the budget resumes the runs. A paused run’s 24-hour lifetime keeps counting, so a forgotten pause can end in timeout_error.

Watching a run

Runs report on the session’s event stream through workflow_run.* events:

• workflow_run.created: the run started, with its name and planned phases.
• workflow_run.phase_started and phase_ended: progress through phases.
• workflow_run.status_idle and status_running: paused, often at the budget, and resumed.
• workflow_run.error: an error, or a refused start. It is not the end of the run.
• workflow_run.status_ended: always last, with a result.

Three cautions from the docs. A completed result means the program finished, not that the work passed, so check each thread. Run events do not trigger webhooks. And you cannot see the program’s code during the run, though you can ask the agent to print it afterward.

For dashboards, use the OpenTelemetry export that launched October 14. It traces Claude Managed Agents sessions, and you can group a whole session by anthropic.session.id. The workflow runs page does not mention OpenTelemetry, so we have not confirmed how run phases appear in traces. Our post on Claude OpenTelemetry tracing covers setup and what to keep private.

How this differs from dynamic workflows in Claude Code

We covered dynamic workflows in Claude Code in June. The idea is the same: Claude writes a script that runs many agents in phases. The product is different.

Claude Code’s workflows guide describes a tool for a developer at a keyboard. You ask for a workflow or type ultracode, approve the plan, and watch it in /workflows. It runs up to 16 agents at once by default, and saved scripts become reusable commands. The Claude Code docs have changed since our June post, so use the current guide for details.

Claude Managed Agents workflows run on Anthropic’s servers inside an API session. Your application or a schedule starts the session, the agent decides when to start a run, and your code follows the events. Use Claude Code for work in a repository. Use Managed Agents for work a client system runs without a person at a terminal.

Scheduled deployments reach Claude Platform on AWS

Scheduled deployments let a Claude Managed Agents agent start sessions on a cron schedule, such as a weekly content scan every Friday evening. Since October 14 they also work on Claude Platform on AWS. There, each run creates its session as an IAM role in your AWS account. Set execution_identity on the agent first, or creating the deployment returns a 400 error.

A deployment’s budget applies to each run, not the total. Anthropic’s AWS guide also says a session there can run for up to 6 hours without user events before it needs reauthentication. The docs do not say how that affects a long workflow run. Test before relying on overnight runs on AWS. This is separate from Claude’s scheduled tasks, which run in the Claude apps.

Fast mode for Opus 5.5 leaves research preview

On October 15, fast mode for Claude Opus 5.5 left research preview. You no longer request access or send the fast-mode-2026-02-01 header, though old requests that send it still work. Start, Build and Scale usage tiers now get a default fast mode rate limit.

Anthropic’s fast mode guide says it gives up to 2.5 times more output tokens per second. It does not speed up time to the first token. It costs $8 input and $40 output per million tokens, double the standard Opus 5.5 rate.

Fast mode works on the Claude API, including Claude Managed Agents through the agent’s model.speed setting. It also works on Microsoft Foundry deployments hosted on Azure, but not on Claude Platform on AWS. The docs do not say whether a workflow’s inline agents run fast too. Check usage before a large run on a fast agent, since a workflow multiplies the doubled price.

How OpenAI and Google handle fan-out

The other platforms offer similar delegation with different limits. OpenAI’s Agents API, which runs the Codex harness, has a multi_agent setting with max_concurrent_subagents. The coordinator delegates to subagents rather than writing a phased program. We covered its launch in our OpenAI DevDay 2026 recap.

Google’s Antigravity SDK subagents page describes self-cloning and custom subagents, each with its own context window. Our post on the Antigravity SDK and managed agents explains how Google hosts them.

Frequently Asked Questions