What changed
Added from zero: the agent can now write a workflow โ a multi-phase orchestration program โ and execute it as a workflow run that the server runs in the background. This replaces developer-written orchestration code for tasks too large for a single conversation. Previously, fan-out required the developer to manage multiple sessions; now the agent manages its own sub-agents.
TL;DR
Managed Agents can now self-author and execute fan-out workflows โ enable with the managed-agents-2026-04-01 beta header and set multiagent.workflows.type to enabled to let the agent spin up parallel sub-agents for large-scale tasks (e.g., reviewing hundreds of documents in parallel phases).
Developer signal
Enable Dynamic Workflows by (1) including the managed-agents-2026-04-01 beta header on your session requests, and (2) setting the agent's multiagent configuration:
{
"type": "multiagent_20261001",
"workflows": {"type": "enabled"}
}
Tell the agent in its system prompt when to initiate a run and what tasks warrant one. You then follow the run via workflow_run.* events on the session's primary event stream โ the sequence is: workflow_run.created (with phases[] declared), workflow_run.status_running, workflow_run.phase_started/ended per phase, then workflow_run.status_ended with a result field. Each agent within the workflow runs in its own session thread (visible in the thread list, grouped by workflow_run_id). A run's threads are exempt from the session's child-thread limit. The default run lifetime is 24 hours; the agent can set a shorter one. Important edge cases: archive a session to cancel open runs; threads within a run cannot themselves start nested runs; inline agents (those the workflow defines) inherit the session agent's model, tools, and MCP servers. You can ask the agent to print its own workflow code after a run completes โ useful for debugging.