Claude Managed Agents dynamic workflows: the agent writes the fan-out, the budget has to come first

Since October 9, an agent in Claude Managed Agents can write a workflow: a program that runs many agents in phases and combines what they return. The server runs it in the background as a workflow run. The feature is in beta under the managed-agents-2026-04-01 header, and it arrives with a new multiagent type, multiagent_20261001.

I have not run this on my own key. Everything below comes from the documentation as it read on October 13, 2026, and where I give a reading of my own, I say so. The setup is short. The harder part is that the settings that matter have to be chosen before the first message, the money cap cannot be added afterwards, and the plan for the work is written by the model after that, where you do not see it.

What does a Claude Managed Agents dynamic workflow do?

It moves the orchestration out of the conversation and into code the model wrote. With subagents, the agent delegates a task, reads the report and decides the next step itself. With a workflow, a program does that: it starts agents, collects each result, passes results to other agents, repeats a step, and decides what to do when one fails. Results go to the program, not to the agent that the session runs, which stays free to talk to you or end its turn.

Each agent in a run works in its own session thread, with its own conversation history, in the session’s shared sandbox. So every thread sees the same files. The docs recommend workflows for most work that needs more than one agent, and give audits, migrations, deep research and cross-checking as examples.

How do you turn Claude Managed Agents dynamic workflows on, and how do you keep them off?

You set the agent’s multiagent block to the new type. The release note gives the explicit form:

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

The workflows line is not what turns it on, though. With this type, workflows and subagents are both enabled by default, and each has inline_agents enabled, which lets the agent or a workflow define agents on the spot. A block that contains only the type gives you all of it.

That matters most when you migrate. Moving an agent from the older coordinator type replaces the whole multiagent block, and whatever you leave out takes its default. An agent that could only delegate to two subagents you listed can, after the update, start workflow runs and define its own subagents. To keep either off, send {"type": "disabled"} for it in the same update. Sending null does the opposite of what it looks like: it restores the default, and the default is enabled.

Two smaller traps sit in the same section. A session copies the setting when it is created, so changing the agent does not change a session that already exists. And the ant__ tool-name prefix is now reserved: an agent with a custom tool named that way fails every update with a 400 until the tool is renamed.

Who decides when a Claude Managed Agents workflow run starts?

The agent does, and nothing else is asked. There is no API call that starts a run. You describe the work in a user.message, and the agent determines whether and when to start one. The docs say it in one sentence:

Permission policies apply to the tools that a run's agents call, not to
starting the run.

Your lever is prose. The docs’ example instructions tell a contract-review agent to start a run for more than a few contracts and to handle one or two itself. You can also write how to split the work, what to do when an agent fails, and a time limit.

My read is that this is the weakest control in the feature, and it is the one the docs lean on. An instruction in the agent’s system instructions is weighed, not enforced, the point of a prompt is not an invariant. This is the case that essay worries about most: a rule whose violation costs money, with no place in the API to put a gate. You also do not see the tool call that starts a run. The first sign is a workflow_run.created event on the stream. So the model decides to fan out and you learn of it afterwards. What bounds it is whatever you set before the first message.

How do you cap what a Claude Managed Agents workflow run can spend?

With a session budget, and only at session creation. A run has no price of its own; its agents’ tokens are billed at each model’s rates, like the rest of the session. The budget is the one money cap, and there are no per-thread caps under it:

{
  "agent": "$AGENT_ID",
  "environment_id": "$ENVIRONMENT_ID",
  "budget": {
    "type": "limit",
    "max_list_cost": { "amount": "2000", "currency": "USD" }
  }
}

The amount is a whole number of US cents written as a string, so "2000" is $20. Four details decide whether the cap does what you expect. It cannot be added later: adding a budget to a session created without one returns a 400, and removing one is one-way too. It is measured at list price, not your contracted price, and session running time and web searches count. It is not an exact stop. Each thread finishes the model request it already started, and a run can have 64 threads working at once (a number the API does not guarantee), so the overshoot is up to one request per working thread. And at the cap the session goes idle with budget_reached (or requires_action, if a tool call is still waiting on your client) and refuses a user.message until you raise or remove the budget, while a paused run’s lifetime keeps passing, so the run can end with timeout_error while it waits.

The other limits are counts: 1,000 agents started over a run’s life, a 24-hour lifetime unless the agent sets a shorter one, and by default 10 runs open at once in a session. None of them is denominated in money.

The model is the other cost setting. An inline agent uses the model of the agent that the session runs, so an agent on the largest model fans out on the largest model. The documented way to use a cheaper one for part of a run is to create those agents yourself and list them in workflows.predefined_agents. Claude Code’s own Workflow tool got an environment variable for this the same day, CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL in v2.1.296. In Managed Agents the route is the agent list.

How do you follow a Claude Managed Agents workflow run and know it is finished?

You read workflow_run.* events on the session’s event stream: created (with the run’s name and declared phases), status_running, status_idle, phase_started, phase_ended, status_ended, and error. The work is done when two things are true: every run you saw created has its workflow_run.status_ended, and after that a session.status_idle arrives with end_turn that your own request did not cause. After an interrupt, only an idle that follows your next user.message counts. An idle alone proves nothing, because a paused run lets the session go idle while the run is still open, and the agent can start another run when it reads a result.

Run events do not trigger webhooks. A new connection does not replay what you missed, and no endpoint lists runs, so after a reconnect you rebuild state by listing the session’s events. And a run’s thread can wait on your client for a tool confirmation while the session stays running, so answer when the event arrives. A confirmation that comes too late returns 200, which, in the docs’ words, “doesn’t mean that the tool ran.”

To stop a run you ask. No event you send ends one; user.interrupt stops the agent’s turn and ends no run. You send a user.message asking the agent to stop its runs. Archiving the session also ends them, but an archive can return a 400 while a run is open, so the documented order is to ask for the stop, wait for each run’s status_ended, then archive.

Does “completed” mean a Claude Managed Agents workflow run succeeded?

No, and the docs state it outright:

The workflow finished running. The result doesn't say whether the work
passed. A run can end completed even though work on its threads failed, or a
thread couldn't be created.

To find failed work you read the events of each of the run’s threads. The failure result is no more specific: program_error does not name its cause. You also cannot see the workflow’s code, the tool calls that manage the run, or the result each thread returned to the program. The docs suggest asking the agent, after the run, to print the workflow word for word. That is the model’s account of what it ran, which is worth reading and is not a log.

One more sentence on the workflow-runs page deserves a place in your design: “A run can create more than one thread for the same piece of work, so make the tools your agents call safe to call twice.” The docs promise nothing about how often this happens. I read it as the at-least-once problem I described in your multi-agent system is a distributed system: work that may be reissued has to be safe to run twice. The label is mine; the instruction to make tools tolerate a second call is the vendor’s.

My rule there was that the signal of success comes from the artifact, checked by something the working agent does not control. It still applies, and the shared sandbox is where to apply it. My suggestion, untested: tell the workflow in the system instructions to write one result file per unit of work, then count and inspect the files yourself, from outside the run. A closing summary like the docs’ example, “41 of the 300 contracts have one,” is a claim about threads you have not read.

What should you set before enabling Claude Managed Agents workflows for unattended work?

Three settings, then three habits. Set the budget when you create the session, sized with the per-thread overshoot in mind, because it cannot be added afterwards. Disable inline_agents under workflows and list the agents a run may use: an inline agent currently gets all of the session agent’s tools, MCP servers and skills (the API guarantees only a subset), and the docs say you cannot limit it the way you limit an agent you define. Disable subagents explicitly if you want workflows only, since leaving it out enables it. The session copies the agent’s multiagent settings when it is created.

The habits are not fields. Make every tool a run’s agent can call safe to call twice. Write into the system instructions when to start a run and when not to, and treat that as guidance. Check the combined result from outside the run before you trust it.

A block that does the second and third settings, assembled from the documented fields:

{
  "multiagent": {
    "type": "multiagent_20261001",
    "subagents": { "type": "disabled" },
    "workflows": {
      "type": "enabled",
      "inline_agents": { "type": "disabled" },
      "predefined_agents": [
        { "type": "agent", "id": "agent_01Lm4cV8yQ2tNs7XbKdR5h", "version": 2 }
      ]
    }
  }
}

The tools those agents call keep their permission policies inside a run, so the defaults I went through for the web_fetch change apply to every thread a workflow creates, up to 64 of them at a time.

Where I part with the docs is the word most. A workflow is the right shape when the split is not known in advance and the pieces are independent. When you already know the split, a script you wrote keeps the plan somewhere you can read it before it runs, and a list of subagents at least fixes who can be called, even though the agent still decides each step. Here the plan is written at run time, by the model, and shown to you only if you ask afterwards.