Anthropic released dynamic workflows in beta on October 9, letting Claude Managed Agents write programs that spawn and coordinate dozens of sub-agents in parallel. Instead of you orchestrating multiple API calls in your own code, you ask Claude to solve a large problem — reviewing hundreds of contracts, for example — and it writes a workflow: a program that divides the work into phases, runs up to 64 agents concurrently per phase, and combines their results in the background.
The core trade-off is control versus throughput. When you orchestrate agents in your application code, you decide exactly which models run, what prompts they receive, how results are validated, and what happens on errors. You log every step. You can pause for human review. You get determinism: the same input produces the same sequence of calls. Dynamic workflows hand that control to the model. Claude writes the orchestration program at runtime based on your request. You don’t see the code unless you ask Claude to print it afterward. The same request on different runs may produce different workflows with different phases and agent assignments. You get higher concurrency — a single workflow can run 64 agents at once, versus the 25-thread cap on manual subagent delegation — and you get the background execution so your session stays responsive. But you lose the ability to inspect or steer the workflow mid-run, and you lose reproducibility.
Cost model matters too. Every agent Claude spawns within a workflow consumes tokens billed at that model’s rate, and those charges count against your session budget. A workflow that fans out to 64 threads for document review will rack up tokens fast. You cap it with a session budget, but once the budget is hit the workflow pauses, not fails, and you either raise the cap or let it time out. With client-side orchestration you control exactly how many calls run and can batch, cache, or skip calls based on intermediate results. With workflows, the model decides, and you pay for its decisions.
Observability is event-driven. You follow a workflow through workflow_run.* events on the session stream: created names the run and lists its phases, phase_started and phase_ended mark progress, status_ended reports completion or error. Each agent runs in its own session thread, and you can list and stream those threads, but you can’t pause or redirect a specific thread — only ask Claude to stop the entire run. Error handling is coarse-grained. A workflow can end with timeout_error (hit the 24-hour default lifetime), thread_limit_error (exceeded 1,000 agents started over the run), program_error (the workflow code failed or a rule was broken), or unknown_error (server limit or infrastructure failure). The program_error category doesn’t specify what failed, so you read the failed threads’ events to diagnose it. There’s no checkpoint-and-retry mechanism built in; if a workflow fails halfway through processing 500 documents, you start over or ask Claude to try again.
The decision comes down to whether the problem decomposes cleanly and whether you trust the model to decompose it. Parallel document review — scan 300 contracts for a clause, check 500 résumés for a qualification, cross-reference 100 reports for discrepancies — fits because the subtasks are independent, the failure of one doesn’t cascade, and speed matters more than exact reproducibility of the intermediate steps. Long sequential workflows with conditional branching — migrate a database schema only if tests pass, then deploy only if the migration succeeded — don’t fit as well because you want explicit gates and you want your own logic deciding what runs next. Dynamic workflows work when you want the model to figure out how to parallelize the work and you’re willing to pay for the tokens it takes to try.
Anthropic enables workflows with a multiagent field on the agent definition: set {"type": "multiagent_20261001", "workflows": {"type": "enabled"}} and include the managed-agents-2026-04-01 beta header on requests. You guide when Claude should write a workflow by telling it in the system prompt — “use a workflow for batch document analysis” or “write a workflow when the task involves more than 50 independent items” — but the model decides whether to honor that guidance. You can constrain which agents a workflow can spawn by listing predefined agents in workflows.predefined_agents, or you can let the workflow define inline agents with their own system prompts on the fly. Predefined agents use their saved configurations; inline agents inherit the session agent’s model, tools, and MCP servers.
The feature is six days old. The documentation acknowledges gaps: you don’t see the workflow’s code unless you ask Claude to print it, there are server limits on workflows not listed publicly, and phases are documented to run sequentially but the API “doesn’t guarantee” the order matches the listed phases. Anthropic positions dynamic workflows alongside two other orchestration modes in Managed Agents: subagents, where Claude delegates tasks itself and can send follow-up messages to each subagent’s thread, and advisor mode, where the session consults a higher-capability model for guidance mid-turn but does the work itself. Workflows are the only mode that gets you 64-way concurrency and background execution, but they’re also the only mode where you don’t control the orchestration code and can’t easily reproduce a successful run.
Whether to let Claude write your orchestration code depends on whether you value speed and model-driven decomposition over reproducibility and fine-grained control. For exploratory work, prototyping, or tasks where the cost of a failed run is low and the benefit of trying many approaches in parallel is high, dynamic workflows let you move fast. For production pipelines, compliance workflows, or anywhere you need audit trails and deterministic behavior, keeping the orchestration in your own code still makes sense.