Chapter 1: The rise of AI agents

Introduction

The introduction distinguishes response-generating LLM apps from AI agents that can decide and act toward goals.

• AI agents versus chatbots: Explain how an AI agent extends an LLM-based app beyond answering questions: it perceives its environment, decides what to do, and acts toward a goal using resources provided by an LLM.
  Why it matters: This distinction explains why an agent can do more than tell you what needs doing.

Key terms: LLM-based apps, AI agents, environment, goal

1.1 Defining agents and agentic thinking

Defines agents and agentic behavior, distinguishes agents from reactive assistants, and places LLM-powered agents in the broader history of AI.

• Practical meaning of agency: Explain that an agent perceives its environment, decides what to do, and acts toward a goal, and that agentic describes behavior that follows this pattern with some autonomy.
  Why it matters: This practical definition gives you a way to recognize agentic behavior across different kinds of systems.
• Assistant and agent distinction: Distinguish a generative assistant's one-prompt response from an agent's persistent, multistep pursuit of a goal, including how observations inform its next choice.
  Why it matters: The contrast helps you judge behavior rather than relying on whether a product is marketed as an assistant or an agent.
• Historical breadth of agents: Describe that agents predate LLMs and can use several AI approaches, while LLMs expand the scope of what a single agent can reason about and accomplish.
  Why it matters: This keeps the book's LLM focus in perspective without treating every agent as an LLM system.

Key terms: agent, agentic, agency, environment, goal, generative assistant, autonomy, persistence, multistep workflows, LLM-powered agents

1.1.1 Understanding agent, assistant, and LLM patterns

This section distinguishes direct LLM interactions, tool-using assistants, and agents by how they use tools, pursue goals, and involve human approval.

• Direct and mediated LLM interactions: Distinguish a direct LLM chat from an interaction in which an LLM uses a tool or reformulates a request for another tool.
  Why it matters: This distinction shows what changes when an LLM does more than answer directly.
• Assistant and agent autonomy: Distinguish the book's assistant and agent patterns by where approval occurs and whether the system can plan and execute multistep work toward a higher-level goal.
  Why it matters: The amount of independent planning and action is the book's main distinction between these patterns.
• Graduated human oversight: Explain why an autonomous agent may still require human approval for particular actions and how the section relates oversight to risk.
  Why it matters: Oversight lets an agent pursue a goal without treating every possible action as safe to perform independently.

Key terms: direct chat, LLM, tools, proxy agent interaction, assistant, agent, autonomy, per-step approval, higher-level goal, agency

1.1.2 Thinking like agents: Sense-plan-act-learn

This section explains how agents turn goals into tool-based tasks through a sense-plan-act-learn cycle, and why built-in model reasoning may still need guidance.

• Agency and tool-based tasks: Explain that agency is an agent’s ability to decide how to complete a goal and use tools to do it. Describe how a goal is broken into tasks that involve tool execution, sometimes passing one tool’s output to the next.
  Why it matters: It connects an agent’s decision-making to the concrete tasks and tools that accomplish a goal.
• Sense-plan-act-learn cycle: Trace the high-level sense-plan-act-learn cycle for a goal, including what each step means for an LLM-powered agent and how the agent decides whether to continue or return results.
  Why it matters: The cycle provides a high-level way to describe how an agent progresses from a goal to a completed result.
• Limits of built-in reasoning: Distinguish the reasoning support needed by earlier LLMs from the built-in reasoning capacity of many current frontier models, and explain why instructions may still need to guide reasoning.
  Why it matters: A reasoning mode alone does not guarantee that an agent will plan reliably for a complex goal.

Key terms: agency, goal, tasks, tools, tool chaining, sense-plan-act-learn, SPAL cycle, sense, plan, act

1.1.3 Agents act with tools

This section explains how agents use registered tool functions to act on external systems, handle tool failures, and avoid repetitive integration work through shared protocols such as MCP.

• Tool functions and registration: Explain how tool functions let an agent interact with external systems and why the agent needs instructions and registration to use them.
  Why it matters: Tool registration is what makes external actions available to an agent rather than merely to its surrounding code.
• Tool failures as control flow: Describe how a well-built agent responds when a tool fails instead of treating the failure as a crash.
  Why it matters: External services are unreliable, so an agent needs a bounded way to respond when a call goes wrong.
• Shared protocols for tool access: Explain the integration burden of codebase-specific tools and how a protocol such as MCP changes where agents obtain tools.
  Why it matters: Shared tool access can shift engineering effort away from repeatedly building integrations and toward agent behavior.

Key terms: tools, tool functions, register a tool, tool failures, normal control flow, retries, fallbacks, runaway loops, Model Context Protocol (MCP), tool wrappers

1.2 Introducing the Model Context Protocol

This section introduces MCP as a standard way for agents to discover and use reusable external tools, and explains the basic connection flow and trust considerations.

• Standardized external tool access: Explain that MCP is an open standard based on JSON-RPC 2.0 that gives tool requests and responses a predictable, language-agnostic structure for connecting AI systems to external services.
  Why it matters: A shared protocol lets agents connect to tools without depending on the server’s programming language.
• Reusable server integrations: Explain how an MCP server makes external tools available without each agent developer building separate tool functions and connections. State that a missing server must still be built, but can then be reused across agents.
  Why it matters: Reusable servers reduce repeated integration work when multiple agents need the same capability.
• Agent server interaction sequence: Describe the basic sequence of running and registering an MCP server, discovering its tools with list_tools, and then having the agent choose and execute a tool in response to a task.
  Why it matters: This sequence shows how an agent finds available capabilities before using one for a task.
• MCP server trust boundary: Explain why connecting an agent to an MCP server requires care: the server exposes endpoints the agent can call autonomously, so developers should treat it as a trusted dependency and limit its privileges.
  Why it matters: Convenient tool access also grants potentially consequential execution access.

Key terms: MCP, JSON-RPC 2.0, open standard, language-agnostic, prebuilt MCP servers, tool functions, shared, reusable layer, MCP server, registering, list_tools

1.3 Understanding the five functional layers of an agent

Introduces five functional layers for describing agent capabilities and explains that the layers are neither universally required nor executed in a fixed order.

• Five functional agent layers: Describe the five functional layers as a way to organize an agent’s capabilities, and distinguish the usually essential core layers from layers an agent may omit.
  Why it matters: The layers give you a way to describe what capabilities an agent has without assuming every agent needs the same design.
• Layer interaction versus diagram order: Explain why the layered diagram is not a runtime sequence, using the section’s examples of how core components interact.
  Why it matters: Treating the picture as a fixed sequence would misrepresent how the agent’s components work together.

Key terms: functional layers, persona, tools and actions, reasoning and planning, knowledge and memory, evaluation and feedback, agentic loop, runtime call order, core components

1.3.1 The agent persona

This section defines the agent persona as the first layer of an agent and describes what it can contain and how it can be created.

• Agent persona and role: Explain how an agent persona, often called a system prompt, defines the agent’s base role and guides its tasks and responses. Describe the kinds of attributes it may include.
  Why it matters: The persona establishes the role and guidance from which the agent operates.
• Persona creation methods: Describe the methods the section gives for creating personas, including how evolutionary algorithms can refine them.
  Why it matters: A persona need not be written entirely by hand; it can also be drafted or refined through other methods.

Key terms: agent persona, system prompt, role, operating constraints, handcrafting, LLM-assisted drafting, data-driven techniques, evolutionary algorithms, performance metrics

1.3.2 Agent tools and actions

This section explains how tools and actions extend agents and distinguishes information retrieval from persistent memory and actions in the world.

• Tools and actions layer: Explain how tools help agents complete tasks and support reasoning and planning, knowledge and memory, and evaluation and feedback. Describe how those activities can also drive an agent’s tool use.
  Why it matters: Tools are not just a way to act externally; they also support an agent’s other functions.
• Tool categories and effects: Distinguish context retrieval tools from knowledge and memory tools and task completion tools, including what each does with information or state.
  Why it matters: These distinctions clarify whether a tool is gathering context, accessing persistent memory, or acting in the world.

Key terms: tools and actions, reasoning and planning, knowledge and memory, evaluation and feedback, context retrieval, knowledge and memory tools, task completion tools, external state, persistent stores

1.3.3 Agent reasoning and planning

This section explains when agents need structured reasoning, compares single-path and multipath planning, and introduces external planners.

• Choosing a reasoning approach: Explain when model-native reasoning is usually sufficient and when structured reasoning should be added, including the rule for safety-critical or regulated tasks.
  Why it matters: The choice determines whether the agent has enough control and oversight for the task’s complexity and risk.
• Single-path and multipath planning: Distinguish single-path from multipath reasoning by describing how each handles plans and the trade-off between cost and robustness.
  Why it matters: Considering alternatives can improve a difficult plan, but it consumes more time and tokens.
• External planner responsibility: Describe where planning logic resides when an agent uses an external planner and what the executing agent receives.
  Why it matters: It separates responsibility for deciding the step sequence from responsibility for executing a step.

Key terms: model-native reasoning, structured reasoning augmentation, reasoning trace, guardrails, single-path reasoning, multipath reasoning, tree-of-thought, token, latency, external planners

1.3.4 Agent knowledge and memory

This section explains how agents use external knowledge and interaction-based memory to supply relevant context, and why retrieval and context-window limits shape what an agent sees.

• Knowledge and memory roles: Distinguish an agent’s knowledge from its memory by their sources, how they change, and whom they apply to.
  Why it matters: The distinction helps you decide whether information belongs in shared reference material or in an agent’s interaction history.
• Short and long term memory: Describe conversational memory and distinguish its short-term and long-term forms.
  Why it matters: This explains how an agent can use both the current exchange and relevant information from earlier sessions.
• Context window selection tradeoffs: Explain why the context window forces agents to select, trim, or summarize information rather than include everything.
  Why it matters: Good context management means deciding what to leave out as well as what to retrieve.
• Retrieval augmented agent context: Explain how retrieval-augmented generation brings relevant knowledge or memory into an agent’s context at decision time.
  Why it matters: Retrieval lets an agent use relevant stored information without placing all of it in context at once.
• Knowledge and memory storage forms: Describe the section’s distinction between unified and hybrid knowledge-and-memory structures and give examples of storage or retrieval forms.
  Why it matters: The agent’s information need not live in one kind of store or be retrieved in one way.

Key terms: knowledge, memory, conversational memory, short-term memory, long-term memory, context window, tokens, context window management, retrieval-augmented generation, RAG

1.3.5 Agent evaluation and feedback

This section explains how evaluation and feedback improve agent responses, both as external checks and as internal feedback during the agent’s learn phase.

• External response evaluation: Explain how an external evaluation layer can improve an agent’s response, including the LLM-as-judge example.
  Why it matters: This distinguishes checking a response before delivery from simply accepting the agent’s first output.
• Learn-phase internal feedback: Describe how an agent uses evaluation and feedback during the learn phase of its process loop.
  Why it matters: Feedback can shape what the agent does next, not just check its final response.
• Evaluation mechanism choices: Describe the evaluation mechanisms named here and explain the actor-critic arrangement.
  Why it matters: The section shows that evaluation is not one fixed component; its form depends on the agent system.

Key terms: evaluation and feedback layer, LLM-as-judge, rubric, learn phase, internal feedback, goal-execution plan, guardrails, critic, evaluator, actor-critic arrangement

1.4 Advancing to multi-agent systems

This section explains four reasons to use multiple agents when a single agent is limited by a problem’s scale, scope, or need for independent actors.

• Focused agents and bounded context: Explain how dividing work among agents can improve specialization and keep each agent’s context manageable.
  Why it matters: This explains why splitting work can help even when the agents are not working simultaneously.
• Parallel work across agents: Explain why multiple agents can complete naturally concurrent workloads faster than one agent working sequentially.
  Why it matters: Parallelism is a separate reason to use multiple agents, even if one agent could eventually do every task.
• Problems requiring independent actors: Distinguish problems that inherently require multiple agents from tasks merely made easier or faster by using them.
  Why it matters: In these cases, multiple agents are part of the problem itself, not just a way to improve efficiency.

Key terms: specialization, context management, context window, parallelism, fan out, wall-clock time, inherently multi-agent problems, independent actors, distinct goals

1.4.1 The agent flow assembly line

This section explains how specialized agents can work in an assembly-line flow, how they can share context, and when that pattern is useful.

• Specialized agent flow: Describe an agent flow as an assembly line of specialized agents with distinct tools and resources, and explain the kinds of tasks it suits.
  Why it matters: This gives you a practical way to divide a difficult chain of work among agents.
• Agent coordination options: Distinguish threaded, blackboard, and chained coordination by what agents share and the tradeoff of each.
  Why it matters: How agents share information affects both their access to useful context and the complexity of the flow.
• Context based pattern choice: Explain how downstream agents’ need for shared context guides the coordination choice, including why a simple assembly-line form can be the default.
  Why it matters: This helps you avoid sharing extra context that does not help downstream agents.

Key terms: agent flow, assembly line, specialized worker, designated roles, threaded, blackboard, chained, conversation thread, schema, shared context

1.4.2 Agent orchestrations (hub-and-spoke)

This section explains how a hub-and-spoke agent orchestration delegates work, why it helps, and where it limits collaboration.

• Hub-and-spoke agent roles: Describe how a primary orchestrator plans and coordinates work by delegating subgoals to specialized worker agents, which may also plan internally.
  Why it matters: This division of responsibility is what makes the pattern an orchestration rather than a single agent doing everything.
• Benefits of central delegation: Explain when orchestration is a useful upgrade and how it keeps input and output under one agent’s control while extending a tool-using agent with specialized workers.
  Why it matters: It shows why adding specialist agents need not mean giving up a single point of control.
• Limits on worker collaboration: Explain why tightly restricted worker agents may struggle to provide feedback or evaluation, even when some workers serve as observers or critics.
  Why it matters: The limitation clarifies what centralized delegation trades away.

Key terms: agent orchestration, hub-and-spoke, orchestrator, worker agents, subgoals, single agent, input and output, worker agents as tools, feedback, evaluation

1.4.3 Agent collaboration (teams of agents)

This section explains how teams of role-based agents collaborate and why their ability to tackle complex problems must be weighed against communication and cost.

• Collaborative agent team roles: Describe how agents in a collaborative team communicate with one another and contribute through distinct roles, tools, and functions. Give the QA and product agents as examples.
  Why it matters: The roles and peer communication distinguish a collaborative team from agents merely using tools.
• Collaboration capability and cost: Explain why collaboration can be useful for especially complex problems but is usually reserved for problems that simpler patterns cannot solve. Describe the efficiency and cost tradeoff used to choose a pattern.
  Why it matters: Choosing collaboration only when its added capability is needed helps avoid unnecessary time and expense.

Key terms: agent team, collaboration pattern, agent role, QA agent, product agent, agent collaboration, latency, token spend, operational complexity, capability

1.5 Next steps

Outlines the book’s path from agent layers to advanced systems and clarifies that production operations receive only brief coverage.

1.6 Summary

This chapter summary recaps what makes agents autonomous, how their capabilities are organized and connected to tools, and how multiple agents can work together.