What will I learn in chapter 1 of Build an AI Agent (From Scratch)?

The introduction explains why the book builds agents from scratch rather than relying on frameworks from the outset. After reading it you should be able to: Explain why building agent components yourself helps you diagnose failures, even if you later use a framework. Distinguish personal, customer-facing, and specialized agents by whom they serve and the kinds of tasks they handle. Explain why the book uses “AI agent” and “LLM agent” interchangeably despite the different applications described. Explain that the agents discussed rely on LLMs as their decision-making core. Explain how predicting the next token from preceding tokens, learned through large-scale training, lets an LLM apply language patterns to new examples. Explain that an LLM agent is a program that gives an LLM authority over part of its control flow: deciding what to do next and when to stop from its current context and goals, rather than following only developer-prescribed steps. Describe how the LLM, tools, and loop work together: the LLM decides what to do, tools make external actions possible, and the loop lets decisions and actions recur until the goal is reached. Trace the research agent’s loop: the LLM assesses its context and information needs, chooses a tool if needed, receives the tool result in its context, then decides whether to seek more information or produce the report. Explain why repetition helps when the required tools and number of steps are unknown in advance.

What does section 1.1, The age of AI agents, cover?

Surveys three kinds of modern AI agents and identifies LLMs as their common foundation. Distinguish personal, customer-facing, and specialized agents by whom they serve and the kinds of tasks they handle. Explain why the book uses “AI agent” and “LLM agent” interchangeably despite the different applications described.

What does section 1.2.1, What is an LLM?, cover?

This section defines how the book uses “LLM,” explains next-token prediction and generalization, and introduces reasoning models. Describe what an LLM is and why the book uses the term for multimodal models as well as text models. Explain how predicting the next token from preceding tokens, learned through large-scale training, lets an LLM apply language patterns to new examples. Describe what reasoning models do before producing a result and why the section connects this to agent capabilities.

What does section 1.2.2, What is an LLM agent?, cover?

Defines an LLM agent through a research example and explains how LLM-directed decisions, tools, and an iterative loop let it complete tasks whose steps are not known in advance. Explain that an LLM agent is a program that gives an LLM authority over part of its control flow: deciding what to do next and when to stop from its current context and goals, rather than following only developer-prescribed steps. Describe how the LLM, tools, and loop work together: the LLM decides what to do, tools make external actions possible, and the loop lets decisions and actions recur until the goal is reached. Trace the research agent’s loop: the LLM assesses its context and information needs, chooses a tool if needed, receives the tool result in its context, then decides whether to seek more information or produce the report. Explain why repetition helps when the required tools and number of steps are unknown in advance.

What does section 1.3, Workflow vs. agent, cover?

The section frames LLM application design as a choice about control of execution flow, distinguishing developer-defined workflows from LLM-directed agents. Distinguish workflows from agents by explaining who controls execution flow: developers predefine the steps in a workflow, while an LLM dynamically decides an agent’s actions and when to stop. Describe the three aspects of control shown in the agency progression and explain what changes as autonomy increases.

What does section 1.3.1, Workflow: Developer-defined flow, cover?

This section defines developer-controlled workflows and explains three patterns: a single LLM call, a chain, and a router. Explain that developers define a workflow’s operations and available paths, while LLMs perform specific steps within that structure. Describe a single LLM call as one prompt producing one response for a specific task, with the rest of the process under developer control. Explain how a chain passes one LLM call’s output to the next in a developer-defined order, and why dividing a broad task into focused steps can help.

What does section 1.3.2, Agent: LLM-directed flow, cover?

This section explains how an agent lets an LLM direct tool use and repeat actions until a task is complete, with tool creation as a higher level of autonomy. Explain how an agent differs from a predetermined flow: the LLM chooses what to do next based on the current context and progress toward the goal. Explain why an agent uses tools and how the LLM selects a useful tool and specifies its parameters. Trace the agent’s cycle of assessing its state, deciding on an action, observing the result, and repeating until the task is complete. Explain why this can take one step or many.

What does section 1.3.3, Combining workflows and agents in practice, cover?

This section explains how to embed agents within structured workflows and why that hybrid design can be useful. Describe how a workflow can contain an agent at a stage that needs flexibility while keeping the overall process structured. Use the document-processing example to show where the agent operates and where a workflow stage checks its output. Justify placing agent behavior only where its flexibility is worth the cost, using the section’s reasons of containing complexity, managing costs, and handling failure.

What does section 1.4, Tasks that require agents, cover?

This section introduces a two-stage decision for choosing whether a task needs an agent rather than a simpler approach. Explain why you should first ask whether a task requires an LLM, then, if it does, ask whether it needs an agent or whether a workflow will suffice. State that a no at either stage points to a simpler, more cost-effective approach.

What does section 1.4.1, Tasks that require an LLM, cover?

This section explains how to decide whether a task needs an LLM before considering an LLM agent, using data structure and input diversity as the main criteria. Explain why deciding whether a task needs an LLM comes before deciding whether to use an LLM agent. Describe why analyzing unstructured text, images, or audio makes a task a strong candidate for LLM use, in contrast with structured data. Explain how the range and predictability of inputs or requested tasks affect whether an LLM is worthwhile.

What does section 1.4.2, Conditions for using agents, cover?

Explains when an agent is worth using instead of a single LLM call, weighing task complexity and value against cost, latency, and error risk. Explain why a task that requires gathering information from multiple sources and calculating a result can be a good fit for an agent. Describe the costs, latency, and error risks added by an agent’s multiple steps compared with a single LLM call. Apply task complexity, task value, and error cost and detectability to explain when an agent is justified.

What does section 1.4.3, GAIA: An agent gym, cover?

Introduces GAIA as a benchmark of agent-suited tasks and explains why its clear answers and accessible problems make it useful for practicing agent development. Explain what GAIA contains and why its questions are suited to agents rather than a single LLM call or a predefined workflow. Describe how GAIA’s clear answers support feedback and the observe-analyze-improve cycle of agent development. Explain why GAIA problems can be understood without specialized domain knowledge.

Chapter 1: What is an AI agent?

What you will learn in chapter 1 of Build an AI Agent (From Scratch)

The introduction explains why the book builds agents from scratch rather than relying on frameworks from the outset.

After this chapter you will be able to

Rationale for building from scratch. Explain why building agent components yourself helps you diagnose failures, even if you later use a framework.
Three kinds of agents. Distinguish personal, customer-facing, and specialized agents by whom they serve and the kinds of tasks they handle.
Shared LLM foundation. Explain why the book uses “AI agent” and “LLM agent” interchangeably despite the different applications described.
LLM decision-making role. Explain that the agents discussed rely on LLMs as their decision-making core.
Next-Token Prediction and Generalization. Explain how predicting the next token from preceding tokens, learned through large-scale training, lets an LLM apply language patterns to new examples.
Autonomous agent control flow. Explain that an LLM agent is a program that gives an LLM authority over part of its control flow: deciding what to do next and when to stop from its current context and goals, rather than following only developer-prescribed steps.
LLM tools and loop roles. Describe how the LLM, tools, and loop work together: the LLM decides what to do, tools make external actions possible, and the loop lets decisions and actions recur until the goal is reached.
Iterative tool use and stopping. Trace the research agent’s loop: the LLM assesses its context and information needs, chooses a tool if needed, receives the tool result in its context, then decides whether to seek more information or produce the report. Explain why repetition helps when the required tools and number of steps are unknown in advance.
Workflow and agent control. Distinguish workflows from agents by explaining who controls execution flow: developers predefine the steps in a workflow, while an LLM dynamically decides an agent’s actions and when to stop.
Developer-defined workflow control. Explain that developers define a workflow’s operations and available paths, while LLMs perform specific steps within that structure.
Predefined LLM call chains. Explain how a chain passes one LLM call’s output to the next in a developer-defined order, and why dividing a broad task into focused steps can help.
Router choice within fixed paths. Explain how a router uses an LLM to select among predefined paths and why that choice remains a workflow rather than agent-directed flow.
LLM-directed task flow. Explain how an agent differs from a predetermined flow: the LLM chooses what to do next based on the current context and progress toward the goal.
Multistep agent loop. Trace the agent’s cycle of assessing its state, deciding on an action, observing the result, and repeating until the task is complete. Explain why this can take one step or many.
Agents within workflow stages. Describe how a workflow can contain an agent at a stage that needs flexibility while keeping the overall process structured. Use the document-processing example to show where the agent operates and where a workflow stage checks its output.
Reasons for hybrid architecture. Justify placing agent behavior only where its flexibility is worth the cost, using the section’s reasons of containing complexity, managing costs, and handling failure.
Two-stage agent suitability decision. Explain why you should first ask whether a task requires an LLM, then, if it does, ask whether it needs an agent or whether a workflow will suffice. State that a no at either stage points to a simpler, more cost-effective approach.
LLM need before agents. Explain why deciding whether a task needs an LLM comes before deciding whether to use an LLM agent.
Unstructured data criterion. Describe why analyzing unstructured text, images, or audio makes a task a strong candidate for LLM use, in contrast with structured data.
Input diversity criterion. Explain how the range and predictability of inputs or requested tasks affect whether an LLM is worthwhile.
Agent selection criteria. Apply task complexity, task value, and error cost and detectability to explain when an agent is justified.
GAIA task characteristics. Explain what GAIA contains and why its questions are suited to agents rather than a single LLM call or a predefined workflow.
Clear answers and iteration. Describe how GAIA’s clear answers support feedback and the observe-analyze-improve cycle of agent development.
Prompts Within Broader Context. Distinguish a prompt from context, including the roles of system and user prompts and other information the LLM may reference.
Context Window Information Limits. Explain why the information available in an LLM’s context window matters to an agent’s ability to complete a task.
Two causes of agent failure. Distinguish failures caused by insufficient model intelligence from failures caused by missing task information, using the section’s examples.
Context information and performance. Explain why selecting information for an agent’s context is important to its performance.
Context engineering purpose and scope. Describe context engineering as supplying the information an LLM needs at the right time and in the right form, while keeping the context focused on what the task requires. Give examples of the decisions it includes beyond prompt wording.
Selective Context Over Volume. Explain why filling an LLM’s context window with more data can worsen its responses, and why highly relevant information should be selected instead.
Generated and retrieved context. Distinguish generating context from retrieving it: the LLM can add its own plans or reflections, while retrieval brings in information from external sources.
External writing and context reduction. Explain how writing preserves information outside the context, while reducing shrinks the context to keep attention on important information.
Task and tool isolation. Describe isolating tasks or tools in distinct environments and why this avoids overloading a single context.
Agent harness and context. Explain what the harness includes and how context engineering fits within it.
Python knowledge prerequisites. Describe the Python fundamentals readers need for the book’s examples and exercises: basic data structures, control flow, functions, and classes.
Local development setup. Describe the local setup recommended for completing the exercises, distinguishing necessary preparation from specific recommendations.

Cover of Build an AI Agent (From Scratch)

liveBook manning.com

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

Section by section

Introduction

The introduction explains why the book builds agents from scratch rather than relying on frameworks from the outset.

Rationale for building from scratch: Explain why building agent components yourself helps you diagnose failures, even if you later use a framework.
Why it matters: Understanding an agent’s internals makes failures easier to investigate regardless of which tools you use.

Key terms: agent-building frameworks, build agents from scratch, mental model, debugging failures

1.1 The age of AI agents

Surveys three kinds of modern AI agents and identifies LLMs as their common foundation.

Three kinds of agents: Distinguish personal, customer-facing, and specialized agents by whom they serve and the kinds of tasks they handle.
Why it matters: These distinctions show the range of work agents can be built to do.
Shared LLM foundation: Explain why the book uses “AI agent” and “LLM agent” interchangeably despite the different applications described.
Why it matters: The shared foundation explains why the book begins agent-building with LLMs.

Key terms: personal AI agents, customer-facing agents, specialized agents, AI agent, LLM agent, LLMs

1.2 Understanding LLM agents

This section identifies LLMs as the decision-making core of the agents discussed and introduces questions the following sections will address.

LLM decision-making role: Explain that the agents discussed rely on LLMs as their decision-making core.
Why it matters: This identifies the LLM’s role before the book explains how an agent works.

Key terms: LLMs, decision-making core

1.2.1 What is an LLM?

This section defines how the book uses “LLM,” explains next-token prediction and generalization, and introduces reasoning models.

LLM Scope in This Book: Describe what an LLM is and why the book uses the term for multimodal models as well as text models.
Why it matters: This clarifies what the book means when it calls a model an LLM.
Next-Token Prediction and Generalization: Explain how predicting the next token from preceding tokens, learned through large-scale training, lets an LLM apply language patterns to new examples.
Why it matters: Next-token prediction and generalization explain the basic capability on which the book’s agents rely.
Reasoning Models Before Answers: Describe what reasoning models do before producing a result and why the section connects this to agent capabilities.
Why it matters: This distinguishes a reasoning model’s pre-answer thinking from an immediate response.

Key terms: LLM, multimodal models, foundational architecture, tokens, next token, generalization, reasoning models, thinking tokens, <think>

1.2.2 What is an LLM agent?

Defines an LLM agent through a research example and explains how LLM-directed decisions, tools, and an iterative loop let it complete tasks whose steps are not known in advance.

Autonomous agent control flow: Explain that an LLM agent is a program that gives an LLM authority over part of its control flow: deciding what to do next and when to stop from its current context and goals, rather than following only developer-prescribed steps.
Why it matters: This distinction explains what makes the research example an agent rather than just a fixed sequence of searches.
LLM tools and loop roles: Describe how the LLM, tools, and loop work together: the LLM decides what to do, tools make external actions possible, and the loop lets decisions and actions recur until the goal is reached.
Why it matters: The three roles show how an agent can do more than produce a response from its training data.
Iterative tool use and stopping: Trace the research agent’s loop: the LLM assesses its context and information needs, chooses a tool if needed, receives the tool result in its context, then decides whether to seek more information or produce the report. Explain why repetition helps when the required tools and number of steps are unknown in advance.
Why it matters: The loop explains how a research agent can adapt its searches as findings arrive instead of requiring a predetermined number of steps.

Key terms: LLM agent, autonomous control flow, control flow, current context, goals, LLM, tools, loop, action space, agent loop

1.3 Workflow vs. agent

The section frames LLM application design as a choice about control of execution flow, distinguishing developer-defined workflows from LLM-directed agents.

Workflow and agent control: Distinguish workflows from agents by explaining who controls execution flow: developers predefine the steps in a workflow, while an LLM dynamically decides an agent’s actions and when to stop.
Why it matters: This distinction helps you choose an architecture suited to your use case.
Dimensions of LLM agency: Describe the three aspects of control shown in the agency progression and explain what changes as autonomy increases.
Why it matters: These dimensions make the amount of LLM control more precise than a simple workflow-or-agent label.

Key terms: workflows, agents, execution flow, levels of agency, current step, next step, available steps

1.3.1 Workflow: Developer-defined flow

This section defines developer-controlled workflows and explains three patterns: a single LLM call, a chain, and a router.

Developer-defined workflow control: Explain that developers define a workflow’s operations and available paths, while LLMs perform specific steps within that structure.
Why it matters: Developer control is the basis for recognizing all three patterns as workflows.
Single LLM call pattern: Describe a single LLM call as one prompt producing one response for a specific task, with the rest of the process under developer control.
Why it matters: A workflow can be as simple as one well-crafted model call.
Predefined LLM call chains: Explain how a chain passes one LLM call’s output to the next in a developer-defined order, and why dividing a broad task into focused steps can help.
Why it matters: Chaining shows how a developer can structure a complex request without giving up control of the flow.
Router choice within fixed paths: Explain how a router uses an LLM to select among predefined paths and why that choice remains a workflow rather than agent-directed flow.
Why it matters: An LLM making a decision does not, by itself, make a system an agent.

Key terms: workflow, predictability, single LLM call, prompt, response, chain, predefined sequence, focused, well-defined tasks, router, predefined path

1.3.2 Agent: LLM-directed flow

This section explains how an agent lets an LLM direct tool use and repeat actions until a task is complete, with tool creation as a higher level of autonomy.

LLM-directed task flow: Explain how an agent differs from a predetermined flow: the LLM chooses what to do next based on the current context and progress toward the goal.
Why it matters: This distinction explains what makes the flow agent-directed.
Tools as external capabilities: Explain why an agent uses tools and how the LLM selects a useful tool and specifies its parameters.
Why it matters: Tools let an agent do things that text generation alone cannot do.
Multistep agent loop: Trace the agent’s cycle of assessing its state, deciding on an action, observing the result, and repeating until the task is complete. Explain why this can take one step or many.
Why it matters: The loop explains how an agent can handle tasks whose required steps are not known in advance.
Autonomous tool creation: Describe how an agent at a higher level of autonomy can create functionality missing from its predefined tools, such as a custom parser.
Why it matters: Tool creation shows how an agent can adapt to a requirement its original toolkit did not anticipate.

Key terms: agent, LLM, current context, external tools, callable functions, parameters, multistep loop, current state, action, result

1.3.3 Combining workflows and agents in practice

This section explains how to embed agents within structured workflows and why that hybrid design can be useful.

Agents within workflow stages: Describe how a workflow can contain an agent at a stage that needs flexibility while keeping the overall process structured. Use the document-processing example to show where the agent operates and where a workflow stage checks its output.
Why it matters: This pattern gives an agent room to adapt without making the entire process unpredictable.
Reasons for hybrid architecture: Justify placing agent behavior only where its flexibility is worth the cost, using the section’s reasons of containing complexity, managing costs, and handling failure.
Why it matters: The design decision is where an agent earns its added flexibility and expense, not whether every part must be a workflow or an agent.

Key terms: workflow, agent, agents as nodes in a workflow, quality review, hybrid approach, complexity, agent loops, graceful degradation

1.4 Tasks that require agents

This section introduces a two-stage decision for choosing whether a task needs an agent rather than a simpler approach.

Two-stage agent suitability decision: Explain why you should first ask whether a task requires an LLM, then, if it does, ask whether it needs an agent or whether a workflow will suffice. State that a no at either stage points to a simpler, more cost-effective approach.
Why it matters: These questions help you avoid building an agent when a simpler solution would do.

Key terms: LLM, agent, workflow

1.4.1 Tasks that require an LLM

This section explains how to decide whether a task needs an LLM before considering an LLM agent, using data structure and input diversity as the main criteria.

LLM need before agents: Explain why deciding whether a task needs an LLM comes before deciding whether to use an LLM agent.
Why it matters: Checking for a simpler solution can avoid unnecessary cost and errors.
Unstructured data criterion: Describe why analyzing unstructured text, images, or audio makes a task a strong candidate for LLM use, in contrast with structured data.
Why it matters: The form of the data helps you choose between flexible interpretation and conventional programming.
Input diversity criterion: Explain how the range and predictability of inputs or requested tasks affect whether an LLM is worthwhile.
Why it matters: The variety of requests helps determine whether flexibility is worth an LLM’s cost and latency.

Key terms: LLM agent, computational cost, deterministic approaches, unstructured data, structured data, clear schemas, Input diversity, rule-based system, hardcode the logic

1.4.2 Conditions for using agents

Explains when an agent is worth using instead of a single LLM call, weighing task complexity and value against cost, latency, and error risk.

Multistep research tasks: Explain why a task that requires gathering information from multiple sources and calculating a result can be a good fit for an agent.
Why it matters: The example shows what an agent can help with before you weigh whether using one is worthwhile.
Agent execution tradeoffs: Describe the costs, latency, and error risks added by an agent’s multiple steps compared with a single LLM call.
Why it matters: These tradeoffs explain why a simple request may be better handled without an agent.
Agent selection criteria: Apply task complexity, task value, and error cost and detectability to explain when an agent is justified.
Why it matters: These criteria help you choose an agent for tasks that warrant one rather than using agents by default.

Key terms: multistep research task, agents, costs, latency, errors propagate, task complexity, task value, error cost and detectability

1.4.3 GAIA: An agent gym

Introduces GAIA as a benchmark of agent-suited tasks and explains why its clear answers and accessible problems make it useful for practicing agent development.

GAIA task characteristics: Explain what GAIA contains and why its questions are suited to agents rather than a single LLM call or a predefined workflow.
Why it matters: The nature of GAIA’s questions explains why it is a useful setting for developing agents.
Clear answers and iteration: Describe how GAIA’s clear answers support feedback and the observe-analyze-improve cycle of agent development.
Why it matters: Checkable answers make failures easier to spot and improvements easier to test.
Accessible search tasks: Explain why GAIA problems can be understood without specialized domain knowledge.
Why it matters: Readers can focus on agent development rather than first learning a specialist subject.

Key terms: GAIA, question-and-answer pairs, multistep reasoning, agentic approach, clear answers, fast feedback, agent development cycle, observe-analyze-improve cycle, web search, information synthesis

1.5 Context engineering

This section distinguishes prompts from context and explains why an agent needs the right information in the LLM’s context window.

Prompts Within Broader Context: Distinguish a prompt from context, including the roles of system and user prompts and other information the LLM may reference.
Why it matters: The distinction helps you see that an agent’s response depends on more than the latest user request.
Context Window Information Limits: Explain why the information available in an LLM’s context window matters to an agent’s ability to complete a task.
Why it matters: An agent cannot make effective use of task information that is absent from the context the LLM receives.

Key terms: prompt, system prompts, user prompts, context, context window, context engineering, next token

1.5.1 Why agents fail

This section distinguishes failures caused by limited model intelligence from failures caused by missing information, and explains why the information in an agent’s context matters to its performance.

Two causes of agent failure: Distinguish failures caused by insufficient model intelligence from failures caused by missing task information, using the section’s examples.
Why it matters: Identifying which cause is at work helps you avoid treating every failure as a need for a stronger model.
Context information and performance: Explain why selecting information for an agent’s context is important to its performance.
Why it matters: Even a capable model needs the relevant information available to produce an accurate answer.

Key terms: insufficient model intelligence, lack of necessary information, context, information deficiency, agent performance

1.5.2 From prompt engineering to context engineering

This section explains why tool-using agents need context engineering in addition to prompt engineering.

Dynamic agent context: Explain why writing a good system prompt is no longer enough when agents use tools: search, code, and database results are added to the context as the agent works.
Why it matters: The information an agent receives changes as it acts, so the initial prompt is only part of the picture.
Context engineering purpose and scope: Describe context engineering as supplying the information an LLM needs at the right time and in the right form, while keeping the context focused on what the task requires. Give examples of the decisions it includes beyond prompt wording.
Why it matters: Useful agent behavior depends on giving the LLM relevant information, not just well-worded instructions.

Key terms: prompt engineering, system prompts, context, context engineering, tool-execution results, conversation history, external knowledge

1.5.3 Bigger context isn’t always better

This section explains why large context windows do not make it useful to give an LLM all available information.

Selective Context Over Volume: Explain why filling an LLM’s context window with more data can worsen its responses, and why highly relevant information should be selected instead.
Why it matters: Choosing relevant context can help the model use crucial information rather than lose it among unnecessary material.

Key terms: context window, context rot, lost in the middle, highly relevant information

1.5.4 Five context-engineering strategies

The section distinguishes five ways to shape an agent’s context and shows how three of them work together in memory systems.

Generated and retrieved context: Distinguish generating context from retrieving it: the LLM can add its own plans or reflections, while retrieval brings in information from external sources.
Why it matters: The distinction clarifies whether useful context comes from the agent’s own work or an outside source.
External writing and context reduction: Explain how writing preserves information outside the context, while reducing shrinks the context to keep attention on important information.
Why it matters: Keeping information for later and keeping the current context focused solve different problems.
Task and tool isolation: Describe isolating tasks or tools in distinct environments and why this avoids overloading a single context.
Why it matters: Separate environments help keep each task’s context suited to that task.
Combined memory strategies: Explain why memory systems use retrieve, write, and reduce together.
Why it matters: Memory shows that context-engineering strategies can work together rather than being alternatives.

Key terms: Generate, Retrieve, context, Write, Reduce, context window, context rot, Isolate, sandbox environments, separate agents

1.5.5 From context engineering to harness engineering

The section defines the harness as everything outside the model that supports an agent and explains why real-world agent use has brought harness engineering into focus.

Agent harness and context: Explain what the harness includes and how context engineering fits within it.
Why it matters: This distinction helps you see that an agent’s capabilities depend on more than its model.
Real-world harness demands: Explain why attention widened from context engineering to harness engineering as agents became real products.
Why it matters: It explains why the book treats an agent’s surrounding systems as practical design concerns.

Key terms: harness, harness engineering, context engineering, Agent = Model + Harness, memory and skills, code execution, multi-agent

1.5.6 The journey of this book

This section maps the book’s progression from a basic agent loop through added capabilities to evaluation.

1.6 Prerequisites for reading this book

This section identifies the Python skills, local setup, service access, and likely costs needed to follow the book’s hands-on exercises.

Python knowledge prerequisites: Describe the Python fundamentals readers need for the book’s examples and exercises: basic data structures, control flow, functions, and classes.
Why it matters: These basics let you follow and modify the code rather than getting stuck on Python syntax.
Local development setup: Describe the local setup recommended for completing the exercises, distinguishing necessary preparation from specific recommendations.
Why it matters: A working local setup lets you run the exercises as you read.
Service access and costs: State which external-service access and API background the exercises call for, and summarize the costs described here.
Why it matters: Knowing the required services and expected expense helps you prepare before reaching the API exercises.

Key terms: plain Python, data structures, control flow, functions, classes, local Python development environment, code editor or IDE, pip, uv, OpenAI API key

1.7 Summary

Summarizes what LLM agents are, how their control differs from workflows, when they are useful, and why context engineering matters.

Where this is used later

Components we have to build (chapter 4) · Identifying the components to build puts the from-scratch approach into practice.
(chapter intro) (chapter 2) · The earlier introduction to what an LLM agent is.
Why do we need LLM tools? (chapter 3) · Motivating tools as a way to extend what an LLM-based agent can do.
The think-act cycle (chapter 4) · Providing the basic roles behind the think-act cycle.
Three collaboration patterns (chapter 9) · The distinction between a developer-defined flow and an agent-directed one.
Agent workflow: Defining order in code (chapter 9) · The distinction between developer-defined and agent-directed flow.
Sequential: Step-by-step execution (chapter 9) · Builds on the idea of developer-ordered, step-by-step execution.
(chapter intro) (chapter 10) · The distinction between an agent’s LLM-directed flow and a developer-defined workflow.

Concepts explained in this chapter

AI agentAn AI agent is a software system that uses artificial intelligence to perceive information, perform tasks, and make or execute decisions on a user's or organization's behalf.
tool usageA tool call is a model-generated specification requesting invocation of a particular external tool with particular arguments.
context engineeringThe discipline of designing which information is provided to a language model, when it is provided, and how it is represented for task completion.
language modelA large language model is a neural language model trained on extensive text data that generates and interprets language.
pipelineA workflow is a predefined sequence of computational steps that controls execution while delegating selected steps to language models or other components.
ReActThe ReAct pattern is an agent design in which reasoning and action alternate so the agent can incorporate tool results and adapt its subsequent behavior.
specialized agentA specialized agent is an AI agent designed for domain-specific tasks that require substantial expertise or extended processing.
GAIAThe GAIA dataset is a collection of benchmark problems, metadata, and associated task files for evaluating general-purpose AI assistants.
control flowControl flow is the sequence and selection of computational operations that determines what a program does next.
memoryAgent memory is a mechanism for retaining and retrieving information across an agent's reasoning steps or interactions.
similarity searchRetrieval is the technique of obtaining relevant information from external data sources for use during task execution.
loopA loop workflow repeatedly runs one or more agents across iterations until a stopping condition is met or an iteration limit is reached.
continuous improvementA reasoning process that repeatedly evaluates intermediate results and determines subsequent steps.
context windowA context window is the maximum amount of tokenized input and generated context that a language model can process together.
routingA router agent is an AI agent that examines a request and transfers control to an appropriate specialist agent.
Agent classThe Agent class is the book's abstract programming interface for representing an agent loop.
MCPModel Context Protocol is an open protocol that standardizes how AI applications connect to tools, prompts, resources, and external services.
multi-agent systemA multi-agent setup is an architecture in which multiple agents cooperate to complete a task.
planningPlanning is the construction of an ordered strategy or set of steps for completing a complex task.
pluginAn agent skill is a reusable capability that packages knowledge or procedures for carrying out a class of tasks.
reflectionReflection is an agent technique for examining intermediate reasoning or results and revising subsequent actions.
workspaceAn agent workspace is an execution environment in which the agent can create, inspect, and manipulate task-related artifacts.
prompt engineeringPrompt engineering is the practice of designing prompts and instructions to elicit accurate or appropriately formatted outputs from a language model.
promptAn instruction supplied to a language model that establishes high-level behavior or constraints for an interaction.
research agentA research agent is an LLM agent that gathers and synthesizes information from multiple sources to produce a research report.
autonomyAutonomy is the capacity of a system to determine and continue its own actions without a predetermined sequence controlling every step.
evaluationAgent evaluation is the systematic measurement of an agent's behavior and task performance.
file reading and writingFile reading is a tool capability that retrieves content from files available to an agent.
web searchWeb search is a tool capability that retrieves information from internet-accessible search indexes or pages.
structured dataData organized according to a defined schema with predictable fields, types, or relationships.
dialogueConversation history is the accumulated sequence of prior messages retained for continuing an interaction with a language model.
benchmarkA benchmark is a standardized evaluation used to compare system performance on a specified set of tasks.

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.