Chapter 8: Multi-agent systems

Introduction

The introduction explains why a customer request spanning images, products, and policies calls for coordinated specialist agents rather than isolated tools or one overloaded model.

• Multipart request coordination: Explain why the customer's photo, waterproof-boot question, and return-policy question require several capabilities whose results must be combined into one response.
  Why it matters: Individual tools are useful, but a customer needs one coherent answer to the whole request.
• Specialized agent architecture: Justify the section's preference for specialized agents coordinated by an orchestrator over a single LLM handling every responsibility.
  Why it matters: Dividing responsibilities gives the system a way to handle varied requests without asking one model to do everything.

Key terms: multipart request, MCP tools, response coordination, multi-agent architecture, specialized agents, intelligent orchestrator, coordination layer, context window

8.1 Multi-agent systems

This section introduces the shift from individual AI capabilities to orchestrating them in multi-agent systems for complex conversations.

8.1.1 Why multi-agent architecture matters

The section uses a shopping request to show why specialized, coordinated agents can handle mixed customer needs better than one agent trying to do everything.

• Three needs in one query: Describe why the jacket-and-warranty request calls for product search, policy knowledge, and conversation coordination.
  Why it matters: Recognizing the different needs within one request makes the case for dividing the work.
• Specialized agents versus one generalist: Explain the monolithic agent problem and distinguish the responsibilities of SearchAgent, PolicyAgent, and Coordinator in the proposed multi-agent solution.
  Why it matters: Separating responsibilities helps avoid making one agent handle every part of a mixed request.

Key terms: Product search, Policy knowledge, Conversation coordination, monolithic agent problem, multi-agent solution, SearchAgent, PolicyAgent, Coordinator

8.1.2 Introducing LangGraph: The multi-agent framework

Introduces LangGraph as a multi-agent framework and defines the shared state, workflow structure, and coordination capabilities it provides.

• LangGraph workflow building blocks: Describe how LangGraph represents a multi-agent workflow using shared state, nodes, edges, and conditional edges.
  Why it matters: These terms give you a way to describe how agents share information and how work moves between them.
• Multi-agent coordination capabilities: Explain what LangGraph adds beyond simple function calling or basic routing, including support for multistep collaboration, fallbacks, and workflow visibility.
  Why it matters: A multi-agent workflow needs to handle collaboration and problems, not just select an agent once.

Key terms: State, Nodes, Edges, Conditional edges, Cycle management, Error handling, Observability

8.1.3 Building intelligent agent coordination

This section explains how semantic intent analysis and conditional routing coordinate agents for different user queries.

• Intent Based Agent Coordination: Explain how a multi-agent system uses LLM function calling to analyze a user’s intent rather than relying on keyword matching, then uses LangGraph conditional routing to send the query to an appropriate agent.
  Why it matters: Routing by intent helps the system choose an agent suited to each query instead of following a brittle keyword rule.

Key terms: intelligent coordination, semantic understanding, function calling, conditional routing, LangGraph

8.1.4 Real-world example: ShopBot multi-agent system

ShopBot illustrates how a shopping assistant can coordinate specialized product-search and policy-answering agents, ground answers in company knowledge, and assign models according to task difficulty.

• Specialized product search: Explain why ShopBot has a separate SearchAgent and what it provides to the rest of the system.
  Why it matters: Separating search makes product matching easier to improve without entangling it with other workflows.
• Grounded policy answers: Explain how ShopBot’s QAAgent answers questions about business policies and why it uses RAG.
  Why it matters: Policy answers are more trustworthy when they draw on company documents rather than the model’s unsupported guesses.
• LangGraph agent coordination: Describe LangGraph’s role when a ShopBot request calls for product search, policy answers, or both.
  Why it matters: Specialized agents become one useful assistant only when their work is routed and combined.
• Task matched model assignment: Justify ShopBot’s use of a smaller model for straightforward tasks and a more capable model for demanding responses.
  Why it matters: Using a stronger model where it matters most can avoid paying for that capability on simpler routing tasks.

Key terms: SearchAgent, product search, MCP, QAAgent, RAG, business policies, grounded, LangGraph, orchestration, intent analysis

8.1.5 Running your multi-agent system

8.1.6 Adding vision: Image-based product search with VisionAgent

This section shows how ShopBot handles a product query that combines an image with text by turning the image into a caption and reusing its existing search workflow.

• Image and text search flow: Trace how a shopper’s image and text become a product search: a captioning model describes the image, the caption is combined with the shopper’s constraints, and SearchAgent searches using the combined text.
  Why it matters: This lets an image-based request use the product search and response workflow ShopBot already has.
• VisionAgent responsibility boundary: Distinguish the preprocessing step that produces an image caption from what VisionAgent does with that caption, and explain why this does not require new product-search logic.
  Why it matters: The boundary makes clear which component handles the image and which existing component handles product search.

Key terms: multimodal query, captioning model, SearchAgent, AgentResponse, VisionAgent, captioning step, preprocessing step

8.1.7 What you built and why it matters

Summarizes ShopBot’s coordinated multi-agent architecture and explains why specialized agents are easier to extend and maintain than a monolithic system.

• ShopBot coordination and response flow: Describe how ShopBot’s orchestrator routes user intent to specialized search, policy Q&A, or vision-search agents, preserves their work in shared state, and synthesizes a unified response.
  Why it matters: This explains how ShopBot handles questions that may need more than one kind of agent without presenting disconnected answers.
• Benefits of specialized agents: Explain why separate agents make ShopBot easier to test, extend, and maintain, and why a problem in one agent need not stop the others.
  Why it matters: Separating responsibilities makes changes and failures less likely to disrupt the whole shopping assistant.

Key terms: LangGraph orchestrator, specialized agents, state management, synthesis step, modularity, scalability, reliability, maintainability, degrades gracefully

8.2 Testing multi-agent workflows

This section explains why multi-agent systems need end-to-end workflow tests and identifies five categories for checking their reliability and user experience.

• End-to-end workflow validation: Explain why testing agents in isolation is insufficient for a multi-agent system and what end-to-end tests must check.
  Why it matters: Agents can each pass their own tests while the overall conversation still fails at a handoff.
• Five workflow testing categories: Describe the five categories of multi-agent workflow tests and the distinct concern each addresses.
  Why it matters: These categories help reveal different ways an otherwise functional multi-agent workflow can disappoint users.

Key terms: end-to-end tests, orchestration layer, state flows, integration points, blended queries, ambiguous intent, agent failure, state flow, regression testing

8.2.1 Category 1: Blended queries and multimodal interactions

This subsection explains what blended-query tests check when users combine visual input, text, and follow-up questions.

• Blended Query Test Purpose: Explain that blended query tests check whether an orchestrator recognizes complex requests, routes them through multiple specialized agents, and preserves critical context.
  Why it matters: A response can reach the right agents yet still fail if important parts of the user’s request are lost.

Key terms: blended query tests, orchestrator, specialized agents, critical context

8.2.2 Category 2: Ambiguous intent and robust routing decisions

This subsection explains what ambiguous-intent tests should check in a multi-agent system’s routing decisions.

• Ambiguous intent routing tests: Explain why routing should be tested with unclear user requests and what a graceful response looks like.
  Why it matters: Testing unclear requests helps catch routing decisions that would frustrate real users.

Key terms: ambiguous queries, orchestrator, routing logic

8.2.3 Category 3: Agent failure and resilience verification

This section explains why multi-agent workflows should be tested for helpful responses when individual agents or infrastructure components fail.

• Agent failure resilience tests: Explain that agent failure tests simulate outages or unavailable agents to check whether a multi-agent orchestrator degrades gracefully and still gives users helpful responses instead of crashing.
  Why it matters: A production system needs to remain useful when an agent or its supporting infrastructure is unavailable.

Key terms: agent failure tests, resilience testing, degrading gracefully

8.2.4 Category 4: State flow and information preservation across the workflow

This section explains why multi-agent workflows need state flow tests to ensure user requirements survive every handoff.

• State flow preservation tests: Explain how shared state carries user requirements across agents and what state flow tests verify. Describe how failed state management can affect the final response.
  Why it matters: A final answer can be wrong even when individual agents work if a user's constraints disappear between them.

Key terms: shared state, state flow tests, information preservation

8.2.5 Regression: Moving forward without breaking what worked

This section recommends rerunning multi-agent workflow tests as the system changes and adding a test for every discovered bug.

• Regression testing as a habit: Explain why existing tests should be rerun when features or agents are added, and why each discovered bug should become a test.
  Why it matters: Regression tests give you an early warning when a change breaks something that previously worked.

Key terms: regression, old flows, safety net

8.3 Alternative framework: CrewAI

Introduces CrewAI as a team-oriented alternative to LangGraph for building multi-agent systems.

• CrewAI and LangGraph approaches: Distinguish LangGraph’s fine-grained control of state and routing from CrewAI’s role-and-goal-based approach, in which the framework handles much of the coordination.
  Why it matters: This distinction helps you understand what each framework asks you to specify when building a multi-agent system.

Key terms: LangGraph, CrewAI, state, routing, roles, goals

8.3.1 LangGraph vs. CrewAI: Different philosophies

This section contrasts LangGraph’s explicit workflow design with CrewAI’s role-based agent collaboration and explains the control-versus-convenience tradeoff.

• Framework mental models and tradeoffs: Distinguish how LangGraph and CrewAI organize multi-agent systems, and explain when each approach fits and what control or coding effort it trades away.
  Why it matters: The distinction helps you choose between precise workflow control and easier task-based collaboration.

Key terms: LangGraph, CrewAI, states, nodes, and edges, roles, goals, and backstories, routing logic

8.3.2 ShopBot with CrewAI

The section outlines the steps for rebuilding a simplified ShopBot with CrewAI.

• CrewAI ShopBot build sequence: Describe the outlined sequence for a simplified CrewAI ShopBot: install CrewAI, define tools and agents, create tasks, assemble the crew, and test the implementation.
  Why it matters: This sequence shows how the section organizes a CrewAI version of ShopBot without requiring details that are not in the text.

Key terms: ShopBot, CrewAI, tools, agents, tasks, crew

8.3.3 When to use which multi-agent framework

This section explains how workflow complexity, team preferences, and desired control guide the choice between LangGraph and CrewAI.

• Multi-agent framework selection tradeoffs: Distinguish when LangGraph or CrewAI is the better fit based on workflow structure, team background, and the need for control or speed.
  Why it matters: Matching the framework to the workflow helps you choose between explicit control and faster setup.

Key terms: LangGraph, CrewAI, explicit graph structure, cycles, role-based approach

8.3.4 The framework landscape

This section surveys other multi-agent frameworks and argues that choosing a tool matters less than understanding reusable coordination patterns.

• Framework Choice Principle: Explain why framework choice should depend on the problem and the builder’s mental model, with complexity added only as needed.
  Why it matters: A framework should serve the system you need to build, not dictate it.
• Transferable Coordination Patterns: Explain why understanding multi-agent patterns matters more than mastering a particular framework, and name the patterns this section identifies.
  Why it matters: Reusable patterns remain useful even when you change frameworks.
• Alternative Framework Emphases: Distinguish the emphases the section assigns to AutoGen, Agency Swarm, and Haystack.
  Why it matters: Their different emphases illustrate why the framework should fit the task.

Key terms: mental model, requirements, framework, intent analysis, agent specialization, state management, error handling, response synthesis, AutoGen, Agency Swarm

8.4 Summary