Chapter 01 · The Agentic Mindset
Your LLM is a brain in a jar.
Picture it. A flawless, glistening brain suspended in nutrient fluid inside a glass container on a lab bench. It contains the sum of human knowledge. It can reason about quantum mechanics, write a sonnet in iambic pentameter, explain the Krebs cycle at five different levels of complexity, and debug your Rust borrow-checker errors. It is brilliant. It is knowledgeable. And it is utterly, completely paralyzed.
The brain has no hands. It cannot open a browser. It cannot read your email. It cannot check tomorrow's weather, query a database, or run a single line of code. It cannot remember what you said to it thirty seconds ago unless you say it again. Every conversation starts from zero. Every question lands on a blank slate. The brain thinks, produces text, and stops. That is the entirety of its existence.
This book gives it hands.
This book gives it memory. This book gives it the ability to act, to observe the results of its actions, to course-correct, and to keep going until the job is done. This book turns the brain in the jar into an agent — a system that perceives, reasons, decides, and acts in a continuous loop. By the time you finish the last chapter, you will have built agents that research topics, write and execute code, coordinate with other agents, and operate autonomously for hours at a time.
But before you write a single line of code, you need to understand what you are building and why. That is what this chapter is for.
What This Book Is (and What It Isn't)
This is not a book about prompt engineering.
You will not find chapters titled "37 Tricks to Get Better Responses from ChatGPT" or "The Ultimate System Prompt Template." Prompt engineering is a useful skill. It is also a dead end. Tweaking the wording of a prompt to coax a slightly better answer out of a model is not engineering — it is alchemy. It does not scale, it does not compose, and it does not teach you to build systems.
This is a book about building systems that think, decide, and act.
You will write real code. You will build things that work. By Chapter 4, you will have a running agent loop. By Chapter 11, you will have multiple agents coordinating on a shared task. By Chapter 20, you will have an agent that can write, test, and debug its own code. Every chapter builds on the last. Nothing is throwaway. When you finish, you will have a personal library of agent components you can remix for any project.
You need to know Python. You should have called an LLM API at least once — an OpenAI chat completion, an Anthropic message, anything that gave you a response from a model. You should be comfortable with functions, classes, async/await, and reading API documentation. If you have built a web app or a data pipeline, you are ready.
You do not need a PhD. You do not need to understand transformer architectures or attention mechanisms. Chapter 2 covers how LLMs work at the level you actually need — tokens, temperature, context windows, and why any of it matters when you are building an agent. Nothing more, nothing less.
Section 1: What Is an Agent, Really?
The word "agent" gets thrown around a lot. Every AI startup has one. Every framework claims to build them. Most of what people call agents are just thin wrappers around a single API call. That is not what we are building.
Here is the definition this book uses:
An agent is a system that operates in a continuous loop: observe, think, act, observe. It maintains state across iterations. It decides what to do next based on what it has seen and done before.
Three words matter in that definition: loop, state, and decides.
A chatbot does not loop. You send a message, it sends a response, the interaction ends. There is no state beyond the current conversation turn. The model does not decide to do anything — it just generates text. A chatbot is a brain in a jar taking questions through a slot in the glass.
An automation script does not think. It follows a predetermined sequence of steps. If the API returns an unexpected error, the script crashes or hits a hardcoded fallback. It cannot look at the error message, figure out what went wrong, and try a different approach. It acts, but it does not reason.
Traditional software does not handle novelty. Every path through the code was anticipated by a developer. If the user does something unexpected, the software either ignores it, throws an error, or does the wrong thing. Traditional software follows rules. It does not reason about situations the programmer never considered.
An agent is different. An agent encounters a task — "research the competitive landscape for electric cargo bikes and produce a summary with citations" — and it figures out what to do. It searches the web. It reads the results. It realizes it needs more specific data and searches again. It synthesizes findings. It produces the summary. If a search fails, it tries different query terms. If a source looks unreliable, it cross-references. It does all of this without a human telling it each next step.
The key insight that makes all of this possible:
LLMs enable agents because they can reason about novel situations. Traditional software cannot handle "figure out what the user means and do the right thing." LLMs can.
This is the fundamental shift. For the first time, we have a software component that can look at an unfamiliar situation and produce a reasonable plan of action. It is not always right. It makes mistakes. But it is right often enough, and its mistakes are structured enough, that we can build systems around it.
The Agent Spectrum
Not all agents are created equal. They exist on a spectrum:
Level 1: LLM + Single Tool. The simplest agent. You give the model access to one function — a calculator, a search API, a database query — and it calls it when needed. This is where you start in Chapter 5.
Level 2: LLM + Multiple Tools + Memory. The model has access to several tools and maintains state across calls. It can chain tool calls: search for information, then summarize it, then save the summary to a file. This is where most production agents live.
Level 3: Planning Agents. Before acting, the agent produces a plan. It breaks the task into subtasks, executes them in order, and revises the plan as new information arrives. Chapter 14 covers this in depth.
Level 4: Reflective Agents. The agent critiques its own output. It generates a response, then asks itself: "Is this actually correct? Did I miss anything? Could I do better?" It iterates until it is satisfied. Chapter 16.
Level 5: Multi-Agent Systems. Multiple agents, each with different tools and personalities, coordinate on a shared task. One researches, one writes, one reviews. They pass work between each other. Chapter 19.
Every level builds on the one before it. You do not skip from Level 1 to Level 5. You add one capability at a time, and you understand exactly what each addition costs in complexity, latency, and money.
Section 2: The Four Components of Every Agent
Every agent, from the simplest Level 1 to the most complex multi-agent swarm, is built from exactly four components. If you understand these four, you understand agents.
The Model (Brain)
The model is the reasoning engine. It is the LLM — Claude, GPT-4, Gemini, Llama, or any other large language model — that looks at the current situation and decides what to do.
When you choose a model for your agent, five properties matter:
Reasoning ability. Can the model think through multi-step problems? Can it handle ambiguity? Can it recognize when it does not know something? A model that confidently produces wrong answers is worse than useless in an agent — it will call the wrong tools with the wrong parameters and never realize it made a mistake.
Tool-use capability. Can the model reliably produce structured function calls? This is not about whether the API supports tool use — most do. It is about whether the model understands when to call a tool, which tool to call, and how to format the arguments. A model that calls search_web(query="") when it should call query_database(sql="SELECT...") will waste cycles and produce garbage.
Context window size. How much information can the model hold in its working memory at once? A 4K context window holds roughly 3,000 words — enough for a short conversation. A 200K context window holds roughly 150,000 words — enough for an entire codebase, a long conversation history, and detailed instructions. Context window size directly determines how much state your agent can maintain without external memory.
Latency. How fast does the model respond? An agent loop might make 10, 20, or 50 model calls to complete a single task. If each call takes 5 seconds, your agent is unusable. If each call takes 200 milliseconds, it feels responsive. Latency is a first-class design constraint.
Cost. How much does each call cost? At $15 per million input tokens, a 50-call agent loop with 10K tokens per call costs about $7.50. At $0.15 per million tokens, the same loop costs $0.075. Cost determines whether you can afford to run your agent at scale.
You do not need the most powerful model for every task. A fast, cheap model can handle simple decisions. You reserve the expensive, high-reasoning model for the hard parts. Chapter 8 covers model selection and routing in detail.
The Tools (Hands)
Tools are functions the agent can call. They are the hands attached to the brain.
A tool is just a function with a description. The description tells the model what the function does, what parameters it expects, and when to use it. The model decides to call the function, the agent runtime executes it, and the result goes back into the model's context.
Tools can be anything:
- APIs: Search the web, send an email, create a calendar event, query a database, call another AI model.
- File system: Read a file, write a file, list a directory, check if a file exists.
- Code execution: Run Python, run SQL, run a shell command, evaluate an expression.
- Human-in-the-loop: Ask the user a question, request approval, escalate an issue.
The agent's job is not to execute tools — it is to decide which tool to use, when to use it, and how to interpret the result. This is where the intelligence lives. A search tool is trivial to implement. Deciding that the search results are low-quality and a different query is needed — that is the hard part.
A tool is not a capability. A tool is an option. The agent's intelligence is in choosing the right option at the right time.
The Memory (Experience)
Without memory, every interaction starts from zero. The agent does not remember what it just did, what it learned, or what the user told it five minutes ago. Memory is what turns a sequence of independent API calls into a coherent, goal-directed process.
There are three kinds of memory:
Short-term memory is the conversation history stored in the model's context window. Every message — user input, model response, tool call, tool result — gets appended to the context. The model can "remember" anything in its context window. When the context fills up, older messages get dropped. This is the simplest form of memory and the one you will use first.
Working memory is a scratchpad for intermediate results. The agent searches the web and gets 20 results. It does not need all 20 in the context forever — it needs to extract the relevant ones, summarize them, and store the summary. Working memory is where the agent keeps what it is currently thinking about. It can be as simple as a Python dictionary or as structured as a key-value store.
Long-term memory persists across sessions. It lives outside the context window — in a vector database, a SQL database, or a file system. The agent can store facts, preferences, and lessons learned, then retrieve them in future sessions. "The user prefers concise answers." "The API rate limit is 100 requests per minute." "This approach failed last time; try something different." Chapter 12 covers long-term memory in depth.
The Loop (Will)
The loop is what makes an agent an agent. Without the loop, you have a single LLM call — useful, but not an agent. The loop is the control flow that keeps the agent running until the task is complete.
Here is the loop in its simplest form:
while not task_complete:
observation = get_observation() # What is happening right now?
thought = llm.think( # Given everything I know...
system_prompt, # my instructions,
memory, # what I remember,
observation # and what I just saw,
) # ...what should I do?
action = parse_action(thought) # Convert the thought into a concrete action.
result = execute_action(action) # Do it.
memory.add(thought, action, result) # Remember what happened.
That is it. Fifteen lines of pseudocode. Every agent you build in this book is a variation on this loop. The complexity comes from what you put inside each step — how you structure memory, how you define tools, how you handle errors, how you decide when the task is complete. But the skeleton never changes.
The loop enables three things that a single LLM call cannot do:
Multi-step problem solving. The agent can break a complex task into steps and execute them one at a time, using the results of each step to inform the next. Search, read, extract, synthesize, verify — each step builds on the last.
Error recovery. When a tool call fails, the agent sees the error, figures out what went wrong, and tries something different. It does not crash. It adapts.
Adaptation. The agent can change its approach mid-task. If the first search returns nothing useful, it tries different keywords. If a file is too large to read in one pass, it reads it in chunks. The loop gives the agent the ability to respond to reality rather than follow a script.
Section 3: Why Now?
Agents are not a new idea. The term "software agent" dates back to the 1990s. Researchers have been building autonomous systems for decades. So why is this book being written now, and why should you care?
Five things changed between 2022 and 2025:
1. LLMs Crossed the Reasoning Threshold
Before GPT-4, you could not trust an LLM to reliably decide which tool to call. Models would hallucinate function names, invent parameters, or call tools in nonsensical orders. You could build demos, but you could not build production systems.
That changed. GPT-4, Claude 3, and their peers can now look at a task description, a list of available tools, and the current state, and produce a reasonable plan of action. They are not perfect — they still make mistakes — but their error rate dropped below the threshold where you can build reliable systems around them. The mistakes that remain are structured and predictable enough that you can handle them with validation, retry logic, and fallback strategies.
2. Tool-Use APIs Became Standardized
In 2023, OpenAI shipped function calling. A few months later, Anthropic shipped tool use. Both follow the same pattern: you describe your functions in a JSON schema, the model returns a structured function call, you execute it, and you pass the result back. This standardization means you can write tool definitions once and use them with any model that supports the pattern. It also means frameworks can abstract over model providers, which they did.
3. Context Windows Exploded
In 2022, the standard context window was 4,096 tokens — about 3,000 words. You could fit a system prompt and a short conversation. That was it.
In 2025, 200,000-token context windows are standard. Gemini offers 2 million. This changes everything. An agent can now hold an entire codebase in working memory. It can maintain a long conversation history without summarization. It can process large documents in a single pass. Context window size is not just a convenience — it fundamentally changes what kinds of agents you can build.
4. Cost Collapsed
Running an agent loop that makes 50 LLM calls used to cost dollars. GPT-4 was $30 per million input tokens at launch. Today, models with comparable capability cost $0.15 per million tokens — a 200x reduction. Fast, cheap models like Claude Haiku and GPT-4o-mini cost even less.
This matters because agents are inherently expensive in terms of token usage. A single user request might trigger 10, 20, or 50 model calls. At $30/M tokens, that is a real cost. At $0.15/M tokens, it is a rounding error. The economics now support agents in production.
5. The Ecosystem Matured
You no longer need to build everything from scratch. Libraries like the Anthropic SDK, OpenAI SDK, and LangChain provide building blocks for tool definition, message management, and agent loops. Frameworks handle the plumbing so you can focus on the interesting parts — tool design, memory architecture, and loop control flow. You will use some of these in this book, and you will also learn when not to use them. A framework is a tool, not a requirement.
The bottom line: the pieces are in place. The models are capable, the APIs are stable, the context windows are large, the cost is low, and the tooling is mature. There has never been a better time to learn how to build agents.
Section 4: What You'll Build in This Book
This book is a construction project. Every chapter produces something that works. Here is the roadmap:
Part I: Foundations (Chapters 1-4)
Chapter 2 takes you inside the jar — how LLMs actually work, from tokens to temperature, with nothing you do not need. Chapter 3 sets up your development environment. Chapter 4 has you write your first agent loop. By the end of Part I, you have a running agent that can hold a conversation and maintain state.
Part II: Tools and Actions (Chapters 5-8)
Chapter 5 gives your agent its first tool. Chapter 6 adds multiple tools and teaches the agent to choose between them. Chapter 7 covers structured output — getting the agent to produce JSON, function calls, and typed data reliably. Chapter 8 tackles model selection and routing: when to use the fast cheap model and when to call in the heavy artillery.
Part III: Memory and State (Chapters 9-12)
Chapter 9 builds working memory — scratchpads, notebooks, and intermediate state. Chapter 10 implements conversation management: summarization, compaction, and context window strategies. Chapter 11 introduces vector databases and semantic search. Chapter 12 ties it together into a long-term memory system that persists across sessions.
Part IV: Planning and Reasoning (Chapters 13-16)
Chapter 13 teaches your agent to break tasks into steps. Chapter 14 implements plan-and-execute: the agent produces a plan, then follows it. Chapter 15 adds reflection: the agent critiques its own output and iterates. Chapter 16 combines planning and reflection into a single loop.
Part V: Multi-Agent Systems (Chapters 17-19)
Chapter 17 introduces agent-to-agent communication. Chapter 18 builds a coordinator agent that delegates work to specialists. Chapter 19 is the capstone: a multi-agent research team that can investigate a topic, debate findings, and produce a cited report.
Part VI: Production (Chapters 20-22)
Chapter 20 builds a coding agent that writes, tests, and debugs code. Chapter 21 covers evaluation — how to know if your agent is actually getting better. Chapter 22 covers deployment, monitoring, and observability.
Every project builds on the last. The agent loop from Chapter 4 is the same loop that powers the multi-agent system in Chapter 19. The tool definitions from Chapter 5 are the same pattern you use in Chapter 20. Nothing is throwaway code. By the end, you have a personal library of agent components you understand deeply because you built them yourself.
Section 5: The Mindset
Before you write code, internalize these five principles. They will save you months of frustration.
1. Agents Are Software, Not Magic
The LLM is one component in a larger system. It is the most interesting component, and the one that gets all the attention, but it is not the whole story. Around the LLM sits tool execution, memory management, error handling, logging, validation, retry logic, rate limiting, and all the other unglamorous infrastructure that makes software reliable.
When your agent fails, do not blame the model. Look at the system. Is the prompt clear? Are the tool descriptions accurate? Is the error handling catching failures and feeding useful information back to the model? Is the memory system surfacing the right context at the right time? Nine times out of ten, the fix is in the infrastructure, not the model.
2. Expect Failure
Agents will call the wrong tool. They will hallucinate parameters. They will get stuck in loops, calling the same failing function over and over. They will produce output that looks plausible but is factually wrong. They will exceed your token budget. They will time out. They will do things you never anticipated.
This is not a sign that agents do not work. It is a sign that you are building a system with a non-deterministic component at its core. Your job is to build systems that handle this gracefully. Validate tool inputs before executing them. Set maximum iteration counts. Implement circuit breakers. Log everything. Design fallback paths. Assume the model will fail and build a system that survives that failure.
3. Start Simple
The most common failure mode in agent development is over-engineering. Someone reads a paper about multi-agent debate with tree-of-thought reasoning and reflexion loops, and they try to build the whole thing at once. It does not work. They cannot debug it because there are too many moving parts. They give up.
Do not do this.
Start with a single LLM call. Get the prompt right. Then add one tool. Get the tool calling working reliably. Then add a second tool. Then add memory. Then add a loop. Add one piece at a time, and verify that each piece works before adding the next.
A single LLM call with a well-designed prompt often beats a complex multi-agent system. Complexity is a cost, not a virtue. Add it only when the simpler approach demonstrably fails.
4. Test in Production
Agent behavior is emergent. You cannot predict all failure modes from a notebook or a test suite. The model will surprise you — sometimes delightfully, sometimes catastrophically. The only way to discover the catastrophic surprises is to ship something simple and watch it run.
This does not mean shipping broken software to users. It means deploying a simple agent internally, logging everything, and observing. What tools does it call most often? Where does it get stuck? What kinds of inputs confuse it? Use those observations to harden the system before it ever touches a real user.
5. The Model Is Not Your Friend
Anthropomorphism is the enemy of good agent design. The model is not "thinking" in any human sense. It is not "trying its best" or "getting confused." It is a token predictor. It produces the most statistically likely sequence of tokens given its training data and the current context. Sometimes that sequence happens to be correct and useful. Sometimes it happens to be plausible-sounding nonsense.
Treat the model like a component with a spec, not a colleague with feelings. It has failure modes. It has performance characteristics. It has a context window limit. It has a cost per call. Design your system around these facts, not around a fantasy of machine consciousness.
The Turn
Here is what you need to understand, right now, before you turn the page:
Every agent, no matter how complex, is just four components arranged in a loop. A brain that reasons. Hands that act. Memory that persists. A loop that keeps it all running.
You already know how to call an LLM API. You have done it. A few lines of Python, an API key, a prompt, and text comes back. That is the brain.
You already know how to write functions. You have written thousands of them. A function that searches the web, a function that queries a database, a function that sends an email. Those are the hands.
You already know how to store data. A list, a dictionary, a database, a file. That is memory.
You already know how to write a while loop. A condition, a body, an iteration. That is the loop.
You have all the pieces. You have had them for years. The only thing you have been missing is the arrangement — the pattern that connects the API call to the function to the data store to the loop. That pattern is what this book teaches.
Agents are not magic. They are not artificial general intelligence. They are not the Singularity. They are software systems built from components you already understand, arranged in a way you are about to learn.
You open your terminal. You write the loop. You watch it think.
Looking Ahead
In the next chapter, you will learn exactly what happens inside that jar.
You will learn how an LLM turns your prompt into tokens, how those tokens flow through the model, and how the model decides which token comes next. You will learn what temperature actually does, why context windows have limits, and how tool-use APIs work under the hood. You will learn the difference between a 7B model and a 70B model, between a base model and an instruct-tuned model, between a completion and a chat model.
And you will learn none of the things you do not need. No attention mechanism math. No transformer architecture diagrams. No backpropagation. Just the mental model you need to build agents that work.
The jar is about to open.