What will I learn in chapter 11 of AI Agents and Applications?

The introduction contrasts deterministic LangGraph workflows with agents that use an LLM to make context-sensitive tool decisions. After reading it you should be able to: Distinguish a deterministic agentic workflow from an agent that uses an LLM to choose tools and their order as a task evolves. Describe the planned travel agent’s information source and tool: it uses a vector store retriever to answer questions about Cornwall’s destinations and resorts from chunked Wikivoyage content. Describe how to prepare the chapter 11 project: open the ch11 folder in a VS Code terminal, create and activate a virtual environment, then install the dependencies from requirements.txt. Describe where to load the API key in main_01_01.py once the .env file is ready. Trace how the setup turns Wikivoyage pages for selected Cornwall destinations into information searchable by semantic similarity. Explain why the downloaded text is split into overlapping chunks before embedding. Explain how the singleton initialization avoids rebuilding the vector store and how the resulting retriever gives the agent access to travel information. Distinguish tool calling from earlier function calling and describe what a tool lets an LLM do. Justify using an agent with tool calling rather than hardcoded API calls when tool needs cannot be predicted.

What does section 11.1.1, Project setup, cover?

Sets up the chapter 11 Python project, its API key and debugger configuration, and a naming convention for successive agent scripts. Describe how to prepare the chapter 11 project: open the ch11 folder in a VS Code terminal, create and activate a virtual environment, then install the dependencies from requirements.txt. State where the section puts the OpenAI API key and the VS Code debugging configuration. Explain what x and y represent in main_x_y.py and why the section uses that naming convention.

What does section 11.1.2, Loading environment variables, cover?

This subsection tells readers where to load the API key in the travel agent script after preparing the .env file. Describe where to load the API key in main_01_01.py once the .env file is ready.

What does section 11.1.3, Preparing the travel information vector store, cover?

This section prepares a searchable Wikivoyage knowledge base for the Cornwall travel agent and makes it reusable through a retriever. Trace how the setup turns Wikivoyage pages for selected Cornwall destinations into information searchable by semantic similarity. Explain why the downloaded text is split into overlapping chunks before embedding. Explain how the singleton initialization avoids rebuilding the vector store and how the resulting retriever gives the agent access to travel information.

What does section 11.2.1, From function calling to tool calling, cover?

This section explains what tool calling adds to LLMs, why agents use it for flexible decisions, and how ReAct alternates reasoning with tool use. Distinguish tool calling from earlier function calling and describe what a tool lets an LLM do. Justify using an agent with tool calling rather than hardcoded API calls when tool needs cannot be predicted. Trace how the ReAct pattern moves from a user question through reasoning, optional tool actions, and a final answer.

What does section 11.2.2, How tool calling works with LLMs, cover?

Explains what an LLM receives when a tool is registered and illustrates tool registration with a decorated travel-search function. Explain that registering a tool exposes its name, parameters, and textual description to the LLM, which decides at runtime when and how to use it based on the user input and conversation context. Describe how decorating search_travel_info() with @tool makes it available for tool calling, and state what the function takes and returns.

What does section 11.2.3, Registering tools with the LLM, cover?

This section explains how registering the travel search tool lets an LLM request its use, and how LangChain simplifies that registration. Explain what information a direct OpenAI tool registration supplies and what happens when the model requests the tool. Describe how this section registers the travel search tool through LangChain and what LangChain handles automatically.

What does section 11.2.4, Agent state: Tracking the conversation, cover?

This subsection defines the agent’s state as a simple message history for the conversation. Explain that this implementation’s AgentState consists only of the sequence of messages exchanged by the user, the agent, and tools, so it tracks the entire conversation without additional state fields.

What does section 11.2.5, Executing tool calls, cover?

This section explains how a tool-execution node runs LLM-requested tools, returns their results to the conversation, and can be replaced by LangGraph’s built-in ToolNode. Trace how a tool-execution node reads the LLM’s latest message, invokes each requested tool with its arguments, and adds the results to the conversation state for the LLM to use. Explain why most applications can use LangGraph’s ToolNode instead of writing a custom ToolsExecutionNode.

What does section 11.2.6, The LLM node: Coordinating reasoning and action, cover?

The section explains how a tool-enabled LLM node uses conversation messages to decide whether to request tools, continue reasoning, or answer. Trace how the LLM node processes the agent state and decides between requesting tool calls and producing a final answer. Describe how each outcome appears in the returned AIMessage.

What does section 11.3, Assembling the agent graph, cover?

This section introduces the single-tool travel agent as a LangGraph directed graph made of LLM and tool-execution nodes connected by edges. Describe how the single-tool travel information agent is represented as a directed graph: its nodes correspond to the LLM and tool-execution logic, while its edges represent possible flows of data and control.

What should I know before reading chapter 11?

Workflows (chapter 5): The earlier description of workflows as state-dependent flows.; Agents (chapter 5): The earlier distinction between workflows and agents.; Splitting and storing the documents (chapter 7): Splitting and storing documents in a vector store.; Splitting strategy (chapter 8): Prior discussion of splitting text for retrieval.; Embedding strategy (chapter 8): Prior discussion of embedding text for retrieval.; When to use agent-based architectures (chapter 5): The distinction between situations suited to agents and those suited to fixed workflows.; State management and typing (chapter 5): The idea that a LangGraph agent has state.

Chapter 11: Building tool-based agents with LangGraph

What you will learn in chapter 11 of AI Agents and Applications

The introduction contrasts deterministic LangGraph workflows with agents that use an LLM to make context-sensitive tool decisions.

After this chapter you will be able to

Workflow and agent distinction. Distinguish a deterministic agentic workflow from an agent that uses an LLM to choose tools and their order as a task evolves.
Single Tool Travel Agent. Describe the planned travel agent’s information source and tool: it uses a vector store retriever to answer questions about Cornwall’s destinations and resorts from chunked Wikivoyage content.
Python environment and dependencies. Describe how to prepare the chapter 11 project: open the ch11 folder in a VS Code terminal, create and activate a virtual environment, then install the dependencies from requirements.txt.
API key loading placement. Describe where to load the API key in main_01_01.py once the .env file is ready.
Cornwall travel content pipeline. Trace how the setup turns Wikivoyage pages for selected Cornwall destinations into information searchable by semantic similarity. Explain why the downloaded text is split into overlapping chunks before embedding.
Reusable vector store retriever. Explain how the singleton initialization avoids rebuilding the vector store and how the resulting retriever gives the agent access to travel information.
Tool-calling capabilities. Distinguish tool calling from earlier function calling and describe what a tool lets an LLM do.
Dynamic tool selection. Justify using an agent with tool calling rather than hardcoded API calls when tool needs cannot be predicted.
ReAct reasoning-action cycle. Trace how the ReAct pattern moves from a user question through reasoning, optional tool actions, and a final answer.
Tool registration and selection. Explain that registering a tool exposes its name, parameters, and textual description to the LLM, which decides at runtime when and how to use it based on the user input and conversation context.
Manual tool registration and invocation. Explain what information a direct OpenAI tool registration supplies and what happens when the model requests the tool.
LangChain tool binding. Describe how this section registers the travel search tool through LangChain and what LangChain handles automatically.
Conversation message state. Explain that this implementation’s AgentState consists only of the sequence of messages exchanged by the user, the agent, and tools, so it tracks the entire conversation without additional state fields.
Tool-call execution flow. Trace how a tool-execution node reads the LLM’s latest message, invokes each requested tool with its arguments, and adds the results to the conversation state for the LLM to use.
LLM node decision cycle. Trace how the LLM node processes the agent state and decides between requesting tool calls and producing a final answer. Describe how each outcome appears in the returned AIMessage.
Agent graph nodes and edges. Describe how the single-tool travel information agent is represented as a directed graph: its nodes correspond to the LLM and tool-execution logic, while its edges represent possible flows of data and control.
LLM and tools node roles. Describe the two nodes in the agent graph and how their roles support the conversation’s ReAct-style flow.
Conditional tool call routing. Explain how the conditional edge chooses the tools node or ends the graph based on the LLM’s latest message.
Chatbot REPL interaction cycle. Trace how the chatbot welcomes the user, accepts a question, packages it as a HumanMessage, invokes the agent graph, and displays the reply from its output. Explain that it repeats until the user types exit or quit.
Tool call routing and execution. Trace how the LLM’s search tool calls move through tools_condition to ToolsExecutionNode.__call__(), which invokes the named tool with each call’s arguments.
Tool results and final answer. Explain how search results return as ToolMessages for another LLM step, and how the absence of further tool calls leads to the final displayed answer.
Need for current travel conditions. Explain why semantic search over curated travel content may not be enough for travel advice: useful answers can depend on changing conditions such as the weather.
Mock weather service behavior. Describe what WeatherForecastService returns for a town and how it generates those values.
Weather forecast tool behavior. Describe how the weather_forecast tool makes mock weather data available to the agent, including its town-name input and its success and error responses.
Multi-tool LLM setup. Explain that extending the travel agent to handle weather checks requires setting up its LLM for tool calling and making it recognize both available tools.
Modular multi-tool orchestration. Explain how registering the weather forecast tool expands the agent’s answers and why adding it does not require changing the agent graph.
Initial multi-tool behavior. Describe how inspecting the LLM’s tool calls reveals that it may request weather for towns it chose without consulting the semantic search tool, and explain why that matters.
Guidance for grounded tool use. Explain how clearer tool descriptions and a guiding SystemMessage change the agent’s tool use. Describe why searching for candidate beach towns first reduces the risk of invented suggestions.
Search and weather tool chain. Trace how the agent uses search results and weather tool calls to answer a beach-town request, including what happens when the first towns do not have suitable weather.
Prebuilt agent tradeoff. Explain why a developer might use a LangGraph prebuilt agent, such as the ReAct agent, after building an agent from scratch.
Prebuilt ReAct agent refactoring. Describe how to replace manual tool binding, custom execution and LLM nodes, and explicit graph wiring with a built-in LangGraph ReAct agent. Explain that the prebuilt agent handles tool calling, flow, and synthesis.
LangSmith agent behavior tracing. Explain why high-level agent abstractions can be harder to inspect and what LangSmith lets developers trace.
Prebuilt Agent Trace Visibility. Explain what the LangSmith graphical trace reveals and why that remains useful with a prebuilt LangGraph agent.

liveBook manning.com

Read chapter 11 on liveBook Get the book at manning.com

What it builds on

Workflows (chapter 5) · The earlier description of workflows as state-dependent flows.
Agents (chapter 5) · The earlier distinction between workflows and agents.
Splitting and storing the documents (chapter 7) · Splitting and storing documents in a vector store.
Splitting strategy (chapter 8) · Prior discussion of splitting text for retrieval.
Embedding strategy (chapter 8) · Prior discussion of embedding text for retrieval.
When to use agent-based architectures (chapter 5) · The distinction between situations suited to agents and those suited to fixed workflows.
State management and typing (chapter 5) · The idea that a LangGraph agent has state.

Section by section

Introduction

The introduction contrasts deterministic LangGraph workflows with agents that use an LLM to make context-sensitive tool decisions.

Workflow and agent distinction: Distinguish a deterministic agentic workflow from an agent that uses an LLM to choose tools and their order as a task evolves.
Why it matters: This distinction explains what makes the chapter’s tool-based system an agent rather than a predetermined workflow.

Key terms: agentic workflows, agents, large language model (LLM), tools, application state

11.1 Starting simple: Building a single-tool travel info agent

Introduces a single-tool Cornwall travel agent and the chunked vector-store content that will support its answers.

Single Tool Travel Agent: Describe the planned travel agent’s information source and tool: it uses a vector store retriever to answer questions about Cornwall’s destinations and resorts from chunked Wikivoyage content.
Why it matters: This establishes what information the agent can draw on without requiring you to explain its tool-calling mechanics yet.

Key terms: vector store retriever, Wikivoyage, chunks, vector store

11.1.1 Project setup

Sets up the chapter 11 Python project, its API key and debugger configuration, and a naming convention for successive agent scripts.

Python environment and dependencies: Describe how to prepare the chapter 11 project: open the ch11 folder in a VS Code terminal, create and activate a virtual environment, then install the dependencies from requirements.txt.
Why it matters: This prepares the Python environment needed to work through the agent examples.
API key and debugger files: State where the section puts the OpenAI API key and the VS Code debugging configuration.
Why it matters: These files provide the key and debugging setup used while developing the project.
Versioned script naming convention: Explain what x and y represent in main_x_y.py and why the section uses that naming convention.
Why it matters: The names make it easier to follow and compare successive agent implementations.

Key terms: ch11 project folder, virtual environment, requirements.txt, .env, OpenAI API key, launch.json, .vscode, main_x_y.py, feature, version

11.1.2 Loading environment variables

This subsection tells readers where to load the API key in the travel agent script after preparing the .env file.

API key loading placement: Describe where to load the API key in main_01_01.py once the .env file is ready.
Why it matters: This places API key loading early in the agent script without requiring readers to recall code not shown here.

Key terms: .env file, API key, main_01_01.py, import statements

11.1.3 Preparing the travel information vector store

This section prepares a searchable Wikivoyage knowledge base for the Cornwall travel agent and makes it reusable through a retriever.

Cornwall travel content pipeline: Trace how the setup turns Wikivoyage pages for selected Cornwall destinations into information searchable by semantic similarity. Explain why the downloaded text is split into overlapping chunks before embedding.
Why it matters: This pipeline gives the agent a way to find relevant destination information rather than relying only on what the model already contains.
Reusable vector store retriever: Explain how the singleton initialization avoids rebuilding the vector store and how the resulting retriever gives the agent access to travel information.
Why it matters: Reusing the store avoids needless setup work while giving the agent a consistent way to retrieve destination information.

Key terms: build_vectorstore(), Wikivoyage, overlapping chunks, OpenAI’s embedding models, Chroma vector store, semantic similarity, singleton pattern, get_travel_info_vectorstore(), vector store client, retriever

11.2 Enabling agents to call tools

Introduces tool calling as the next step for making the prepared vector store retriever available to the agent.

11.2.1 From function calling to tool calling

This section explains what tool calling adds to LLMs, why agents use it for flexible decisions, and how ReAct alternates reasoning with tool use.

Tool-calling capabilities: Distinguish tool calling from earlier function calling and describe what a tool lets an LLM do.
Why it matters: It clarifies how an LLM can use capabilities such as code execution or API lookups rather than only generate text.
Dynamic tool selection: Justify using an agent with tool calling rather than hardcoded API calls when tool needs cannot be predicted.
Why it matters: It identifies when an agent offers flexibility that a fixed workflow cannot.
ReAct reasoning-action cycle: Trace how the ReAct pattern moves from a user question through reasoning, optional tool actions, and a final answer.
Why it matters: The cycle shows how an agent can use new tool results to decide whether to act again or answer.

Key terms: function calling, tool calling, tool, structured inputs, structured outputs, agents, fixed agentic workflows, tool parameters, ReAct, Reasoning

11.2.2 How tool calling works with LLMs

Explains what an LLM receives when a tool is registered and illustrates tool registration with a decorated travel-search function.

Tool registration and selection: Explain that registering a tool exposes its name, parameters, and textual description to the LLM, which decides at runtime when and how to use it based on the user input and conversation context.
Why it matters: Tool registration gives the model the information it needs to choose a tool for a request.
Decorated travel search tool: Describe how decorating search_travel_info() with @tool makes it available for tool calling, and state what the function takes and returns.
Why it matters: The travel-search example shows how an ordinary function is exposed as a callable tool.

Key terms: tool calling, function signature, textual description, @tool, search_travel_info(), parameter schema, vector store, Wikivoyage

11.2.3 Registering tools with the LLM

This section explains how registering the travel search tool lets an LLM request its use, and how LangChain simplifies that registration.

Manual tool registration and invocation: Explain what information a direct OpenAI tool registration supplies and what happens when the model requests the tool.
Why it matters: It separates the model’s decision to request a tool from the application’s responsibility to run it.
LangChain tool binding: Describe how this section registers the travel search tool through LangChain and what LangChain handles automatically.
Why it matters: It shows what LangChain removes from the manual registration work while still making the tool available to the model.

Key terms: tool registration, parameter schema, structured tool call, tools argument, decorated Python function, .bind_tools(TOOLS), function signature, docstring, JSON schema

11.2.4 Agent state: Tracking the conversation

This subsection defines the agent’s state as a simple message history for the conversation.

Conversation message state: Explain that this implementation’s AgentState consists only of the sequence of messages exchanged by the user, the agent, and tools, so it tracks the entire conversation without additional state fields.
Why it matters: This identifies what the agent retains as its conversation state in this implementation.

Key terms: AgentState, LLM messages, tool responses

11.2.5 Executing tool calls

This section explains how a tool-execution node runs LLM-requested tools, returns their results to the conversation, and can be replaced by LangGraph’s built-in ToolNode.

Tool-call execution flow: Trace how a tool-execution node reads the LLM’s latest message, invokes each requested tool with its arguments, and adds the results to the conversation state for the LLM to use.
Why it matters: Tool results become information the LLM can use in its next response.
Built-in ToolNode alternative: Explain why most applications can use LangGraph’s ToolNode instead of writing a custom ToolsExecutionNode.
Why it matters: Using ToolNode can simplify agent development when custom execution logic is unnecessary.

Key terms: tool calls, ToolsExecutionNode, conversation state, ToolNode

11.2.6 The LLM node: Coordinating reasoning and action

The section explains how a tool-enabled LLM node uses conversation messages to decide whether to request tools, continue reasoning, or answer.

LLM node decision cycle: Trace how the LLM node processes the agent state and decides between requesting tool calls and producing a final answer. Describe how each outcome appears in the returned AIMessage.
Why it matters: This decision point lets the agent use information from tools before answering when needed.

Key terms: LLM node, agent state, llm_with_tools, AIMessage, content, tool_calls

11.3 Assembling the agent graph

This section introduces the single-tool travel agent as a LangGraph directed graph made of LLM and tool-execution nodes connected by edges.

Agent graph nodes and edges: Describe how the single-tool travel information agent is represented as a directed graph: its nodes correspond to the LLM and tool-execution logic, while its edges represent possible flows of data and control.
Why it matters: This picture of the graph makes the agent’s components and their connections easier to follow.

Key terms: LangGraph, directed graph, node, edges, LLM node, tool execution node

11.4 Understanding the agent graph structure

Explains how the travel agent graph moves between its LLM and tools nodes, decides when to end, and starts and finalizes execution.

LLM and tools node roles: Describe the two nodes in the agent graph and how their roles support the conversation’s ReAct-style flow.
Why it matters: The separate node roles explain how the agent can act on an LLM request rather than only generate text.
Conditional tool call routing: Explain how the conditional edge chooses the tools node or ends the graph based on the LLM’s latest message.
Why it matters: This routing decision is what lets the agent use a tool when requested and otherwise finish with an answer.
Graph entry and compilation: Describe where each user question enters the graph and what compiling the graph accomplishes.
Why it matters: The entry point and compilation explain how the defined graph becomes an agent ready to handle a question.

Key terms: LLM node, tools node, ReAct pattern, conditional edge, tools_condition, tool_calls, END, entry point, llm_node, builder.compile()

11.5 Running the agent chatbot: The Read-Eval-Print Loop

This section shows how a simple Read-Eval-Print Loop connects a user to the travel information agent graph.

Chatbot REPL interaction cycle: Trace how the chatbot welcomes the user, accepts a question, packages it as a HumanMessage, invokes the agent graph, and displays the reply from its output. Explain that it repeats until the user types exit or quit.
Why it matters: This loop lets someone interact with the agent you built through repeated questions and answers.

Key terms: Read-Eval-Print Loop (REPL), HumanMessage, agent graph, exit, quit

11.6 Executing a request

Introduces a hands-on walkthrough of running and debugging the travel information agent to observe its LangGraph flow between the LLM and a tool.

11.6.1 Step-by-step debugging

Walks through debugging a travel agent request to show how LLM tool calls are routed, executed, returned as messages, and turned into a final answer.

Breakpoints and message inspection: Describe how to trace one request by placing breakpoints in llm_node(), ToolsExecutionNode.__call__(), and search_travel_info(), then inspecting state["messages"] and response_message as execution advances.
Why it matters: These inspection points make the agent’s otherwise hidden steps visible.
Tool call routing and execution: Trace how the LLM’s search tool calls move through tools_condition to ToolsExecutionNode.__call__(), which invokes the named tool with each call’s arguments.
Why it matters: It explains why an LLM message requesting information leads to tool execution instead of being shown as the answer.
Tool results and final answer: Explain how search results return as ToolMessages for another LLM step, and how the absence of further tool calls leads to the final displayed answer.
Why it matters: It connects the tool’s retrieved facts to both the final answer and the graph’s stopping decision.

Key terms: breakpoints, state["messages"], response_message, tool calls, tools_condition, ToolsExecutionNode.__call__(), semantic search tool, ToolMessage, tool_calls, AIMessage

11.7 Expanding your agent: Adding a weather forecast tool

The section explains why a travel agent that searches curated content may also need current weather information.

Need for current travel conditions: Explain why semantic search over curated travel content may not be enough for travel advice: useful answers can depend on changing conditions such as the weather.
Why it matters: This explains the motivation for adding a weather tool without assuming how that tool works.

Key terms: semantic search, curated travel content, dynamic, real-time information

11.7.1 Implementing a mock weather service

This section introduces a mock weather service that supplies simulated conditions and temperatures while the travel agent is being expanded.

Mock weather service behavior: Describe what WeatherForecastService returns for a town and how it generates those values.
Why it matters: The agent can be developed with weather information before a real weather API is connected.

Key terms: mock weather service, WeatherForecastService, weather condition, temperature

11.7.2 Creating the weather forecast tool

This section introduces a weather forecast tool that wraps a mock service so an agent can use simulated weather data.

Weather forecast tool behavior: Describe how the weather_forecast tool makes mock weather data available to the agent, including its town-name input and its success and error responses.
Why it matters: The agent needs the tool to incorporate simulated weather information into its responses.

Key terms: weather_forecast tool, mock weather forecast, town name

11.7.3 Updating the agent for multi-tool support

This subsection completes the multi-tool setup by making the LLM aware of both the travel and weather tools.

Multi-tool LLM setup: Explain that extending the travel agent to handle weather checks requires setting up its LLM for tool calling and making it recognize both available tools.
Why it matters: Adding a weather tool is not enough unless the LLM is set up to recognize it alongside the travel tool.

Key terms: tool calling, both available tools, travel queries, weather checks

11.8 Executing the multi-tool agent

This section explains that registering a weather tool lets the agent combine travel and weather information without changing its graph.

Modular multi-tool orchestration: Explain how registering the weather forecast tool expands the agent’s answers and why adding it does not require changing the agent graph.
Why it matters: This explains why the agent can gain another capability without a graph redesign.

Key terms: weather forecast tool, graph structure, LLM, tool-calling protocol

11.8.1 Running the multi-tool agent (initial behavior)

This section uses a debugging run to show that the multi-tool agent may request weather for towns chosen from the LLM’s pretrained knowledge without first using semantic search.

Initial multi-tool behavior: Describe how inspecting the LLM’s tool calls reveals that it may request weather for towns it chose without consulting the semantic search tool, and explain why that matters.
Why it matters: Having multiple tools available does not guarantee the agent will use the tool needed for an accurate answer.

Key terms: response_message.tool_calls, semantic search tool, pretraining

11.8.2 Improving LLM tool usage with system guidance

Clearer tool descriptions and a guiding system message steer a travel agent to search its knowledge base before checking weather and producing a grounded answer.

Guidance for grounded tool use: Explain how clearer tool descriptions and a guiding SystemMessage change the agent’s tool use. Describe why searching for candidate beach towns first reduces the risk of invented suggestions.
Why it matters: The agent’s recommendations are more trustworthy when candidate towns come from the knowledge base rather than the model’s unsupported guesses.
Search and weather tool chain: Trace how the agent uses search results and weather tool calls to answer a beach-town request, including what happens when the first towns do not have suitable weather.
Why it matters: The sequence shows how the agent combines retrieved town information with weather results instead of treating either tool’s output as the final answer.

Key terms: tool descriptions, SystemMessage, semantic search tool, hallucinations, knowledge base, ToolMessage, vector store, weather forecast, synthesized, fact-based answer

11.9 Using prebuilt components for rapid development

Introduces LangGraph’s prebuilt agents as a way to reduce orchestration boilerplate without giving up transparency and observability.

Prebuilt agent tradeoff: Explain why a developer might use a LangGraph prebuilt agent, such as the ReAct agent, after building an agent from scratch.
Why it matters: It explains why the chapter moves from a hand-built agent to a prebuilt one.

Key terms: prebuilt agent components, ReAct agent, orchestration logic, boilerplate, transparency, observability

11.9.1 Refactoring to use the LangGraph ReAct agent

Refactors a custom tool-based agent into a prebuilt LangGraph ReAct agent that handles tool use and orchestration.

Prebuilt ReAct agent refactoring: Describe how to replace manual tool binding, custom execution and LLM nodes, and explicit graph wiring with a built-in LangGraph ReAct agent. Explain that the prebuilt agent handles tool calling, flow, and synthesis.
Why it matters: It lets you use a tested tool-use pattern without maintaining the agent’s orchestration code.
Remaining tool-call steps: Describe the AgentState change made during the refactoring and what it controls.
Why it matters: The state field gives the prebuilt agent a way to keep tool-calling rounds controlled.

Key terms: LangGraph ReAct agent, ToolsExecutionNode, llm_node, tool binding, graph wiring, AgentState, remaining_steps, tool-calling rounds

11.9.2 Running the prebuilt agent

11.9.3 Observing and debugging with LangSmith

This section explains how LangSmith restores visibility into an agent built with high-level abstractions.

LangSmith agent behavior tracing: Explain why high-level agent abstractions can be harder to inspect and what LangSmith lets developers trace.
Why it matters: Tracing helps you inspect what an agent did even when its high-level implementation hides the flow.

Key terms: LangSmith, tracing, tool calls, LLM reasoning, intermediate states

11.9.4 Enabling LangSmith tracing

This subsection shows how to access a LangSmith trace and explains why tracing makes even a prebuilt agent’s behavior inspectable.

LangSmith Trace Access: Describe how to enable tracing through the .env file, rerun the application with a question, and open the resulting trace in LangSmith.
Why it matters: These steps let you inspect what happened when the agent answered a question.
Prebuilt Agent Trace Visibility: Explain what the LangSmith graphical trace reveals and why that remains useful with a prebuilt LangGraph agent.
Why it matters: Prebuilt components save development effort without making the agent’s actions opaque.

Key terms: .env file, LangSmith, Tracing Projects, trace, LangSmith graphical trace, tool call, LLM step, flow of messages, observability

11.10 Summary

This summary contrasts LangGraph agent approaches and recaps how tool design, testing, and tracing support reliable tool-calling agents.

Where this is used later

(chapter intro) (chapter 12) · The single travel-information agent that this chapter expands.
Summary (chapter 12) · How LLMs use tool calling.
Introduction to MCP servers (chapter 13) · Agents calling tools to use external capabilities.
The solution: The Model Context Protocol (chapter 13) · Earlier tool-calling concepts.
Hotel booking tool (chapter 12) · Agents executing tool calls.
Building the multi-agent graph (chapter 12) · An agent’s coordination of reasoning and tool-based action.
Implementing the MCP server (chapter 13) · The earlier weather tool that this server replaces.
Preparing the travel agent for live weather data (chapter 13) · The travel agent’s existing weather forecast tool.

Concepts explained in this chapter

tool usageA tool call is a structured model response that requests invocation of a named tool with supplied arguments.
ReActA ReAct agent is an agent architecture that interleaves reasoning with actions such as invoking tools and observing their results.
similarity searchRetrieval is the process of finding relevant stored documents from an indexed collection in response to a query.
LangGraphLangGraph is a LangChain module for representing application workflows as graphs with branching and more complex control flow.
debuggingDebugging is the systematic diagnosis and correction of faults in software execution or behavior.
conditional edgeA conditional edge is a workflow transition whose destination is selected at runtime according to state or other conditions.
toolA tool is an instrument or software capability that enables a person or system to perform a task, obtain information, or interact with resources.
nodeA node is a LangGraph workflow component that performs processing by reading the current state and returning state updates.
AI agentAn AI agent is a software system that works with a large language model to perform multi-step tasks by selecting actions, invoking tools, and adapting to intermediate results.
promptA system prompt is an instruction message supplied to a language model to establish high-level behavior or constraints.
hallucinationA hallucination is an incorrect, misleading, or fabricated response generated by a language model.
text chunkA text splitter is a component that divides large text into smaller chunks or document objects.
trajectoryExecution history is the recorded sequence of workflow decisions, transitions, and intermediate states produced during graph execution.
LangSmithLangSmith is a development and observability platform for tracing, debugging, evaluating, monitoring, and refining language-model applications.
vector databaseA vector store is a database specialized for storing embeddings and associated documents and retrieving them by semantic similarity.
edgeAn edge is a LangGraph graph connection that determines how execution moves between nodes, optionally according to a condition.
specialized agentA specialized agent is an agent configured with a distinct role and tool set for a particular type of task.

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.