The Claude Platform release notes carry an entry for October 9 that closes a gap in the API: an agent in Claude Managed Agents can now use dynamic workflows. In beta, behind the managed-agents-2026-04-01 beta header.
What a dynamic workflow is
For work made of many pieces — Anthropic’s example is reviewing hundreds of documents — the agent writes a workflow itself. The workflow is a program that runs many agents in phases and combines their results. The server runs it in the background as a workflow run.
The difference from the old way is who decides. Until now a developer wrote the phases and the agent worked through them. Now the agent decides, based on the task, how many agents run in which phases — and writes the program that does it.
How to turn it on
In the agent’s multiagent field:
{"type": "multiagent_20261001", "workflows": {"type": "enabled"}}You steer it from the system prompt, which tells the agent when to start a run. Every run is observable through workflow_run.* events on the session’s event stream.
The same tool, now on the other side
Claude Code has had dynamic workflows since June — Claude writes a script that orchestrates dozens of agents and you watch it run. What ships now is the same mechanic server-side, for agents that run without a terminal.
That makes Managed Agents the subject twice this week. On October 7, web_fetch was tightened so it only retrieves URLs that were already in the session.
The order of those two changes is the interesting part
First an agent’s network reach gets fenced in, two days later the same agent may spawn as many further agents as it likes. Those fit together, even if they look opposed: whatever scales has to be bounded first.
In practice this mostly means cost and runtime get harder to predict. If you let an agent decide its own fan-out, treat the workflow_run stream as an instrument rather than a log. And the line in your system prompt about when a run may start at all is the real ceiling.