4 Architecting and building multi-agent systems

The chapter introduces multi-agent systems as a practical response to the limits of a lone agent. As tasks become broader, more tool-heavy, or more difficult to reason through in one pass, developers split work across multiple agents to improve specialization and manageability. The text emphasizes that multi-agent designs can be powerful, but they also add cost, latency, and unpredictability, so they should be adopted deliberately rather than by default.

It then lays out the main architectural and coordination patterns used in agent systems: sequential flows, orchestration, collaboration, parallel delegation, hierarchical coordination, debate and refinement, voting, role-playing, conditional routing, and peer-to-peer networks. Across these patterns, three core concerns recur: who makes decisions, who controls execution, and how agents communicate. The chapter argues that simpler flows are usually easier to build, debug, and evaluate, while more centralized or decentralized structures offer greater flexibility only when the problem truly needs them.

Finally, the chapter focuses on making agent flows safer and more reliable through handoffs and guardrails. It shows how to pass work between agents either through explicit code or built-in handoff mechanisms, how to visualize and monitor those transitions, and how to validate inputs and outputs with guardrails or retry loops. The overall message is to keep agent architectures as simple and typed as possible, add structure only where needed, and use guardrails to preserve predictable behavior as workflows grow more complex.

The three well-established patterns for building multiple agent systems, from the agent flow (assembly line), orchestrator (hub-and-spoke), to the collaboration (peer to peer).

Decision-making (command) and control demonstrated for more specialized multi-agent architectures, the flow, orchestration and manager architectures.

Comparing different agent communication patterns represented in a flow.

Various ways agents may coordinate execution sequentially or in parallel.

A single agent is transformed into a multi-agent flow of agents. The agent role is broken down into three well-defined and distinct roles/agents that each encapsulate a well-defined set of tools, appropriate to each of those roles. The single agent becomes a flow of Research Tools agent, Planning agent and Filesystem agent.

shows an agent-to-agent flow with a deterministic (coded) decision point added. Taking the decision away from the agents and making it deterministic keeps the agent flow more deterministic and consistent.

three agent flow communication patterns demonstrating how agents can pass messages from one another and in turn pass command and control from agent to agent.

There are two ways to visualize the agent flow using draw_graph and the Traces page that can be found on the OpenAI Dashboard under logs.

Guardrails can be used to validate and control input and output from an agent, or agent flow.

Traces page after executing the Orchestration agent shows X and Y.

• Single-agent designs often hit scalability walls; converting a monolithic agent into an agentic flow (a chain of specialised agents) restores clarity, extensibility, and performance.
• Agent-to-agent flows work like prompt-chaining with superpowers: each node can invoke tools and reason independently yet pass concise, typed outputs downstream to keep the context lean.
• Insert deterministic decision points (code or schema checks) wherever the flow must repeat reliably; don’t rely on stochastic LLM judgment for pass/fail branches.
• The OpenAI Agents SDK supports two hand-off styles: conversational (shared thread) and pass-off (explicit code routing). Choose conversational for speed and pass-off for fine-grained control.
• Use the handoffs field of the agent plus clear instructional prompts to enable internal hand-offs that require zero extra orchestration code.
• Visualise complex flows early using draw_graph(), and the Dashboard Traces view reveals hidden loops, tool chains, and latency hotspots.
• Wrap risky transfers in guardrails—input/output validators that reject, retry, or correct data before it corrupts the flow; tripwires surface as explicit exceptions you can loop on.
• Guardrails themselves can be LLM-powered agents, giving you natural-language policies without brittle regex or length checks—remember they, too, need schemas and tests.
• Tool limits still matter in multi-agent worlds: every registered tool inflates every call; keep each agent’s tool list tight (< 10) and scoped to its role to avoid token bloat.
• Flow, orchestration, and manager-worker are the three canonical decision patterns. Start with plain flows and graduate to orchestrators only when centralised delegation is truly required.
• Choose one communication layer (shared memory, message passing, MCP, or emerging A2A protocol) per project; mixing channels multiplies debugging pain.
• A production-ready agentic flow blends typed I/O, deterministic checkpoints, visual traces, scoped tool sets, and guardrails—yielding pipelines that can scale, recover, and evolve without surprise.
• Agents may be coordinated using multiple different strategies: Sequential Flow, Parallel Delegation, Hierarchical Coordination, Iterative Debate and Refinement, Voting / Best-of-N (Ensemble), Role-Playing Collaboration, Conditional Routing (Branching), and Peer-to-Peer Network

FAQ