Chapter 12: Multi-agent systems
The chapter introduces the need to coordinate specialized agents in a travel assistant that handles both travel information and accommodation booking.
After this chapter you will be able to
- Coordination of specialized agents. Explain why a travel assistant might coordinate multiple specialized agents rather than rely on a single travel-information agent, using travel questions and accommodation booking as the example.
- Action Beyond Information Retrieval. Explain why a practical travel assistant needs the ability to act as well as retrieve information.
- Hotel data through tools. Explain how the agent can retrieve hotel offers, details, and room availability from a local SQLite database through toolkit tool calls rather than raw SQL in its prompts.
- B&B availability tool setup. Describe what the B&B booking tool retrieves, why its REST service is mocked for development and testing, and the stated order of setup.
- Accommodation Tool Selection. Explain how the accommodation booking agent uses its hotel and B&B tools, including what it does when a user gives no accommodation preference.
- Router Agent Role. Explain how a router agent combines the two specialized agents into a single conversational entry point by sending each user request to the agent suited to handle it.
- Structured router agent choice. Describe how the router defines its two available agent types and uses a Pydantic output model so the OpenAI client returns which agent should handle a query without manual string parsing.
- Router classification and handoff. Trace how the router uses a system prompt and the user’s message to select a specialist agent, then redirects the workflow to that agent’s node.
- Dynamic router graph connections. Trace how a user query moves from the router agent to either specialist agent and then to the end of the workflow. Distinguish the explicit end edges from the router’s runtime connection, which is handled by Command based on the LLM’s response.
- One-way specialist routing. Explain how the router handles a user question, using the attractions and room-availability examples to identify which specialist responds.
- Cross-domain request coordination. Explain why the router-based design cannot effectively answer a request spanning travel information and accommodation booking, and describe the Supervisor’s role in coordinating the agents.
- Supervisor agent orchestration. Explain how a Supervisor manages specialized agents, choosing which to invoke and potentially invoking agents multiple times in one workflow.
- Return ticket agent interactions. Distinguish a workflow-based router’s one-time dispatch from a Supervisor’s ability to invoke and revisit agents within a session. Explain that the Supervisor can collect and combine intermediate results for open-ended or multipart requests.
- Supervisor agent execution flow. Trace how the travel_assistant uses the travel information agent and then the accommodation booking agent, with each agent calling its own tools. Explain that the Supervisor coordinates the agents dynamically by treating them as tools.
What it builds on
- Starting simple: Building a single-tool travel info agent (chapter 11) · The single travel-information agent that this chapter expands.
- Enabling agents to call tools (chapter 11) · Agents calling tools to do more than provide information
- Executing tool calls (chapter 11) · Agents executing tool calls.
- Setting up and connecting to the database (chapter 10) · Setting up and connecting to a SQLite database.
- The LLM node: Coordinating reasoning and action (chapter 11) · An agent’s coordination of reasoning and tool-based action.
Section by section
Introduction
The chapter introduces the need to coordinate specialized agents in a travel assistant that handles both travel information and accommodation booking.
- Coordination of specialized agents: Explain why a travel assistant might coordinate multiple specialized agents rather than rely on a single travel-information agent, using travel questions and accommodation booking as the example.
Why it matters: This distinction explains why the travel assistant expands beyond the single agent built in the previous chapter.
Key terms: single, specialized agent, multi-agent travel assistant, travel information agent, accommodation booking agent
12.1 Building an accommodation booking agent
The section introduces accommodation booking as a way to make a travel assistant capable of acting, not just retrieving information.
- Action Beyond Information Retrieval: Explain why a practical travel assistant needs the ability to act as well as retrieve information.
Why it matters: This distinction explains why the travel assistant is being extended beyond answering questions.
Key terms: information retrieval, ability to act, travel assistant
12.1.1 Hotel booking tool
The section prepares a local hotel database and makes it available to an agent through LangChain’s SQL Database toolkit.
- Hotel data through tools: Explain how the agent can retrieve hotel offers, details, and room availability from a local SQLite database through toolkit tool calls rather than raw SQL in its prompts.
Why it matters: This explains where the hotel information comes from and how the agent accesses it. - Hotel database preparation: Describe the preparation and verification sequence: copy the existing script, put the supplied schema in a hotel_db folder, create the database from that setup, and check it in the SQLite shell.
Why it matters: Checking the database first helps separate database setup problems from agent integration problems. - SQL toolkit initialization: Describe the Python-side sequence after database setup: import LangChain’s SQL integration libraries, instantiate the SQLite database, and create a SQL Database toolkit instance to access its tools.
Why it matters: These steps make the prepared hotel database available through agent tools.
Key terms: SQL Database toolkit, agent tools, SQLite database, tool calls, hotel_db, cornwall_hotels_schema.sql, SQLite shell, LangChain SQL integration libraries
12.1.2 B&B booking tool
This subsection introduces a B&B availability tool backed by a REST service and uses a mock service for development and testing.
- B&B availability tool setup: Describe what the B&B booking tool retrieves, why its REST service is mocked for development and testing, and the stated order of setup.
Why it matters: It establishes what the accommodation agent’s B&B tool is for without requiring a live booking service during development.
Key terms: B&B booking tool, REST service, BnBBookingService, check_bnb_availability
12.1.3 ReAct accommodation booking agent
This section introduces a ReAct accommodation booking agent that uses hotel and B&B tools, then identifies why it is not yet a unified travel assistant.
- Accommodation Tool Selection: Explain how the accommodation booking agent uses its hotel and B&B tools, including what it does when a user gives no accommodation preference.
Why it matters: This is the booking behavior the reader should recognize when trying out the agent. - Disconnected Travel Agents: Describe the limitation of having the travel information agent and accommodation booking agent as separate agents.
Why it matters: This limitation motivates bringing the agents together in the next section.
Key terms: ReAct accommodation booking agent, hotel database, mock B&B service, travel information agent, accommodation booking agent, unified experience
12.2 Building a router-based travel assistant
Introduces a router agent that directs travel information and accommodation booking requests to the appropriate specialized agent within one conversation.
- Router Agent Role: Explain how a router agent combines the two specialized agents into a single conversational entry point by sending each user request to the agent suited to handle it.
Why it matters: Routing lets users ask about travel and accommodation in one conversation without choosing an agent themselves.
Key terms: router agent, travel information agent, accommodation booking agent, specialized agent
12.2.1 Designing the router agent
This section sets up a router agent to return a structured choice between two agents in a multi-agent travel assistant.
- Structured router agent choice: Describe how the router defines its two available agent types and uses a Pydantic output model so the OpenAI client returns which agent should handle a query without manual string parsing.
Why it matters: A structured, limited choice gives the travel assistant a clear result to use when routing a query.
Key terms: router agent, enumeration, Pydantic model, structured format, travel_info_agent, accommodation_booking_agent
12.2.2 Routing logic
This section explains how a LangGraph router classifies a user request and hands it to the selected specialist agent.
- Router classification and handoff: Trace how the router uses a system prompt and the user’s message to select a specialist agent, then redirects the workflow to that agent’s node.
Why it matters: This explains how a request reaches the appropriate specialist in the multi-agent workflow.
Key terms: system prompt, router agent, entry node, AgentTypeOutput, Command, travel information agent
12.2.3 Building the multi-agent graph
This section explains how the router-based travel assistant graph connects to specialist agents and why its architecture combines workflow routing with flexible tool use.
- Dynamic router graph connections: Trace how a user query moves from the router agent to either specialist agent and then to the end of the workflow. Distinguish the explicit end edges from the router’s runtime connection, which is handled by Command based on the LLM’s response.
Why it matters: This distinction explains how the graph can route a request without defining a fixed edge from the router to each specialist. - Hybrid workflow and tool decisions: Explain why the travel assistant is described as a hybrid architecture, distinguishing its top-level workflow-driven routing from the more flexible tool-based decisions within each specialist agent.
Why it matters: It clarifies why a structured routing workflow can still contain agents that make dynamic tool decisions.
Key terms: router agent, travel information agent, accommodation booking agent, Command, explicit edges, hybrid architecture, workflow-driven routing logic, specialist agent, tool-based decision process
12.2.4 Trying out the router agent
This section shows how the router-based travel assistant sends each question to one specialist agent and then ends the workflow.
- One-way specialist routing: Explain how the router handles a user question, using the attractions and room-availability examples to identify which specialist responds.
Why it matters: This one-way handoff is the behavior the later Supervisor workflow builds beyond.
Key terms: router agent, travel information agent, accommodation booking agent, one-way ticket
12.3 Handling multi-agent requests with a Supervisor component
The section explains why a router-based travel assistant cannot handle requests that need both specialist agents and introduces the Supervisor as a way to coordinate them.
- Cross-domain request coordination: Explain why the router-based design cannot effectively answer a request spanning travel information and accommodation booking, and describe the Supervisor’s role in coordinating the agents.
Why it matters: It explains when choosing one agent is insufficient and coordination becomes necessary.
Key terms: router-based design, travel information agent, accommodation booking agent, Supervisor, intermediate results
12.3.1 The Supervisor pattern: An agent of agents
This section introduces the Supervisor as an agent that coordinates specialized agents and explains the main choices involved in setting one up for the travel assistant.
- Supervisor agent orchestration: Explain how a Supervisor manages specialized agents, choosing which to invoke and potentially invoking agents multiple times in one workflow.
Why it matters: This explains how one travel assistant can coordinate several specialist agents. - Supervisor configuration choices: Describe how setting up a Supervisor differs from setting up a ReAct agent and why managed agents need unique names.
Why it matters: It identifies the key configuration change when turning the travel assistant into a Supervisor-based assistant. - Supervisor model choice: Justify the recommendation to use a more powerful LLM for the Supervisor when handling complex requests.
Why it matters: The coordinating agent’s model choice can affect how well the assistant handles multifaceted requests.
Key terms: Supervisor, agent of agents, orchestrator, specialized tool, ReAct agent, unique name, list of agents, powerful LLM, complex multi-step requests, task decomposition
12.3.2 From “one-way” to “return ticket” interactions
This section contrasts one-time router dispatch with a Supervisor that can coordinate and revisit specialized agents to handle multipart travel requests.
- Return ticket agent interactions: Distinguish a workflow-based router’s one-time dispatch from a Supervisor’s ability to invoke and revisit agents within a session. Explain that the Supervisor can collect and combine intermediate results for open-ended or multipart requests.
Why it matters: This distinction explains why the Supervisor can address requests that need more than a single agent dispatch. - Supervisor orchestration roles: Describe the Supervisor as the central decision-maker that activates the appropriate agent or sequence of agents, with tool-based orchestration at both the Supervisor and agent/tool levels.
Why it matters: It clarifies the Supervisor’s coordinating role without confusing it with the specialized agents’ tool use.
Key terms: workflow-based router, Supervisor, one-way ticket, return tickets, intermediate results, high-level orchestration, low-level orchestration, tool-based approach
12.3.3 Trying out the Supervisor agent
A LangSmith trace shows how a Supervisor travel assistant coordinates two specialist agents to answer a multi-part request.
- Supervisor agent execution flow: Trace how the travel_assistant uses the travel information agent and then the accommodation booking agent, with each agent calling its own tools. Explain that the Supervisor coordinates the agents dynamically by treating them as tools.
Why it matters: The trace makes it possible to see how one assistant handles a request that needs more than one specialist agent.
Key terms: Supervisor, travel_assistant, travel_info_agent, accommodation_booking_agent, agents as tools, LangSmith trace
12.4 Summary
This summary contrasts router and supervisor agents and recaps practices for making multi-agent handoffs reliable and observable.
Where this is used later
- Adding short-term memory to our travel assistant (chapter 14) · The router-based travel assistant being modified.
- Implementing guardrails to reject nontravel-related questions (chapter 14) · The router’s existing choice between travel and weather agents.
- Deployment on the LangGraph platform and Open Agent Platform (chapter 14) · The supervisor agent pattern used as an example of an OAP prebuilt pattern.
Concepts explained in this chapter
- routingA router function is a callable that examines workflow conditions and returns the name of the next execution path.
- agent orchestrationA supervisor agent is an agent that coordinates a group of more granular agents to accomplish a larger task.
- multi-agent systemA multi-agent system is a software system in which multiple agents independently or cooperatively perform tasks and pursue goals.
- specialized agentA specialized agent is an agent configured with a distinct role and tool set for a particular type of task.
- trajectoryExecution history is the recorded sequence of workflow decisions, transitions, and intermediate states produced during graph execution.
- prompt engineeringPrompt design is the practice of formulating instructions and context to influence a language model's behavior and output.
- stateState is the structured information representing a workflow's progress, intermediate results, failures, and contextual values across processing steps.
- toolA tool is an instrument or software capability that enables a person or system to perform a task, obtain information, or interact with resources.
- tool usageA tool call is a structured model response that requests invocation of a named tool with supplied arguments.
- structured dataA table is structured data arranged into rows and columns, typically representing related records or values.
- ReActA ReAct agent is an agent architecture that interleaves reasoning with actions such as invoking tools and observing their results.
- graph-based workflowA graph structure is a workflow organization in which nodes and edges define execution order and data flow, potentially including dynamic branches.
- promptA system prompt is an instruction message supplied to a language model to establish high-level behavior or constraints.
- debuggingDebugging is the systematic diagnosis and correction of faults in software execution or behavior.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.