On 9 October 2026 Anthropic added dynamic workflows to Claude Managed Agents, its hosted agent harness. The feature is in beta with the managed-agents-2026-04-01 beta header. An agent can now write a workflow, a program that runs many agents in phases and combines their results, and the server runs it in the background as a workflow run. The agent decides when to start one.

What Anthropic Shipped

The Claude Platform release notes for 9 October describe the feature for "work with many pieces, such as reviewing hundreds of documents". You turn it on by setting the agent's multiagent field to {"type": "multiagent_20261001", "workflows": {"type": "enabled"}}, guide the agent in its system prompt on when to start a run, and follow each run through workflow_run.* events on the session's event stream.

The multiagent orchestration docs place workflows next to two older options in the same multiagent block. With subagents, the agent delegates tasks itself and can send follow-ups. With an advisor, the agent consults an advisor model and does the work itself. With a workflow, the program passes context and results from agent to agent without the lead agent in the loop, while the main thread stays free to talk to the user and check on runs. Under the multiagent_20261001 type, subagents and workflows are both enabled by default.

Beta Status And Access

The Managed Agents overview says the whole product is in beta. Every Managed Agents endpoint requires the managed-agents-2026-04-01 beta header, which the SDK sets automatically. Access is enabled by default for all API accounts, and Anthropic says behaviours may be refined between releases. The same page says Managed Agents is not currently eligible for Zero Data Retention or HIPAA Business Associate Agreement coverage. The docs give no general availability date.

How A Run Works

The workflow runs docs describe three layers:

  • Run: one execution of a workflow. A session can have several open at once, 10 by default.
  • Phases: named stages, such as "Read the contracts" then "Reconcile the findings", reported as phase events.
  • Agent threads: each agent works in its own session thread on a prompt the program wrote. It is either an inline agent the workflow defines, which uses the session agent's model and a subset of its tools, or a predefined agent you list in workflows.predefined_agents (up to 20).

Each agent returns its result to the program, not to the lead agent. The program decides what runs next, can repeat a step until a review passes, and can handle a failed agent or let the failure end the run. When the run ends, the lead agent gets a turn to read what it did. Only the agent on the session's primary thread can start a run, so runs do not nest. A run lasts 24 hours by default, and the agent can set a shorter lifetime.

Running Many Agents In Parallel

Parallel work is the main use case in the docs: "A run's agents can work at the same time, so a long task can finish sooner than if one agent did each piece in turn." The documented limits for one run are 64 threads working at once (which Anthropic says it does not guarantee and can change) and 1,000 agents started over the run's life. A run that asks for more ends with thread_limit_error. Run threads do not count against the session's limit of 25 child threads.

The docs also set out what the feature leaves to the operator:

  • Starting a run is the agent's call. There is no API call to start one. Permission policies apply to the tools a run's agents call, not to starting the run. The control you have is turning workflows off or guiding the agent in its prompt.
  • Shared environment. All agents share the session's sandbox, filesystem and vault credentials. An inline agent uses the lead agent's MCP servers, and you can't limit an inline agent's servers. To allow only agents you list, disable inline_agents and list at least one agent.
  • Spend. A run has no price of its own; its agents' tokens are billed at each model's rates and count against your Messages API rate limits. A session budget caps spend, runs included, but must be set when the session is created. At the budget, a run can pass it by one model request per working thread.
  • Partial visibility. You don't see the workflow's code, the tool calls the agent makes to start and manage runs, or the result each thread returns to the workflow. You can ask the agent to print the workflow after the run ends.
  • "Completed" is not "passed". A run can end completed even though work on its threads failed. To find failed work you read each thread's events.
  • Duplicate work. A run can create more than one thread for the same piece of work, so Anthropic advises making the tools your agents call safe to call twice.

What This Does Not Settle

  • This is a beta. Anthropic says the server has other limits and rules for workflows that the docs do not list, and that behaviours may change between releases.
  • The docs give no general availability date and no separate price for workflow runs.
  • Moving an agent from the older coordinator type to multiagent_20261001 turns workflows on unless the same update sets them to disabled. Existing sessions keep the settings they were created with.

Related: The permission outside the agent playbook covers scoped permissions and budgets set outside the agent. See also our notes on WorkOS Airlock, Atlas and Passport and the 2026 Anthropic usage policy.