Anthropic Dynamic Workflows: When AI Agents Should Orchestrate Themselves

Anthropic’s Dynamic Workflows change the question behind multi-agent systems. Instead of asking a developer to predefine every worker, handoff, and branch, the primary Claude agent can write a workflow program for the task, start it, and later combine what its agents return. That is a meaningful new capability for teams building AI workflow automation—but it is not a shortcut around system design.

The practical opportunity is selective autonomy: let a lead agent choose a work topology when the job can be split into independent, reviewable pieces, while keeping budgets, permissions, stop paths, and human accountability outside the model’s discretion. The important word is selective. Dynamic orchestration is a better fit for broad, verifiable work than for every request that happens to be long.

What Anthropic actually introduced

Anthropic’s Workflow runs documentation defines a workflow as a program an agent writes to run many agents and combine their returns. A workflow run is that program’s execution. The service runs the workflow in the background, creating session threads for agents as the program needs them.

That distinction matters. A conventional multi-agent setup normally begins with a fixed roster: a researcher hands off to an analyst, an analyst hands off to a writer, and the developer decides the sequence in advance. With Dynamic Workflows, the lead agent writes the orchestration program for the work described. The program can fan out concurrent agents, pass returned results into later work, repeat a step under a rule, choose a next step based on a result, or handle a failed agent.

Anthropic’s documentation is specific about control boundaries. The workflow program decides which agents run next and writes their prompts; the individual agents return to the program, not directly to the primary session agent. The server executes runs in the background, and the primary agent can later inspect what occurred. Only the agent starts a run; sending an event does not end one, although archiving the session can.

A report from AI Engineer New York described the product as Claude selecting its own multi-agent topology instead of being confined to a configured coordinator and roster. That is useful context, not a guaranteed performance claim. The published documentation is the stronger source for what the product does; conference remarks are best read as an explanation of the product direction.

Why a model-selected topology is different

A topology is the shape of the work: how many investigations happen in parallel, what evidence moves between them, and where results are reconciled. In a fixed roster, that shape is an application decision. Dynamic workflows make it a task-time decision by the lead agent.

Consider a due-diligence review over hundreds of documents. A lead agent might write a program that assigns document groups to separate threads, asks a second phase to compare disputed findings, and reserves a final thread for an evidence-backed summary. The documentation gives the same general idea: work too large for one conversation can be split across agents whose results are later combined. Because each agent has an isolated session thread, the design can reduce irrelevant context mixing while still allowing the workflow to pass selected results forward. The run’s agents also share the session sandbox, so shared files are a coordination surface that deserves normal access controls.

This does not mean the model gets an unlimited organization chart. Anthropic currently documents a maximum of 1,000 agents started over a single run’s lifetime and a limit of 64 simultaneously working threads, while noting that the latter is not guaranteed to remain fixed. The default run lifetime is 24 hours, and time spent waiting on a client counts toward it. A budget pause does not pause that lifetime. These are engineering constraints, not implementation trivia: an apparently idle run may be paused at budget and still time out later.

Operate the capability as a bounded system

The most useful adoption pattern is not “turn on autonomous teams.” It is to define a bounded workload, then earn wider autonomy with observations and evaluations.

Start with a narrow, verifiable unit of work. Good first candidates have a clear corpus, an explicit output format, and checks that can catch omissions or contradictions: classifying support tickets, extracting contract clauses, surveying a set of technical documents, or preparing evidence for a human analyst. Avoid giving a first deployment an open-ended mandate such as “improve our operations.” If the work cannot be decomposed or independently checked, more agents may simply create more confident noise.

Treat budget as a control, not a reporting field. Conference discussion around the launch highlighted the cost concern; the official docs describe runs moving to an idle state when a budget is reached. Set a session budget before enabling expensive fan-out, select a small default scope, and decide in advance who can raise or remove that budget. Measure total cost and completion quality against a single-agent baseline. Parallelism is worthwhile only when the added coverage or reliability exceeds its cost and operational overhead.

Make permissions and stop paths explicit. A workflow can choose its next computational step, but it should not silently acquire broader authority. Give subagents the least access required; separate read-only research from changes to production systems; and put human approval before irreversible or outward-facing actions. Define who can stop a run, what event is treated as escalation, and how a session archive affects active work. A workflow that can take many steps needs a deliberate off-ramp.

Observe the run, not just the final prose. Anthropic says run events arrive on the primary session’s event stream. Phases and thread events are therefore operational data: track which phase began, which ended, what threads failed, and whether a run became idle because of a budget or an interruption. A completed run does not itself prove every thread succeeded. Record inputs, prompts where appropriate, tool activity, intermediate evidence, and the evaluation result so a reviewer can diagnose a surprising answer.

Design the reconciliation step before fan-out. Parallel research does not automatically become a trustworthy answer. Decide which agent receives conflicting claims, what sources count as primary evidence, how confidence is represented, and when the workflow must return uncertainty rather than force a conclusion. This is especially important when agents operate on overlapping source sets: duplicate effort and correlated errors can make a wide workflow look more persuasive than it is. A small independent checker, a deterministic validation rule, or a human reviewer at the merge point can be more valuable than adding another exploratory thread.

A decision framework for teams

Use dynamic orchestration when all five conditions are substantially true:

1. The scope is large enough to benefit from decomposition. There are many items, sources, or test cases rather than one tightly coupled judgment.
2. Subtasks can be made discrete and verifiable. You can define evidence, completion criteria, and a reconciliation step.
3. The cost envelope is explicit. A budget, concurrency expectation, and timeout policy exist before the run begins.
4. Authority is bounded. Agents have only the permissions they need, and consequential actions pause for a person.
5. A baseline exists. You can compare quality, latency, cost, and failure modes with a simpler single-agent or fixed-workflow approach.

Choose a fixed roster when the sequence is stable, compliance requires a repeatable route, or the cost of topology variation outweighs its benefit. Choose one agent when the task is small, highly coupled, or best solved through a single informed conversation. Dynamic orchestration is a tool for creating useful work partitions—not proof that every task deserves a swarm.

The durable lesson from Anthropic’s launch is governance-oriented. Let the system decide how to divide a bounded problem, but do not delegate the definition of acceptable cost, authority, evidence, or failure. Teams that pair Dynamic Workflows with those controls can test a more adaptive form of multi-agent orchestration without mistaking autonomy for assurance.

FAQ

Does a budget guarantee the run will stop exactly at its limit?

No. According to Anthropic’s Workflow runs documentation, each working thread finishes a model request already in progress, so a run may exceed the session budget by one request per working thread. A budget pause also does not stop the run’s lifetime clock.

Does a completed workflow run mean all its agents succeeded?

No. Anthropic says a run can end as completed even if a thread failed or could not be created. Check the events for each thread before accepting the result.

Sources

• Anthropic, “Workflow runs”
• Latent Space, “How Anthropic’s Dynamic Workflows Coordinate Claude Agents”