One agent is a tool.
Several is a management problem.
On 6 May 2026, multiagent orchestration and a companion feature called Outcomes entered public beta for Claude Managed Agents, alongside webhooks for session and vault lifecycle events. This is the follow-on read from Managed Agents 101: what changes when one agent becomes several.
A single well-configured agent is by now a reasonably understood thing: define the task, set the tools, set the effort level, monitor the output. Orchestration introduces a different problem, deciding how work should be divided in the first place, and that decision is where most of the value and most of the risk sits.
Division of work is the whole game
Divide a task well and several agents produce faster, more thorough results than one could. Divide it badly, splitting work that needed one consistent line of judgement, and you get contradictory output that takes longer to reconcile than doing it with a single agent would have. The feature is reliable; the decomposition decision is where projects succeed or fail.
What decomposes cleanly
Research fanned out across sources. A build-then-verify pipeline where one agent produces and another checks. Batch work over many similar items. The common property: the pieces do not need to share an evolving judgement, only inputs and outputs. If halfway through piece three you would want to revise piece one, it was not actually decomposable.
Outcomes: define done before you start
Outcomes lets you define what a successful result looks like for a task, rather than relying on prompt wording to imply it. For anything beyond a one-shot job this is worth adopting early, because a defined outcome is what lets you judge whether a multiagent run actually succeeded, instead of eyeballing the output and hoping.
The webhooks make it operational
Webhooks for session and vault lifecycle events, extended in July to environment and memory store events, mean your systems can react to what agents are doing without polling. That is the difference between a demo and something that runs unattended inside a business process.
Start with a task you can already judge
Our unglamorous advice: make your first orchestration build a task you understand well enough to know what done properly looks like. Teams that reach for multiagent on their hardest, least-understood problem first have the worst time, not because the feature fails but because they have no baseline to judge it against.
Would you give this task to three junior colleagues who cannot talk to each other? If the answer is yes with a clear division of labour, it is a candidate for orchestration. If the answer is only with constant coordination, it wants one agent, not several.
Things people
usually ask.
No. A single agent covers a great deal, and is the right starting point. Orchestration is for work that genuinely decomposes; reaching for it by default adds coordination cost without adding quality.
Defining success criteria for a task explicitly, so a run can be judged against them. It matters more in multiagent work because with several agents producing parts of an answer, “does this look right” stops being a workable quality check.
Two. One producing, one verifying, on a task you already understand. It exercises the whole orchestration surface, division, outcomes, coordination, at the smallest size that teaches you anything.