Part 1 — Foundations

You can code. You have probably called a language model API, wired it into something, and watched it do something impressive and then something stupid. What you have not done yet is ship an agent that other people depend on.

That is the gap this book closes, and Part 1 is where we lay the slab.

What “foundations” means here

Foundations does not mean theory. It means the small number of ideas that, once you actually hold them, make every framework you touch afterwards read like a variation on something you already understand.

There are four of them, and they get one chapter each.

Chapter 1 — Agents vs workflows. The word “agent” has been stretched until it means nothing. We fix that with a working definition you can apply to your own systems: an agent is a language model in a loop, with tools, pursuing a goal it was not given step-by-step instructions for. Then we do the harder and more useful thing, which is establishing when you should not build one. Most of the systems being marketed as agents in 2026 would be cheaper, faster, and more reliable as ordinary workflows, and knowing how to tell the difference will save you more money than any optimization you learn later.

Chapter 2 — The five levels. A capability ladder, running from a bare reasoning model with no connection to the world (Level 0) up to a system that writes its own tools (Level 4). We take a single product idea and walk it up every rung, so you can see exactly what each level buys you and exactly what it costs. The cost side is the part people skip. Each level up roughly doubles the surface area you have to test, trace, secure, and explain to whoever is on call.

Chapter 3 — Model, tools, orchestration. The anatomy underneath every agent, whether it was built with a framework or duct tape. The model reasons. The tools act. The orchestration layer runs the loop, holds the state, and enforces the limits. We go deep on the tool distinction that matters most for safety — tools that read the world versus tools that change it — and on the two levers you have for steering the model: the instructions you give it and the context you assemble for it.

Chapter 4 — Build a ReAct agent from scratch. No framework. Roughly two hundred lines of Python you type yourself. You will build the think/act/observe loop, a tool registry, prompt construction, tool-call parsing, observation feedback, a step cap, and error handling — adding each piece only after you have watched the previous version fail without it.

Why build it by hand first

You are going to use a framework eventually. Part 3 of this book will put you in one. Frameworks are genuinely good now — they handle retries, streaming, tracing, session persistence, and a hundred details you do not want to reimplement.

But a framework’s job is to hide the loop, and if the loop is hidden before you have ever seen it, every bug becomes magic. Your agent calls the same tool eleven times in a row and you have no model of why that could happen. Your token bill triples overnight and you cannot point at the line that did it. Your agent confidently reports a delivery date it never looked up and you do not know whether that is a prompting problem, a tool-description problem, or a context problem.

Engineers who built the loop by hand once diagnose these in minutes. Engineers who started at the framework layer file a GitHub issue.

There is a second reason, less obvious and more important. Writing an agent by hand teaches you that the model is not the interesting part of an agent. The interesting part is everything around it: what you put in the context window, what you let it call, what you do when it calls something wrong, and when you stop it. That reframing is the whole book in one sentence, and it is much easier to believe after you have written the code than after reading someone assert it.

What you will have at the end of Part 1

A running agent. Not a diagram of one. An actual Python file you can execute right now, with an offline mock mode so it works before you have an API key and a real client you can swap in when you do.

Concretely, by the end of Chapter 4 you will have:

• A tool registry that turns plain Python functions into model-callable tools with JSON Schema contracts.
• A think/act/observe loop that runs until the model produces a final answer or hits a hard step cap.
• Error handling that converts every possible tool failure — unknown tool, wrong arguments, thrown exception — into an observation the model can read and recover from, instead of a stack trace that kills the run.
• A trace you can read line by line, showing every thought, every tool call, and every observation.

And you will have a clear-eyed list of what that agent still gets wrong, which is what the rest of the book is for.

How to read this part

Read Chapters 1 through 3 with a text editor open but idle. They are conceptual, and they are short.

Read Chapter 4 with a terminal open and your hands on the keyboard. Type the code; do not paste it. Run each version before you read why it is broken. The failures are the lesson.

One convention note: this book puts one sentence per line in its source. It renders identically to normal prose. It just makes the diffs readable when the book gets revised, which it will.