A multi-agent system connects several agents so they can work on a goal through distinct roles, coordinated actions, or communication. A single agent may handle many tasks, but dividing work becomes useful when it needs too many tools or instructions, must process many items, or cannot hold all the relevant context at once. section 1.4 section 1.6
Start with a support desk
Instead of asking one agent to handle every request, assign triage, billing, and technical support to focused agents. The design question is then not just what each agent can do, but how a request reaches the right one and how its result moves onward. section 1.4 section 4.1
Three patterns provide a starting point. They can be mixed; none is mandatory for a particular task.
- Agent flow: specialized workers act in sequence, like an assembly line. Use it for a well-defined, multistep task with designated roles. section 1.6
- Orchestration: a central agent plans and delegates to specialized workers, which return their results. section 1.6 section 4.1
- Collaboration: agents with defined roles communicate, give feedback, and critique one another. This can address complex problems, but adds computation and latency. section 1.6
Figure 4.1 The three well-established patterns for building multi-agent systems: agent flow (assembly line), orchestrator (hub-and-spoke), and collaboration (peer-to-peer).
Compare the paths work takes through an assembly line, a central coordinator, and a peer-to-peer team. section 4.1
For each handoff, separate three questions: Who decides the next action? Who can execute it? What information passes between them? A planner may decide without using a tool; a worker may execute without choosing the next task. Give each decision-maker enough context to act, without burying the relevant signal. section 4.1
More agents are not automatically better. Unconstrained subgoal loops proved brittle; additional agents can also raise cost, latency, and unpredictability. Keep responsibilities and communication channels defined. Typed input and output schemas can make handoffs less dependent on parsing free-form responses, while traces expose interactions and tool calls for debugging. section 4.0 section 2.6
As the system becomes dependable infrastructure, decide where agents run, how they communicate, how state persists, and how changes are rolled out. Security, governance, compliance, and scaling require further production-specific decisions. section 8.3 section 1.5
