Anthropic opens dynamic workflows on Managed Agents. 1,000 is a lifetime cap; completed does not mean the work passed

What did the 9 October changelog add?

The primary object is the Claude Platform release notes page. Under “October 9, 2026” it says you can now let a Claude Managed Agents agent use dynamic workflows, in beta with the managed-agents-2026-04-01 header. For work with many pieces, such as reviewing hundreds of documents, the agent can write a workflow: “a program that runs many agents in phases and combines their results. The server runs it in the background as a workflow run.”

The same bullet says to set the agent’s multiagent field to {"type": "multiagent_20261001", "workflows": {"type": "enabled"}}, to guide the agent in its system prompt, and to follow workflow_run.* events on the session stream. Those sentences are the changelog’s. They are not a newsroom announcement.

We opened https://www.anthropic.com/news again on 10 October. The visible October items were still Haiku 5.5 on 7 October, the 8 October usage-policy, Genesis Mission, and Cyber Mission posts, and the 6 October Cyber Verification note. There is no Managed Agents workflows item on that index. This changelog sits next to, and is not the same story as, Claude Haiku 5.5 on 7 October or Claude Motion and Dashboards on 8 October, which are Claude apps changes, not this API harness.

How does a dynamic workflow differ from a subagent?

The Multiagent orchestration page, which we opened on 10 October, splits the two paths. With subagents, the agent “delegates tasks itself and reads what each subagent reports.” A subagent’s thread stays available until you archive it, so the agent can send follow-up messages. With dynamic workflows, “Claude writes a program to orchestrate agents without Claude’s direct involvement.” Context and results pass programmatically. The main session thread can keep talking to the user and check in on running workflows. The agent cannot send follow-up messages to a run’s threads, and the server archives each one by the end of its run. That is closer to a planned workflow than to an open-ended agent, except the agent writes the plan.

The same page says 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.” That concurrency is a vendor description of the mechanism, not a speed claim we measured. For why fan-out is a cost decision as much as a latency one, see parallel AI workflows and multi-agent costs.

With multiagent_20261001, dynamic workflows and delegating (subagents) are both on by default. For workflows only, the docs say to add "subagents": {"type": "disabled"}. An advisor model is a third, separate setting and is off by default.

How do you turn it on, and what does the agent decide?

When defining the agent, set multiagent.type to multiagent_20261001 and enable workflows. The contract-reviewer example uses claude-opus-5-5, the agent_toolset_20260401 toolset, and a system prompt that starts a run for more than a few contracts and reviews one or two itself. That prompt is Anthropic’s example, not a default we observed.

A run does not take a separate start call. You describe the work in a user.message; “the agent determines whether and when to start a run.” Permission policies apply to the tools a run’s agents call, not to starting the run. You can list up to 20 predefined agents in workflows.predefined_agents, or let the workflow define inline agents on the session’s model.

A session copies the multiagent setting when it is created. Changing the stored agent later does not change a session that already exists. A session budget, if you want one, must be set when you create the session; “you can’t add one to an existing session.” Runs pause when the session reaches the budget and can resume when you raise or remove it. That is a spend control, not an approval gate on each tool call. Tool confirmations for a run’s threads still arrive on the primary stream and still need an answer.

What are the caps, and what does completed mean?

The Workflow runs page is the limits object. A run is open from workflow_run.created until workflow_run.status_ended, running or idle. Default lifetime is 24 hours; the agent can set a shorter one. Waiting on your client counts. A pause does not stop the clock, so a paused run can end with timeout_error.

completed means “The workflow finished running. The result doesn’t say whether the work passed.” A run can end completed after failed thread work or a thread that never started. Read the thread events. Do not treat completed as a test-suite pass.

1,000 is a lifetime cap of agents a workflow starts. Asking for more ends the run with thread_limit_error. Retries can still produce more than 1,000 threads. Sixty-four concurrent threads is documented as not API-guaranteed. Ten open runs is the session default; idle runs count. A session can start any number of runs over its life.

What does a run cost, and is this Claude Code workflows?

“A run has no price of its own.” Tokens bill at each model’s rates. Prompt caching and web search ($10 per 1,000 searches) apply as elsewhere. Session runtime is $0.08 per hour, to the millisecond, only while status is running. Idle, rescheduling, and terminated time do not count. There is no batch-API discount on sessions.

A run can keep the session running while threads work. At the list rate, 24 hours running is $1.92 in runtime before tokens. That is arithmetic, not a bill we received. A run’s model requests still count toward your Messages API limits.

This is not the May 2026 Claude Code feature. The 28 May Opus 4.8 newsroom post launched Claude Code workflows as a research preview; the living Claude.com article we opened on 10 October now calls them generally available in the CLI, Desktop, and VS Code extension, with an ultracode setting, and warns they “can consume substantially more tokens than a typical Claude Code session.” The 9 October object is a hosted Managed Agents run with workflow_run.* events and the 1,000 / 64 / 10 table. Keep the products separate. For a form-submitting agent the control problem is still computer-use agents, not this changelog.

What did we not test?

We have not created a Managed Agents agent, started a workflow run, or measured tokens. We did not replay the contract-reviewer example. Secondary write-ups that quote a planted-bug comparison are not in the changelog or the docs we opened, and we are not repeating those numbers. The docs say other workflow limits exist and are not listed here.