Dynamic workflows in Claude Managed Agents: the agent writes the program that runs the other agents

On October 9, 2026, Anthropic added dynamic workflows to Claude Managed Agents, in beta under the managed-agents-2026-04-01 header. An agent can now write a workflow: a program that runs many agents in phases and combines what they return. The server runs that program in the background as a workflow run, while the agent keeps working or ends its turn.

Managed Agents is Anthropic's hosted agent loop: you define an agent, start a session, and Anthropic runs the tools and the sandbox. If the term is new, start with Claude Managed Agents.

Subagents and workflows are different tools

Managed Agents already let one agent delegate to others. That is the subagent pattern, covered in multiagent sessions, outcomes, and dreaming. With subagents, the main agent decides each next step: it hands out a task, reads the report, and decides what to do next.

With a dynamic workflow, Claude writes the whole plan as a program up front. Context and results pass from one agent to the next in code, without the main agent reading each one. That frees the main thread to talk to the user and report on progress, and it lets agents inside a run work at the same time.

	Subagents	Dynamic workflows
Who decides the next step	The main agent, after each report	A program the agent wrote
Follow-up messages to a worker	Yes, the thread stays open	No, the server archives each thread at the end of the run
Good for	Specialists you list, work where one result changes the next step	Work with many pieces: audits, migrations, deep research, cross-checking
Limit	Up to 25 child threads per session	Run threads don't count toward that 25

Anthropic's own example is reviewing hundreds of documents. One agent reading all of them runs out of context and takes the longest path. A workflow splits the pile, has agents review pieces in parallel, then runs a later phase that merges the findings.

Turn it on

Set the agent's multiagent block to the multiagent_20261001 type and enable workflows:

{
  "name": "Contract reviewer",
  "model": "claude-sonnet-5-5",
  "system": "You review contracts. When you're asked to review more than a few contracts, start a workflow run that reads them in parallel and combines the findings. Review one or two contracts yourself, without a run.",
  "multiagent": {
    "type": "multiagent_20261001",
    "workflows": { "type": "enabled" }
  }
}

The system prompt matters. The agent decides when to start a run, and a sentence like the one above sets the threshold. Without it you may get a run for a two-page NDA.

Settings to know:

• Defaults. With the multiagent_20261001 type, both subagents and workflows are on. To use workflows only, add "subagents": {"type": "disabled"}. To turn workflows off, set workflows to {"type": "disabled"}.
• Which agents a run can use. By default a workflow defines its own inline agents and writes a system prompt for each; they use the model of the agent the session runs. To give some run agents a different model, such as a cheaper one for the bulk reading, create them as agents and list them in workflows.predefined_agents (up to 20). To allow only the agents you list, set workflows.inline_agents to {"type": "disabled"} and list at least one.
• Geography. The agent and every agent you list must pin the same inference geography, or none of them can. A mismatch is a 400 error.
• Reserved names. Custom tools whose names start with ant__ are rejected once multiagent is set. Rename them in the same update.
• Existing agents. An agent on the older coordinator type cannot start workflow runs. Moving it to multiagent_20261001 turns workflows and inline agents on unless you disable them in the same update.

Following a run

Run events arrive on the session's event stream. A run opens with workflow_run.created, which carries the run ID (wrun_…), a name and description, and the phases the workflow declared. workflow_run.status_running fires when execution begins, and again when a run resumes after a pause. workflow_run.status_ended closes it. Each agent in a run works in its own session thread, which you can list, read, and stream.

A run's lifetime defaults to 24 hours, and the agent can set a shorter one when it starts the run. Only the agent can start a run. Events you send do not end one, but archiving the session does. The Workflow runs docs list the full event set and interrupt behavior.

Set a budget before you try it

Every agent in a run uses tokens, and a run can start dozens. Set a session budget when you create the session; you cannot add one to an existing session. When the session reaches the budget, runs pause. They resume when you raise or remove it. Budgets, advisors, and geo pinning covers how to set one.

What to do first

1. Pick one job with many independent pieces, such as checking 200 vendor contracts against a policy.
2. Create the agent with the system prompt above, adapted to your job, and a session budget low enough that a mistake costs little.
3. Run it on 20 items first. Read the run's phases and a few agent threads to see how it split the work.
4. Compare the merged result against a sample you reviewed by hand. How to evaluate whether your multi-agent pipeline is actually better describes how, and multi-agent failure handling covers what to do when one piece fails.

If you use Claude Code locally, the same idea exists there: see Dynamic Workflows in Claude Code. The Managed Agents version runs on Anthropic's servers, so the run continues when your laptop closes.