What will I learn in chapter 6 of Building Reliable AI Systems?

The chapter introduction contrasts a standalone LLM’s ability to respond with an agent’s ability to interact with real-world systems, and notes a production risk that reliable agents must control. After reading it you should be able to: Explain why a standalone LLM cannot complete the flight-booking request and how an AI agent extends it beyond a general answer. Explain why a standalone LLM cannot reliably provide current information, and how retrieval or external data connections can mitigate that limitation. Explain why an LLM can understand and describe a task yet cannot execute it without access to external systems, using the meeting-scheduling example. Explain why a standalone LLM cannot complete the travel-planning request: it may describe the process, but it cannot coordinate and execute its subtasks in sequence. Explain how an agent differs from a standalone LLM: it adds a control system and tools that let it turn a request into coordinated action rather than only provide an answer. Describe how an agent uses external tools to obtain current information, as in retrieving stock prices from an API instead of relying on static text generation. Explain how agents can carry out requested tasks through external systems rather than merely suggest what a user should do, using the calendar example. Trace how an agent breaks a complex request into ordered subtasks, using the flight example from searching and filtering through presenting options, asking whether to book, and booking if the user agrees.

What does section 6.1.1, Static knowledge, cover?

Explains why a standalone LLM cannot reliably answer questions requiring current information and how external data access can address that limitation. Explain why a standalone LLM cannot reliably provide current information, and how retrieval or external data connections can mitigate that limitation.

What does section 6.1.2, Inability to act, cover?

This section explains why an LLM that understands a request may still be unable to carry out the requested action. Explain why an LLM can understand and describe a task yet cannot execute it without access to external systems, using the meeting-scheduling example.

What does section 6.1.3, No workflow management, cover?

The section explains why a standalone LLM cannot carry out a multistep task even when it can describe what needs to be done. Explain why a standalone LLM cannot complete the travel-planning request: it may describe the process, but it cannot coordinate and execute its subtasks in sequence.

What does section 6.1.4, How AI agents solve these challenges, cover?

This section explains how agents extend LLMs with external connections, the ability to act, and coordination of multistep tasks. Explain how an agent differs from a standalone LLM: it adds a control system and tools that let it turn a request into coordinated action rather than only provide an answer. Describe how an agent uses external tools to obtain current information, as in retrieving stock prices from an API instead of relying on static text generation. Explain how agents can carry out requested tasks through external systems rather than merely suggest what a user should do, using the calendar example.

What does section 6.1.5, Broader applications of AI agents, cover?

This section illustrates how agents act across several industries, contrasts them with standalone LLMs, and reports recent progress on real-world computer tasks. Explain why the section presents AI agents as more actionable than standalone LLMs: agents integrate tools, perform actions, and manage workflows rather than only understanding and generating text. Describe how the section illustrates agent applications in health care, finance, and e-commerce, giving a concrete task an agent could carry out in each. State the reported change in agents’ success on real-world computer tasks and the section’s conclusion about their movement toward production use.

What does section 6.2, Core components of reliable agents, cover?

Introduces reliable agents as systems built from memory, tool integration, and decision-making frameworks. Explain that a reliable agent is more than an LLM: it combines memory to retain context, tool integration to connect with external systems, and decision-making frameworks to orchestrate actions and workflows.

What does section 6.2.1, Memory: Context that sticks, cover?

This section explains how agent memory preserves conversational context, distinguishes short-term from persistent memory, and describes how to retain useful information without overloading the agent or compromising privacy. Explain why an agent needs memory to connect follow-up requests to earlier interactions and spare users from repeating context. Describe what short-term memory retains, how long it lasts, and how an agent uses it during a session. Describe how persistent memory saves and retrieves user information across sessions to support future interactions.

What does section 6.2.2, Balancing memory systems with LangChain, cover?

The section compares ways to retain conversational context, then explains how external tools ground agent responses and why standardized tool interfaces help. Describe how a plain message list retains conversation history in LangChain and why it suits short conversations or cases requiring perfect recall. Explain how summary memory updates compressed conversation context and what it trades for a smaller history. Distinguish when to retain a full buffer and when to summarize, including the role of conversation length, exact recall, and cost.

What does section 6.2.3, Active tool use vs. passive retrieval, cover?

This section distinguishes an agent’s ability to act through tools from passive retrieval and shows how consulting external APIs can ground answers that an LLM would otherwise guess. Distinguish retrieving information from executing a tool that changes an external system. Explain why the ability to take action, such as booking a flight after finding options, goes beyond RAG alone. Explain why an LLM’s confident answer about current weather can be a hallucination and how querying a weather API grounds the agent’s answer in real-time data. Explain the section’s claim that deciding when to consult an API based on confidence can improve reliability without making unnecessary external queries.

What does section 6.2.4, Strategies for reducing hallucinations with tools, cover?

This section presents three ways to reduce agent hallucinations when using tools: ground answers in tool data, handle tool failures without fabricating, and validate tool outputs. Explain that agents can use APIs and databases to ground responses in retrieved information rather than inventing answers, as illustrated by live weather data. Explain why agents need fallback logic when tools fail and what that logic should prevent. Explain why an agent should check tool output before returning it to a user.

What does section 6.2.5, Decision-making: Making AI agents intelligent, cover?

This section explains how agents choose and sequence actions, contrasts rule-based and AI-driven decisions, and introduces ReAct and tree-of-thought reasoning. Explain why an agent needs decision-making in addition to memory and tools, using the travel request to show how it chooses tools and orders tasks. Distinguish predefined rules from AI-driven reasoning in how they select actions, and describe the flexibility and reliability trade-off presented here. Trace ReAct’s repeated reason, act, and observe steps, explaining how an action’s result informs the agent’s next step and eventual answer.

What should I know before reading chapter 6?

What is RAG? (chapter 3): Introduces RAG as a way to bring retrieved information into an LLM application.

Chapter 6: Creating effective AI agents

What you will learn in chapter 6 of Building Reliable AI Systems

The chapter introduction contrasts a standalone LLM’s ability to respond with an agent’s ability to interact with real-world systems, and notes a production risk that reliable agents must control.

After this chapter you will be able to

Standalone LLM and agent capabilities. Explain why a standalone LLM cannot complete the flight-booking request and how an AI agent extends it beyond a general answer.
Static knowledge and live data. Explain why a standalone LLM cannot reliably provide current information, and how retrieval or external data connections can mitigate that limitation.
LLM inability to act. Explain why an LLM can understand and describe a task yet cannot execute it without access to external systems, using the meeting-scheduling example.
Standalone LLM workflow limitation. Explain why a standalone LLM cannot complete the travel-planning request: it may describe the process, but it cannot coordinate and execute its subtasks in sequence.
Agents versus standalone LLMs. Explain how an agent differs from a standalone LLM: it adds a control system and tools that let it turn a request into coordinated action rather than only provide an answer.
External tools for live information. Describe how an agent uses external tools to obtain current information, as in retrieving stock prices from an API instead of relying on static text generation.
Actions through external systems. Explain how agents can carry out requested tasks through external systems rather than merely suggest what a user should do, using the calendar example.
Coordinated multistep workflows. Trace how an agent breaks a complex request into ordered subtasks, using the flight example from searching and filtering through presenting options, asking whether to book, and booking if the user agrees.
Agents Beyond Text Generation. Explain why the section presents AI agents as more actionable than standalone LLMs: agents integrate tools, perform actions, and manage workflows rather than only understanding and generating text.
Three agent foundations. Explain that a reliable agent is more than an LLM: it combines memory to retain context, tool integration to connect with external systems, and decision-making frameworks to orchestrate actions and workflows.
Memory and conversational continuity. Explain why an agent needs memory to connect follow-up requests to earlier interactions and spare users from repeating context.
Short-term session memory. Describe what short-term memory retains, how long it lasts, and how an agent uses it during a session.
Persistent cross-session memory. Describe how persistent memory saves and retrieves user information across sessions to support future interactions.
Full Conversation Buffer. Describe how a plain message list retains conversation history in LangChain and why it suits short conversations or cases requiring perfect recall.
Running Conversation Summary. Explain how summary memory updates compressed conversation context and what it trades for a smaller history.
Memory Strategy Tradeoffs. Distinguish when to retain a full buffer and when to summarize, including the role of conversation length, exact recall, and cost.
Tool Grounding for Agents. Explain why connecting agents to trusted external systems can make their answers more reliable, and identify the kinds of information or actions those systems provide.
Retrieval Versus Action Tools. Distinguish retrieving information from executing a tool that changes an external system. Explain why the ability to take action, such as booking a flight after finding options, goes beyond RAG alone.
API Grounding for Current Answers. Explain why an LLM’s confident answer about current weather can be a hallucination and how querying a weather API grounds the agent’s answer in real-time data.
Tool Grounded Responses. Explain that agents can use APIs and databases to ground responses in retrieved information rather than inventing answers, as illustrated by live weather data.
Graceful Tool Failure Handling. Explain why agents need fallback logic when tools fail and what that logic should prevent.
Tool Output Validation. Explain why an agent should check tool output before returning it to a user.
Decision-making in agent workflows. Explain why an agent needs decision-making in addition to memory and tools, using the travel request to show how it chooses tools and orders tasks.
Rule-based and AI-driven decisions. Distinguish predefined rules from AI-driven reasoning in how they select actions, and describe the flexibility and reliability trade-off presented here.
ReAct reasoning and action cycle. Trace ReAct’s repeated reason, act, and observe steps, explaining how an action’s result informs the agent’s next step and eventual answer.
Stored Knowledge and Real-World Action. Explain why traditional RAG cannot handle some trip-planning requests and how Agentic RAG addresses that limitation by combining retrieval with the ability to take actions.
Transparent interface and user trust. Explain why the project examples use a TypeScript ReAct-based chat interface: it shows the agent’s reasoning steps in the browser, including which tools it selected and why, to help build user trust.
Travel assistant knowledge base. Explain why the travel assistant needs a foundation of information and state that a vector store enables semantic search across that knowledge base.
Tools for information gathering. Explain that the agentic system relies on its ability to use different tools to gather information.
Combining retrieval and live action. Trace how the agent handles a query needing both Eiffel Tower facts and current weather, and explain what this illustrates about Agentic RAG.
Focused tools and descriptions. Explain why production agents need tools that each do one thing reliably and descriptions that clearly state when and how to use them.
Graceful external failure handling. Explain why an agentic RAG system must handle failures of external services, APIs, and network connections and give useful feedback when they occur.
ReAct Grounding and Remaining Risk. Explain that ReAct combines reasoning and action to ground agents in real-world tools and data, reducing hallucinations, but that this alone does not eliminate the need for production safeguards.
Cross-referencing independent results. Explain how an agent can compare outputs from independent tools or sources, flag inconsistencies, and seek clarification or human review when results disagree.
Agent response boundaries. Explain why agents need guardrails and how content filtering keeps their responses safe and on topic.
Feedback-driven agent improvement. Explain how feedback can help an agent improve over time: explicit feedback from users or evaluators on its outputs can be used to refine its reasoning and decision-making.
Visible agent steps and sources. Explain how displaying an agent’s intermediate decisions and sources can improve user trust and reliability. Describe how this visibility lets users check the agent’s choices and notice when it needs correction.
Clinical documentation and physician time. Explain how Mass General Brigham used an AI documentation agent to reduce physicians’ administrative burden and improve time with patients.
Banking agents across employee workflows. Describe how JPMorgan Chase uses different AI tools across adviser, call-center, and developer work, and what benefits the section reports.

liveBook manning.com

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

What it builds on

What is RAG? (chapter 3) · Introduces RAG as a way to bring retrieved information into an LLM application.

Section by section

Introduction

Standalone LLM and agent capabilities: Explain why a standalone LLM cannot complete the flight-booking request and how an AI agent extends it beyond a general answer.
Why it matters: This distinction explains why a useful answer is not the same as completing a user’s task.
Controls for agent loops: Explain why well-designed agents include decision-flow controls and monitoring, using the repeated-tool-call example.
Why it matters: Giving an agent tools also creates a need to detect and prevent unproductive behavior.

Key terms: standalone LLMs, AI agents, external tools, APIs, workflows, context, decision-flow controls, monitoring features, infinite loops

6.1 Why do we need agents?

This section introduces why agents matter by noting that standalone LLMs are capable but face real-world challenges, without yet explaining those challenges.

6.1.1 Static knowledge

Explains why a standalone LLM cannot reliably answer questions requiring current information and how external data access can address that limitation.

Static knowledge and live data: Explain why a standalone LLM cannot reliably provide current information, and how retrieval or external data connections can mitigate that limitation.
Why it matters: It helps you recognize when a question needs a current source rather than an answer drawn only from model training.

Key terms: static knowledge base, tool integration, retrieval-augmented generation (RAG), API integration

6.1.2 Inability to act

This section explains why an LLM that understands a request may still be unable to carry out the requested action.

LLM inability to act: Explain why an LLM can understand and describe a task yet cannot execute it without access to external systems, using the meeting-scheduling example.
Why it matters: Understanding a request is different from having the ability to complete it.

Key terms: glass wall, external systems, external tools

6.1.3 No workflow management

The section explains why a standalone LLM cannot carry out a multistep task even when it can describe what needs to be done.

Standalone LLM workflow limitation: Explain why a standalone LLM cannot complete the travel-planning request: it may describe the process, but it cannot coordinate and execute its subtasks in sequence.
Why it matters: A useful description of a process is not the same as completing it for the user.

Key terms: standalone LLMs, complex workflows, subtasks

6.1.4 How AI agents solve these challenges

This section explains how agents extend LLMs with external connections, the ability to act, and coordination of multistep tasks.

Agents versus standalone LLMs: Explain how an agent differs from a standalone LLM: it adds a control system and tools that let it turn a request into coordinated action rather than only provide an answer.
Why it matters: This distinction explains why an agent can help complete a task instead of merely describing how to do it.
External tools for live information: Describe how an agent uses external tools to obtain current information, as in retrieving stock prices from an API instead of relying on static text generation.
Why it matters: A live source can supply information that a model's static knowledge cannot.
Actions through external systems: Explain how agents can carry out requested tasks through external systems rather than merely suggest what a user should do, using the calendar example.
Why it matters: Completing an action is a different kind of assistance from explaining how someone else could complete it.
Coordinated multistep workflows: Trace how an agent breaks a complex request into ordered subtasks, using the flight example from searching and filtering through presenting options, asking whether to book, and booking if the user agrees.
Why it matters: Ordered steps let an agent handle requests that cannot be completed with a single answer or action.

Key terms: AI agent, standalone LLM, control system, external tools, APIs, databases, live data, performing actions, external systems, workflow orchestration

6.1.5 Broader applications of AI agents

This section illustrates how agents act across several industries, contrasts them with standalone LLMs, and reports recent progress on real-world computer tasks.

Agents Beyond Text Generation: Explain why the section presents AI agents as more actionable than standalone LLMs: agents integrate tools, perform actions, and manage workflows rather than only understanding and generating text.
Why it matters: This distinction explains why an application might need an agent rather than a text-generating model alone.
Agents Across Three Industries: Describe how the section illustrates agent applications in health care, finance, and e-commerce, giving a concrete task an agent could carry out in each.
Why it matters: The examples make the agent’s ability to act concrete in different settings.
Reported Growth in Agent Capability: State the reported change in agents’ success on real-world computer tasks and the section’s conclusion about their movement toward production use.
Why it matters: The reported result gives context for why agent capabilities are receiving attention now.

Key terms: Standalone LLMs, AI agents, tools, actions, workflows, health care, patient overview, market trends, portfolio risks, e-commerce

6.2 Core components of reliable agents

Introduces reliable agents as systems built from memory, tool integration, and decision-making frameworks.

Three agent foundations: Explain that a reliable agent is more than an LLM: it combines memory to retain context, tool integration to connect with external systems, and decision-making frameworks to orchestrate actions and workflows.
Why it matters: These three roles provide a way to understand what an agent needs beyond a model alone.

Key terms: memory, tool integration, decision-making frameworks

6.2.1 Memory: Context that sticks

This section explains how agent memory preserves conversational context, distinguishes short-term from persistent memory, and describes how to retain useful information without overloading the agent or compromising privacy.

Memory and conversational continuity: Explain why an agent needs memory to connect follow-up requests to earlier interactions and spare users from repeating context.
Why it matters: Remembering context makes multistep interactions usable rather than forcing the user to start over.
Short-term session memory: Describe what short-term memory retains, how long it lasts, and how an agent uses it during a session.
Why it matters: Session memory lets an agent use details already supplied without repeatedly asking for them.
Persistent cross-session memory: Describe how persistent memory saves and retrieves user information across sessions to support future interactions.
Why it matters: Cross-session memory allows an ongoing assistant to use a preference the user gave previously.
Selective retention and privacy: Explain how to choose session information for long-term storage while managing context limits, scale, and user privacy.
Why it matters: Selective, privacy-conscious retention makes memory useful without treating every user detail as something to keep forever.

Key terms: memory, context, multistep workflows, short-term memory, conversation history, session, buffer, dictionary, persistent memory, preferences

6.2.2 Balancing memory systems with LangChain

The section compares ways to retain conversational context, then explains how external tools ground agent responses and why standardized tool interfaces help.

Full Conversation Buffer: Describe how a plain message list retains conversation history in LangChain and why it suits short conversations or cases requiring perfect recall.
Why it matters: A full buffer preserves details, but its growing size limits how long it remains practical.
Running Conversation Summary: Explain how summary memory updates compressed conversation context and what it trades for a smaller history.
Why it matters: Summarization can keep long conversations usable, but maintaining it is not free.
Memory Strategy Tradeoffs: Distinguish when to retain a full buffer and when to summarize, including the role of conversation length, exact recall, and cost.
Why it matters: Choosing memory by actual context limits avoids paying for compression before it is needed.
Tool Grounding for Agents: Explain why connecting agents to trusted external systems can make their answers more reliable, and identify the kinds of information or actions those systems provide.
Why it matters: Tool access helps an agent answer from external information and do things a text-only model cannot.
Standardized Tool Connections: Describe the integration problem caused by differing APIs and the uniform interface MCP provides for agent tools.
Why it matters: A common interface reduces the integration work involved in connecting an agent to many tools.
Production Agent State Management: Distinguish the simple memory patterns shown here from the more robust state management suggested for production agents.
Why it matters: The simple patterns explain conversational memory without being presented as the complete production-state solution.

Key terms: buffer memory, HumanMessage, AIMessage, message lists, summary memory, running summary, context window, token overflow, buffer, perfect recall

6.2.3 Active tool use vs. passive retrieval

This section distinguishes an agent’s ability to act through tools from passive retrieval and shows how consulting external APIs can ground answers that an LLM would otherwise guess.

Retrieval Versus Action Tools: Distinguish retrieving information from executing a tool that changes an external system. Explain why the ability to take action, such as booking a flight after finding options, goes beyond RAG alone.
Why it matters: The distinction separates a system that finds an answer from one that can carry out a task.
API Grounding for Current Answers: Explain why an LLM’s confident answer about current weather can be a hallucination and how querying a weather API grounds the agent’s answer in real-time data.
Why it matters: Checking a source for a changing fact is more reliable than presenting a confident guess.
Selective Consultation of APIs: Explain the section’s claim that deciding when to consult an API based on confidence can improve reliability without making unnecessary external queries.
Why it matters: The section presents tool use as a choice to make when external information is needed, not as a requirement for every answer.

Key terms: tools used for retrieval, tools used for action, passive retrieval, change state, RAG, hallucination, tool integration, weather API, real-time data, grounds its response

6.2.4 Strategies for reducing hallucinations with tools

This section presents three ways to reduce agent hallucinations when using tools: ground answers in tool data, handle tool failures without fabricating, and validate tool outputs.

Tool Grounded Responses: Explain that agents can use APIs and databases to ground responses in retrieved information rather than inventing answers, as illustrated by live weather data.
Why it matters: A tool can give the agent evidence for an answer instead of leaving it to guess.
Graceful Tool Failure Handling: Explain why agents need fallback logic when tools fail and what that logic should prevent.
Why it matters: A failed API call should not turn into a confident but invented answer.
Tool Output Validation: Explain why an agent should check tool output before returning it to a user.
Why it matters: Using a tool does not make its result safe to repeat unchecked.

Key terms: anchor responses to tools, APIs, databases, grounded responses, fallback logic, timeouts, rate limits, network issues, validate tool outputs, accuracy

6.2.5 Decision-making: Making AI agents intelligent

This section explains how agents choose and sequence actions, contrasts rule-based and AI-driven decisions, and introduces ReAct and tree-of-thought reasoning.

Decision-making in agent workflows: Explain why an agent needs decision-making in addition to memory and tools, using the travel request to show how it chooses tools and orders tasks.
Why it matters: A capable agent must decide what to do with its tools, not merely have access to them.
Rule-based and AI-driven decisions: Distinguish predefined rules from AI-driven reasoning in how they select actions, and describe the flexibility and reliability trade-off presented here.
Why it matters: The choice of decision-making approach affects both adaptability and the effort needed to make an agent reliable.
ReAct reasoning and action cycle: Trace ReAct’s repeated reason, act, and observe steps, explaining how an action’s result informs the agent’s next step and eventual answer.
Why it matters: Using results to decide the next action lets an agent adjust a multistep workflow rather than follow a fixed sequence blindly.
Tree-of-thought alternative exploration: Describe how tree-of-thought differs from ReAct in this section and when exploring multiple candidate solutions is useful.
Why it matters: Considering alternatives can help an agent choose among several plausible ways to solve a complex problem.

Key terms: decision-making frameworks, tools, multistep workflows, rule-based systems, AI-driven reasoning, predefined logic, LLMs, ReAct, Reasoning + Acting, Reason

6.3 Agentic RAG for reliable agents

This section contrasts traditional RAG’s reliance on stored information with Agentic RAG’s combination of retrieval and action for real-world tasks.

Stored Knowledge and Real-World Action: Explain why traditional RAG cannot handle some trip-planning requests and how Agentic RAG addresses that limitation by combining retrieval with the ability to take actions.
Why it matters: The distinction explains why retrieving relevant documents alone may not answer a question about what is happening now.

Key terms: traditional RAG, Agentic RAG, stored knowledge, retrieval capabilities, take actions

6.3.1 Project: Building an agentic RAG system with LangChain

The section introduces a travel-assistant project and explains why its examples use a transparent TypeScript interface while also providing equivalent Python code.

Transparent interface and user trust: Explain why the project examples use a TypeScript ReAct-based chat interface: it shows the agent’s reasoning steps in the browser, including which tools it selected and why, to help build user trust.
Why it matters: Showing users why the agent selected a tool can make its behavior easier to trust.
Equivalent Python agent code: State that the companion Python file provides the same agent logic and behavior as the TypeScript examples for readers following along in Python.
Why it matters: Python-only readers can follow the project without changing what the agent does.

Key terms: ReAct-based chat interface, transparent UI, reasoning steps, ch06_agentic_rag.py, Python equivalent, agent logic

6.3.2 Setting up dependencies

6.3.3 Building the knowledge base

This section introduces the travel assistant’s knowledge base and identifies a vector store as a way to search it semantically.

Travel assistant knowledge base: Explain why the travel assistant needs a foundation of information and state that a vector store enables semantic search across that knowledge base.
Why it matters: This establishes what information the assistant will draw on without requiring you to explain how the vector store is built.

Key terms: knowledge base, vector store, semantic search

6.3.4 Creating interactive tools

This section identifies using tools to gather information as central to the agentic system, then previews two tools.

Tools for information gathering: Explain that the agentic system relies on its ability to use different tools to gather information.
Why it matters: This identifies the capability the upcoming tools are meant to provide.

Key terms: agentic system, tools, gather information

6.3.5 Configuring the agent’s behavior

6.3.6 Implementing transparent decision-making

6.3.7 Managing conversation context

The section states why conversation context matters and illustrates how an Agentic RAG system answers a query that needs both stored knowledge and live information.

Conversation context across interactions: Explain why the system needs to maintain context across interactions.
Why it matters: Keeping track of earlier interactions helps a conversation feel continuous.
Combining retrieval and live action: Trace how the agent handles a query needing both Eiffel Tower facts and current weather, and explain what this illustrates about Agentic RAG.
Why it matters: A useful answer may require the agent to choose different sources for different parts of a request.

Key terms: context across interactions, Agentic RAG, retrieval tool, knowledge base, weather tool

6.3.8 Making the system work in production

This section identifies practical requirements for production agentic RAG systems and explains how they connect retrieved knowledge with agent actions.

Focused tools and descriptions: Explain why production agents need tools that each do one thing reliably and descriptions that clearly state when and how to use them.
Why it matters: Clear tool boundaries and descriptions help an agent use its available capabilities appropriately.
Graceful external failure handling: Explain why an agentic RAG system must handle failures of external services, APIs, and network connections and give useful feedback when they occur.
Why it matters: Users need a useful response even when a service the agent depends on is unavailable.
Knowledge and action combination: Describe how agentic RAG combines RAG’s access to knowledge with an agent’s ability to act.
Why it matters: This explains the value of putting retrieval and agent capabilities in the same system.

Key terms: tools, tool descriptions, error handling, external services, APIs, agentic RAG, knowledge access, action capabilities

6.4 Advanced techniques

Introduces why ReAct agents need safeguards beyond tool-grounded reasoning to be reliable in production.

ReAct Grounding and Remaining Risk: Explain that ReAct combines reasoning and action to ground agents in real-world tools and data, reducing hallucinations, but that this alone does not eliminate the need for production safeguards.
Why it matters: Grounding helps an agent give reliable answers, but it does not remove every risk.

Key terms: ReAct framework, grounding, production-grade reliability

6.4.1 Cross-referencing

This section explains how agents can cross-check independent sources before relying on results for important decisions.

Cross-referencing independent results: Explain how an agent can compare outputs from independent tools or sources, flag inconsistencies, and seek clarification or human review when results disagree.
Why it matters: A disagreement between sources can reveal a problem before an agent relies on a result.

Key terms: cross-referencing, independent tools or sources, inconsistencies

6.4.2 Guardrails for security and preventing hallucinations

This section explains how content guardrails keep agent responses within safe, relevant boundaries and why simple keyword filters are insufficient in production.

Agent response boundaries: Explain why agents need guardrails and how content filtering keeps their responses safe and on topic.
Why it matters: Clear boundaries help an agent behave reliably and earn user trust.
Keyword filtering limitations: Distinguish the simple rule-based guardrails in the example from semantic guardrails used in production.
Why it matters: A filter that only looks for listed words can miss unsafe requests phrased differently.

Key terms: guardrails, content filtering, safe operating boundaries, rule-based approach, keyword matching, LLM-as-a-judge guardrails, semantically

6.4.3 Reinforcement Learning from AI Feedback

This section explains that feedback on an agent’s outputs can guide iterative improvements to its reasoning and decisions.

Feedback-driven agent improvement: Explain how feedback can help an agent improve over time: explicit feedback from users or evaluators on its outputs can be used to refine its reasoning and decision-making.
Why it matters: Feedback gives a way to refine an agent’s behavior based on what it actually produces.

Key terms: Reinforcement Learning from AI Feedback (RLAIF), explicit feedback, reasoning and decision-making processes

6.4.4 Transparency in multistep reasoning

The section explains how showing an agent’s intermediate steps and sources helps users understand, verify, and correct its answers.

Visible agent steps and sources: Explain how displaying an agent’s intermediate decisions and sources can improve user trust and reliability. Describe how this visibility lets users check the agent’s choices and notice when it needs correction.
Why it matters: Visible steps and sources give users a way to check an agent’s work rather than simply trust its answer.

Key terms: transparency, intermediate reasoning steps, sources

6.4.5 Case studies for agents in production

This section uses production case studies, adoption figures, and a brief framework comparison to show how organizations put AI agents to work and measure their value.

Clinical documentation and physician time: Explain how Mass General Brigham used an AI documentation agent to reduce physicians’ administrative burden and improve time with patients.
Why it matters: The case connects a production agent’s task to outcomes for both clinicians and patients.
Banking agents across employee workflows: Describe how JPMorgan Chase uses different AI tools across adviser, call-center, and developer work, and what benefits the section reports.
Why it matters: The bank illustrates how production AI can support several kinds of work rather than serve as one general-purpose chatbot.
Document automation with human review: Explain how SS&C Technologies shifted document processing from near-universal human review to agent automation with flagged exceptions.
Why it matters: This case shows that high automation can coexist with targeted human review.
Personalized retail and service handoff: Describe how H&M’s shopping agent combines personalized purchase assistance with routine customer-service support.
Why it matters: The retail case ties personalization and routine-question handling to a deliberate role for human service staff.
Industry adoption and agentic distinction: Distinguish the section’s broad AI adoption examples from its narrower measure of truly agentic implementations.
Why it matters: The adoption figures should not be read as saying every widely used AI application is an autonomous agent.
Framework strengths and selection factors: Explain that the listed agent frameworks have different strengths and that selection depends on the intended workflow and existing infrastructure.
Why it matters: Framework choice is presented as a fit-to-workflow decision, not a universal ranking.

Key terms: ambient documentation technology, clinical notes, documentation burden, LLM Suite, Coach AI, EVEE Q&A agent, AI coding assistants, specialized AI agents, automation rates, edge cases

6.5 Summary

Where this is used later

(chapter intro) (chapter 7) · Introduces the limitation of an AI system that cannot act through external systems.
Why harnesses matter (chapter 7) · Introduces agent components such as memory and tool use.
Privacy layer: Protecting personal data (chapter 11) · Protecting personal data builds on the privacy concern raised by persistent user memory.
Teaching your AI to use MCP tools (chapter 7) · Teaching a model to use tools assumes the value of external data and actions.
The solution: MCP (chapter 7) · The MCP solution elaborates on the common-interface idea introduced here.
Introducing LangGraph: The multi-agent framework (chapter 8) · The later introduction to LangGraph expands on the framework named here.
Evaluating agents: Beyond traditional LLM metrics (chapter 9) · Agents’ active use of tools.
Catching and communicating errors (chapter 7) · Develops how tool errors are caught and communicated.

Concepts explained in this chapter

memoryA memory mechanism stores and retrieves information so an AI system can retain context across task steps or interactions.
working memoryAn agent memory that temporarily retains information, typically for the duration of a single session.
AI agentA software system that interprets information, makes decisions, and takes actions to pursue goals.
tool integrationThe process of connecting tools to an AI system so it can invoke them as part of its operation.
ReActAn agent framework that interleaves reasoning, actions, and observations to guide task execution.
action executionThe capability of carrying out tasks by interacting with external systems rather than merely describing possible solutions.
decision frameworkA structured approach that guides an AI agent in reasoning, selecting tools and actions, and sequencing tasks.
message listAn ordered collection of messages that can retain a conversation's history.
buffer memoryA conversation-memory pattern that retains the complete history of messages rather than compressing it.
summary memoryA conversation-memory pattern that maintains a compressed summary of the conversation instead of its complete message history.
agentic RAGA retrieval-augmented generation approach in which an AI agent controls the retrieval process, including deciding when multiple retrievals are needed.
language modelA model that represents patterns in language to predict or generate sequences of text.
retrieval-augmented generationA retrieval-augmented generation approach that retrieves and synthesizes stored information without taking actions in the real world.
transparencyThe degree to which an AI system's behavior, decisions, and relevant processes can be understood or inspected.
reliable agentAn AI agent that performs tool use and multi-step workflows while taking safe actions.
guardrailA constraint that defines behavior a model should or should not exhibit.
tool usageAn AI capability in which a model invokes external tools to obtain information or perform actions.
checkpointingThe practice of saving execution state so a process can be paused and later resumed.
human-in-the-loopHuman supervision of an AI system's outputs, decisions, and operation.
state managementState management is the handling and maintenance of an application's current state as it executes and responds to interactions.
summarizationThe process of condensing information into a shorter representation that preserves important content.
Tree-of-thoughtA prompting method in which a language model explores and evaluates multiple reasoning paths before selecting a solution.
rule-based systemA system that makes decisions by applying predefined logic or rules to inputs.
dialogueA record of the messages exchanged during a conversation.
agent orchestrationThe coordination and sequencing of multiple task steps to accomplish a larger objective.
hallucinationA hallucination is a model-generated output that presents fabricated or unsupported information as if it were true.
evaluatorAn evaluation technique in which a large language model assesses the quality of another model's output.
lexical searchA retrieval method that searches using sparse representations of content, such as term-based vectors.
feedback loopA process that uses information about a system's outputs to guide its later behavior or improvement.

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.