How to build multi-agent systems with Anthropic

Key takeaways

• Start with a simple, evaluated design. Add agentic steps only when that design falls short.
• Treat coordination as infrastructure you design, not behavior that appears when models become more capable.
• Give every handoff an explicit owner, context payload, state boundary, control, and recovery path.

Learning how to build multi-agent systems with Anthropic starts with an awkward question: should the system have multiple agents at all? Agent count is not a maturity score. The architecture earns its complexity only when the workload does. Anthropic's own guidance starts with simple prompts, improves them through evaluation, and adds multi-step agentic systems when simpler solutions fall short. That principle is the foundation for the decisions below. For the wider implementation process, our multi-agent build guide carries the work from architecture into a complete plan.

Should this task use more than one agent?

Use more than one agent after a simpler evaluated design has failed to handle the workload. This is the clearest starting point in Anthropic's guidance on building effective agents: begin simply, evaluate thoroughly, and add agentic steps only when the simpler approach falls short.

There is a credible positive case. Multi-agent systems have proven valuable for open-ended research tasks. But that does not make open-ended research a blanket argument for adding agents. As systems scale, efficiency, cost, and governance become harder problems. Coordination among many agents can also create communication overhead, message congestion, and performance bottlenecks unless the workflow is carefully managed.

Use this keep-or-collapse matrix before choosing a topology:

Coordination does not emerge on its own

Once a task warrants multiple agents, stronger models do not remove the coordination problem. Human coordination assumptions do not automatically transfer to agents. Coordination does not naturally appear just because each agent becomes more intelligent or individually aligned.

This creates an important evaluation boundary. Every model tested in Anthropic's research understood in the abstract that information sources have their own incentives and that consensus is not necessarily evidence. That abstract understanding does not itself establish collective coordination. A group of capable agents still needs an explicit structure for how work is divided, what crosses a boundary, and how the combined output is checked.

We therefore treat collective behavior as its own design object. The question is not only whether each agent can perform its local task. It is whether the surrounding system makes planning, delegation, state, and quality controls legible across the whole trajectory.

This calls for two evaluations. First, can each agent do its assigned work? Second, do the agents coordinate when their work meets? The first result cannot stand in for the second. Individual intelligence and alignment do not guarantee coordination, while abstract knowledge about source incentives does not show how a group will resolve competing inputs. Test the collective output as collective output.

Agreement deserves its own scrutiny. If several agents reach the same answer, their agreement is not automatically evidence for that answer. The models in Anthropic's test understood this point in the abstract, along with the fact that sources can have their own incentives. An evaluation should therefore inspect the information behind a collective result, not count how many agents accepted it.

What is multi-agent orchestration?

Multi-agent orchestration is the control layer that brings planning, policy enforcement, state management, and quality operations into one coherent architecture. It defines how responsibilities move between agents and how the system remains observable when they do.

That control layer matters because context is not free. For agents, transmitting context can cost about as much as acting on it, even though an agent can be forked or repurposed at will. A handoff should therefore be an explicit contract, not an unexamined transcript dump. Our guide to multi-agent orchestration patterns compares the broader control topologies behind those contracts.

Anthropic's Managed Agents leaves agent count open

The Anthropic multi-agent architecture described for Managed Agents is a meta-harness. Its general interfaces can accommodate different specific harnesses around Claude. Those can include Claude Code as well as task-specific agent harnesses that excel in narrow domains.

This is a useful distinction from drawing a fixed set of boxes and calling that the architecture. The meta-harness defines common interfaces around potentially different harnesses. Those interfaces should support state manipulation through the session and computation through the sandbox. The surrounding system can then provide a common control surface without pretending that every inner harness performs the same work.

Managed Agents is designed to run many brains and many hands over long time horizons without assuming a fixed number or location for them. The count stays open. So does the placement. In architecture terms, the stable object is the interface and harness relationship, not a permanent roster of agent identities.

For a builder, that creates two concrete interface questions. What state can a harness manipulate through its session? What computation can it perform through its sandbox? Answering those questions gives the surrounding meta-harness a defined surface for different inner harnesses. Claude Code and a narrow task-specific harness may do different work, but the general interfaces can still accommodate both.

The open count also prevents the architecture diagram from becoming the contract. A deployment can involve different numbers and locations of brains and hands. The common interface carries the design, while the roster can vary. That is a more durable boundary than assigning permanent meaning to "agent one" or "agent two."

Review the architecture at two levels. At the specific-harness level, identify the narrow work and the session or sandbox interface it needs. At the meta-harness level, identify what must remain general enough to accommodate different harnesses. This keeps the design centered on interfaces that Anthropic describes, while leaving the number and location of brains and hands open.

That changes what deserves attention during design. Do not begin by filling a diagram with a supervisor and a preferred number of workers. Begin with the state and computation interfaces that different harnesses need. Then identify which responsibilities belong inside a narrow harness and which belong in the meta-harness around it. Our AI agent architecture patterns guide provides additional structures for making that boundary visible.

Two implementation examples make the control layer concrete

A deployment on AWS shows one way to separate workflow control from local reasoning. In that LangGraph-and-Strands architecture, LangGraph handled macro-level coordination, state persistence, and workflow recovery. Strands handled the reasoning performed inside individual nodes. The example also used checkpoint-based recovery and comprehensive observability to support production reliability.

The value of the example is the division of responsibility. Workflow state and recovery remain concerns of the coordinating layer. Reasoning stays inside the nodes. That makes the control boundary concrete without turning one vendor deployment into a universal blueprint.

A second example starts from distributed-systems abstractions. State machines and the Actor model can manage state, concurrency, and message-driven communication when used with LLM agents. They can support observability, reliability, and control. This view shifts the design conversation away from agent personas and toward transitions, messages, and ownership of state. Those are the mechanics the system must operate when several reasoning components act over time.

The two examples work at different levels. The AWS deployment names a concrete division between coordination and node-level reasoning. State machines and the Actor model supply abstractions for the state, concurrent work, and messages behind such systems. Neither example decides the agent count. Each makes part of the control problem explicit, so it can be observed and operated alongside the reasoning work.

Use the examples to locate control, not to copy their labels. In the AWS design, macro-level coordination, persisted state, and recovery sit outside the reasoning inside individual nodes. In the distributed-systems view, state machines and actors offer ways to manage state, concurrency, and message-driven communication. The practical question is which layer owns each mechanism in the architecture being built.

How do multi-agent systems fail differently?

Multi-agent failures can propagate across boundaries. Errors compound in agentic systems, and one failed step can send agents onto different trajectories with unpredictable outcomes. A local mistake can therefore change what later agents see, what they decide, and where the overall run ends.

This is different from inspecting one isolated response. The system has a trajectory made of intermediate actions and handoffs. When those paths diverge, examining only the final answer hides where the divergence began. Explicit planning, state, and observability give the operator places to inspect that path. They do not make the failure disappear, but they make its movement through the system visible.

Autonomy also changes accountability. Decentralized agent autonomy complicates oversight and accountability. The more responsibility is spread across communicating agents, the less useful it becomes to ask only which model produced the final text. The architecture must preserve enough information to examine the relevant actions, messages, state changes, and controls.

Finally, interacting agents can magnify risks inherited from large language models. A review of orchestrated systems identifies hallucination, bias, and data leakage as risks that require rigorous evaluation and control frameworks. Autonomous agents that communicate and coordinate also have failure modes that differ from single-agent systems.

Failure review should follow the actual trajectory. Locate the failed step, the point where paths diverged, and the later outcomes. Inspect oversight and accountability across decentralized actions. Then evaluate hallucination, bias, and data leakage across agent interactions, not only within one isolated response. These are separate checks because the known failure modes include propagation, weaker accountability, and magnified model risks.

That review needs records from the orchestration layer. Planning steps, state changes, messages, and quality operations are useful inspection points already present in the architecture. They let an operator examine the collective path and the individual work without treating the final answer as the whole system.

A practical build order moves from scaffold to production discipline

Build from a small scaffold toward production discipline. A framework can accelerate initial development, but a reliable production system needs more than agent code that works on a developer machine. Anthropic's material gives a useful order without turning a reference architecture into a template that every workload must copy.

The first stage can use the Claude Developer Platform, which provides access to models, tools, and technical documentation for implementing AI agents. The related Building Effective AI Agents PDF covers common use cases, architecture patterns, future directions, and implementation steps. If your search started with an "Anthropic multi-agent orchestration PDF," this is the implementation guide in the supplied material. It should inform a workload-specific design, not replace one.

The platform and guide play different roles in that work. The platform supplies access to models, tools, and technical documentation. The guide covers use cases, common architecture patterns, future directions, and implementation steps. Together, those materials give you implementation inputs and a set of patterns to examine. The workload still decides whether the system needs multiple agents and which operating boundaries it must carry.

Anthropic's account, "How we built our multi-agent research system," draws a firm line between code that runs on a developer machine and a reliable production system. Production requires substantial added engineering. For multi-agent research at scale, that work includes careful engineering, broad testing, detailed prompt and tool design, robust operations, and close collaboration among research, product, and engineering teams that understand current agent capabilities.

Apply this order to the failure that justified multiple agents in the first place. Keep the planning visible, define the interfaces, and harden the operating path. Then use our broader multi-agent build guide to turn those decisions into an implementation plan.