Claude Dynamic Workflows: Managed Agent Background Runs

What Changed: Dynamic Workflows in Anthropic Managed Agents

On 2026-10-09, Anthropic introduced dynamic workflows for Claude Managed Agents. The capability is available in beta using the managed-agents-2026-04-01 beta header. Previously, coordinating multiple agents required the root agent to handle every handoff explicitly or interact with dedicated subagents turn by turn. With this update, an agent can dynamically write a workflow program that coordinates cohorts of agents across structured phases, aggregates their findings, and reports outcomes back to the main thread.

This orchestration mechanism targets workloads with numerous discrete components that would otherwise overflow a single conversational window or overwhelm interactive coordination. For instance, when processing batches such as 300 contracts, an agent can script a multi-phase routine: one phase fans out document readers across isolated threads, while a subsequent phase aggregates and cross-checks the extracted clauses. Because the generated orchestration program runs on the server as an autonomous workflow run, the primary session thread remains unblocked to interact with end users or query overall progress.

Architectural Differences: Dynamic Workflows, Subagents, and Advisors

The Anthropic platform provides three distinct orchestration paradigms under the multiagent_20261001 specification: subagents, dynamic workflows, and advisors. Selecting the proper pattern depends on whether an agent needs continuous conversational back-and-forth with specialists, programmatic multi-phase execution, or mid-turn strategic guidance.

Subagents excel when an orchestrator must converse repeatedly with dedicated specialists that have preconfigured system instructions and tooling. Dynamic workflows, by contrast, excel when massive parallelization or multi-step analysis is required. Context passes programmatically between worker agents within the shared sandbox, filesystem, and credential vault without requiring the primary agent to supervise individual token exchanges.

Configuring the Multiagent Block and Restricting Agent Access

Enabling dynamic workflows requires declaring the multiagent object in the agent definition with type multiagent_20261001. By default, when this configuration block is supplied, both subagents and workflows are enabled, and both permit inline agents. Inline agents allow the orchestrator or workflow program to define ephemeral workers on the fly, inheriting the orchestrator model, tools, skills, and Model Context Protocol servers.

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

When teams require strict governance over which prompts and capabilities execute, inline creation can be turned off. Setting inline_agents to {"type": "disabled"} mandates that all worker agents be enumerated explicitly in the predefined_agents array. If inline agents are disabled while predefined_agents remains empty, the API rejects the configuration with a 400 error. Predefined entries can reference existing agents by identifier string, pin specific numerical releases like version 2, or declare {"type": "self"} to permit replicas of the host agent.

When defining agents through API calls, remember to pass the required headers anthropic-version: 2023-06-01 and anthropic-beta: managed-agents-2026-04-01. Models such as claude-opus-5-5 can be assigned as the lead coordinator, while lightweight workers like claude-haiku-5-5 can be pre-provisioned in external configuration files to handle modular analysis.

Streaming Execution and Lifecycle States of Workflow Runs

Workflows execute on Anthropic servers in the background. Instead of relying on webhooks, applications observe workflow progress through real-time events emitted over the primary session stream. A workflow run transitions across three core lifecycle conditions: running, idle, and ended. A run is defined as open from the moment workflow_run.created appears until the final workflow_run.status_ended payload arrives.

• workflow_run.created: Announces the newly instantiated run, providing a unique workflow_run_id starting with wrun_, an optional title, and the array of planned execution phases.
• workflow_run.status_running: Confirms that execution is active, emitted upon initial kickoff and whenever a run resumes after pausing.
• workflow_run.status_idle: Indicates the run is temporarily suspended, such as when hitting an operational spend ceiling or awaiting client input.
• workflow_run.phase_started and workflow_run.phase_ended: Demarcate stage transitions within the workflow program, linked via phase_started_id and workflow_run_phase_id.
• workflow_run.status_ended: Marks conclusion of the run, delivering the terminal result object describing whether execution completed, stopped, or failed.

Individual agents operating inside workflow phases emit their own session.thread_created events referencing the parent workflow_run_id. Because phase definitions originate from generated code, clients must handle dynamic behaviors: phases might not complete in strict serial index order, planned phases might occasionally be skipped, and multiple phases can run simultaneously if the program fans out worker groups.

Error Handling, Budgets, and Operational Constraints

Every agent running within a workflow consumes model tokens against your account. Because dynamic scripts can instantiate dozens of concurrent workers, managing expenditure requires enforcing an explicit session budget. Reaching a session spend limit automatically shifts active runs into the idle state via workflow_run.status_idle. Adjusting or lifting the session cap allows the suspended run to transition back to workflow_run.status_running. To evaluate model token costs before scheduling massive batch jobs, developers can review token economics using /tools/llm-api-cost-calculator/ and review spending limits in /posts/per-run-cost-cap-for-llm-api-calls/.

A run status of completed does not inherently guarantee that every individual subtask passed. If a background worker thread encounters a tool exception or network failure, the workflow program can catch the error and proceed to the next phase. Developers should inspect events from child threads to verify quality metrics before acting on the final output.

Implementation Checklist for Claude Dynamic Workflows

Follow this operational checklist when incorporating background dynamic workflows into production Claude Managed Agents deployments:

• Include anthropic-beta: managed-agents-2026-04-01 and anthropic-version: 2023-06-01 headers on every API request.
• Set multiagent.type to multiagent_20261001 and verify whether workflows should be enabled alongside subagents.
• Determine agent permission boundaries: leave inline_agents enabled for flexible prompting or set to disabled and populate predefined_agents to enforce strict tool boundaries.
• Add explicit instructions in the orchestrator system prompt clarifying under what criteria it should launch a workflow run versus answering immediately.
• Establish strict session financial budgets to prevent runaway parallel agent spawning during high-volume document batch runs.
• Attach consumers to the primary thread event stream to monitor workflow_run.* lifecycle markers, mapping phase IDs to phase labels.
• Implement graceful handling for program_error, timeout_error, and thread_limit_error terminal states.