Claude Managed Agents dynamic workflows: limits to set first

Claude Managed Agents can now write and run multi-agent workflows in beta. The agent turns a large task into a program that fans work out to many agents in phases and merges results in the background. Before switching it on, set a session budget, restrict which agents a workflow may use and make tools safe to call twice.

What was released

Dynamic workflows for Claude Managed Agents were announced by Anthropic on 9 October 2026 in the Claude API release notes. The feature is in beta behind the existing managed-agents-2026-04-01 header. A team turns it on in the agent's multiagent block, using the new multiagent_20261001 type with workflows enabled, and is told to say in the agent's system prompt when a workflow run should be started. It sits alongside the existing subagents and the advisor option described in the multiagent orchestration guide.

What actually changed

• The agent writes the orchestration, not you. A workflow is a program the agent writes for the request. It can run agents in parallel, pass one agent's result to another, repeat a step until a check passes and decide what to do when an agent fails, as the workflow runs page describes.
• Runs happen in the background. The main session thread stays free to talk to the user and check on progress. When a run ends, the agent gets a turn to read what it did and answer.
• Subagents and workflows behave differently. A subagent keeps its thread, so the agent can send it follow-ups. A workflow's threads cannot receive follow-ups and are archived by the end of the run, and only the agent on the primary thread can start a run, so runs do not nest.
• New events to follow. Progress arrives on the session's event stream as workflow_run.created, phase start and end events, workflow_run.status_ended and workflow_run.error. These run events do not trigger webhooks.
• Published limits. The documented ceilings are 64 threads working at once in one run, 1,000 agents over a run's life, a 24-hour default lifetime and 10 open runs per session, and Anthropic notes the server has other limits it does not list.
• No separate price. A run's tokens are billed like the session's other tokens, at each model's rates, and they count toward the session budget and the organisation's existing Messages API rate limits.

The settings to fix before you turn it on

In CodeDTX's view, these are the decisions that need an owner before a workflow run touches production data:

1. Set a session budget. Every agent in a run uses tokens, and a fan-out can start many agents from one user request. At the budget, open runs pause rather than fail, and each working thread can still finish the model request it had started, so set the cap with some headroom. Our guide to controlling what an AI agent costs to run covers how to size one.
2. Decide on inline agents. By default a workflow can define its own agents, with system prompts it writes. Those inline agents use the session agent's model and a subset of its tools and MCP servers, and you cannot narrow their MCP access per agent. If you need tight control, turn inline_agents off under workflows and list the predefined agents a run may use.
3. Make tools idempotent. Anthropic's documentation warns that a run can create more than one thread for the same piece of work. Any tool that writes to a database, sends a message or opens a ticket needs a request ID or similar guard, as covered in what to do when an AI agent tool call fails.
4. Read every thread, not just the result. A run can end with a completed result even though work on some of its threads failed. Your client should check the run's threads before reporting success to a user.
5. Plan for limited visibility. You do not see the workflow's code or the result each thread returns to it. The documentation suggests asking the agent to print the workflow after the run ends, which is worth storing alongside the session for audit, along with the delegation questions in who is accountable when agents delegate to agents.

When not to use dynamic workflows

A workflow suits work with many independent pieces, such as audits, migrations, deep research or cross-checking a large document set. It is the wrong fit when a single agent with good tools can finish the task in one conversation, when you need to send follow-ups to the same specialist, or when every step must be approved by a person before the next one starts. It is also a beta feature with limits that can change, so customer-facing flows that depend on predictable cost and timing should run it behind a feature flag first. For long tasks that need state to survive, compare it with the patterns in running AI agent tasks that take days.

Frequently asked questions

What are dynamic workflows in Claude Managed Agents?

They let a Claude Managed Agents agent write a program, called a workflow, that runs many other agents in phases and combines their results. The server runs it in the background as a workflow run, which you follow through events on the session stream. Anthropic released it in beta on 9 October 2026, and it is turned on in the agent's multiagent settings.

How is a workflow run different from using subagents?

With subagents, the agent delegates tasks itself, reads each report and can send the same subagent follow-up messages. With a workflow, the agent writes a program that passes results between agents without its direct involvement, and the run's threads cannot receive follow-ups. Workflows suit many parallel pieces of work; subagents suit a few specialists the agent needs to talk to more than once.

Do dynamic workflows cost extra?

There is no separate charge for a run. The tokens used by every agent in the run are billed like the session's other tokens, at each model's rates, and count toward the session budget and your Messages API rate limits. Because one request can start many agents, the practical cost can rise quickly, so a session budget is the main control to set before use.

Can I stop a workflow from creating its own agents?

Yes. Set inline_agents to disabled under the workflows setting of the agent's multiagent block, and list the agents a run may use in workflows.predefined_agents. With inline agents off, the list must contain at least one agent or the request fails. This is the way to keep runs to agents whose prompts, tools and MCP servers you have already reviewed.