For two years, the dominant interface to large language models was a text box. You typed, the model answered, and whatever happened next was your job: copy the code into your editor, run it, paste the error back. The model was an oracle. You were the hands.
An agent inverts that arrangement. The model gets the hands — tools it can call, files it can edit, commands it can run — and your job shifts from operating the model to directing it. That single inversion is responsible for most of what feels new in AI products since 2024, and most of what goes wrong in them too.
What an agent actually is
Strip away the marketing and an agent is a small thing:
An agent is a model running in a loop, with tools, working toward a goal, deciding for itself what to do next.
Each part of that sentence carries weight:
- A model in a loop. One model call is a completion. An agent calls the model repeatedly, feeding back the results of its own actions, until the goal is met or it gives up.
- With tools. Tools are how the model touches the world: search, file edits, shell commands, API calls. The tool list defines the agent's reach, and most of its risk.
- Toward a goal. The user states an outcome, not a procedure. "Fix the failing test" rather than "open the file, find line 40..."
- Deciding what to do next. This is the line between an agent and a workflow. A workflow's steps are fixed by the developer; an agent chooses its next step at runtime based on what it just observed.
That last distinction matters more than any other in this book. If you can draw the flowchart in advance, you do not need an agent — and you will get more reliability for less money by building the workflow directly. Agents earn their cost only when the path genuinely cannot be known ahead of time.
Why this works now
Three curves crossed to make agents practical:
- Models got good at tool use. Modern models reliably emit structured tool calls, recover from tool errors, and chain dozens of calls without losing the plot. This was not true of earlier generations, and every agent framework from that era carries scar tissue from working around it.
- Context windows grew. An agent's working memory is its context window. At 4k tokens, an agent forgets the file it read two steps ago. At 200k, it can hold a meaningful slice of a codebase, a conversation history, and its own scratchpad simultaneously.
- Inference got cheap enough to waste. An agent burns tokens on dead ends — reading files that turn out to be irrelevant, trying approaches that fail. When tokens were precious this was prohibitive. Now the economics tolerate exploration, and exploration is where agent value comes from.
The reliability gap
Here is the uncomfortable part. A model that is 95% reliable at a single step is roughly 60% reliable across ten chained steps. Agents chain dozens.
Everything hard about building agents lives in that gap, and the chapters ahead are mostly about closing it from different directions:
- Designing the loop so errors surface early and cheaply (chapter 2)
- Engineering what the model sees so each decision is made with the right information (chapter 3)
- Verification: giving the agent a way to check its own work, because an agent that can test its output converts open-ended generation into search against an oracle
The teams shipping agents successfully are not the ones with the cleverest prompts. They are the ones who treated the gap as the central engineering problem, instrumented everything, and made the agent's environment — its tools, its feedback, its guardrails — boringly excellent.
How to read this book
This is a living book. It versions like software: when the field moves or I learn something that changes a recommendation, I ship a revision, and the changelog tells you what changed and why. Read it linearly the first time. After that, interrogate it — ask the book how a chapter applies to the system you are building. That is not a gimmick; it is the thesis of the book applied to the book itself.