An AI agent is a system in which a language model decides the next action from what it observes, repeatedly, inside limits set by code. The model proposes; a harness you write executes, records and stops. One question governs everything else: what signal tells you it worked?
This guide covers the fundamentals every later topic leans on: the definition, the engine, the loop, the harness, and how agents plan and check themselves. It follows Parts I and II of AI Agents, Engineered. Chapter 1, “What Is an Agent?” and Chapter 2, “The Engine” are free to read online; Chapter 3, “The Agent Loop” and Chapter 4, “Planning, Reasoning, and Self-Correction” are in the full book. Every claim points to the chapter or source behind it.
What is an AI agent?
An AI agent is a language model placed in a loop, given a goal and a set of tools, that looks at the state of the task, picks an action, sees the result and goes again until the goal is met or a stopping rule ends the run. What is new is not the model’s fluency but where the control flow lives.
Practitioners have converged on a short version. Simon Willison’s formulation, “An LLM agent runs tools in a loop to achieve a goal,” has become widely shared shorthand, and he adds that the goal means “these are not infinite loops—there is a stopping condition” (Willison, 2025). The book adopts that sentence and then points at the part that matters for engineers: “What is genuinely new here is where the control flow lives.” That one change is why an agent can work through a task nobody scripted, and why it is slower, costlier and harder to test than ordinary code. The glossary entry for agent keeps the definition short.
Chapter 1 also hands you the instrument the whole book steers by, the compass: four bearings that reappear whenever a design choice comes up.
The first bearing, verifiability, is the book’s thesis: “an agent is only as trustworthy as the signal you can use to verify it.” The other three are the scarcity of context, compounding error, and the simplest thing that works. I run every agent proposal past all four, because each one kills a different bad idea.
Agent, workflow, or chatbot: who decides the next step?
A chatbot, a workflow and an agent can run on the same model; what separates them is who owns the next step. In a chatbot the human decides, one message at a time. In a workflow your code decides, along a route fixed in advance. In an agent the model decides, reacting to what it just observed.
The book’s litmus test works in design reviews: “If you can confidently draw the control-flow diagram before the request arrives, you are looking at a workflow.” If the diagram can only be drawn in hindsight, you are looking at an agent. The table summarizes Chapter 1’s distinction.
| Chatbot | Workflow | Agent | |
|---|---|---|---|
| Who decides the next step | The human | Your code | The model |
| Loop | None | Fixed path, drawn in advance | Open loop, path emerges at runtime |
| Executes actions | No | Yes, at steps you chose | Yes, at steps the model chooses |
| Worst failure | A wrong answer | A wrong output at a known step | A wrong action, with more actions built on it |
| How you test it | Read the replies | Test each step like code | Check outcomes; paths vary run to run |
| Cost profile | One call per turn | A known number of calls | Many calls, each re-reading a growing history |
Two refinements keep this from hardening into boxes. The real picture is an autonomy dial, and what moves along it is a single quantity: how much of the control flow the model owns. And the shape that ships most often, in the book’s words, is “a workflow shell with one or two genuinely agentic steps inside it.” The companion post on the one question that decides agents vs workflows works a full example through the rule; AI agent vs chatbot takes the other boundary.
What is agent-washing, and why does it cost money in both directions?
Agent-washing is relabeling a scripted pipeline, chatbot or automation as an “agent” because the word sells. It costs you in both directions: a workflow sold as an agent charges you for oversight it doesn’t need, and an agent sold as an automation skips the safeguards it does need.
The term is not only the book’s. In June 2025 Gartner described “agent washing” as “the rebranding of existing products, such as AI assistants, robotic process automation (RPA) and chatbots, without substantial agentic capabilities,” estimated that “only about 130 of the thousands of agentic AI vendors are real,” and predicted that over 40% of agentic AI projects will be canceled by the end of 2027 (Gartner, 2025). Those are a dated analyst forecast and estimate, not measurements.
The defense is the same litmus test, whatever the label says: does the model decide the next step, or does code? See the agent-washing glossary entry and the post What Is Agentic AI?.
How does the engine underneath actually work?
The engine of every agent is a large language model, which is a next-token predictor: given a stretch of text, it assigns a probability to every possible next token, one is drawn, appended, and the model runs again. It holds no plan in reserve, remembers nothing between calls, and writes by weighted lottery.
Building an agent takes four intuitions from Chapter 2, free to read. The first is that fluency and truth are correlated, not identical. When the model lacks a fact, it produces the most plausible-looking string where the fact should be, which is why the book compresses the engine’s priorities to “Fluent first, correct second.” That is the mechanism behind hallucination, and the reason the confident wrong answer sounds exactly like the confident right one.
The second is the context window, which the book pictures as a desk. Everything the model consults during one call (instructions, history, tool definitions, tool results, the answer it is writing) must fit on it at once: “There is no drawer, no shelf, no second desk.” The desk is swept bare between calls, so your code lays the whole transcript back on it every turn. Even what fits is used unevenly: material in the middle of a long input is recalled worse than material at the edges. The desk is the reason context engineering is a discipline of its own.
The third is sampling. “The picture to keep is a weighted lottery, run once per token,” and two identical requests can draw different tickets and part ways for good. Variability is designed in, which is why tests for agents assert properties of the output rather than exact strings.
How does a model turn text into action?
The fourth intuition answers it: the model acts by writing a request, never by acting itself. With structured output and function calling, it emits a machine-readable request instead of prose, your code runs the real function, and the result goes back to the model. In the book’s phrasing, “the model proposes; your code disposes.”
That diagram is the seed of every agent. Every side effect happens in code you wrote, where you can log it, restrict it or refuse it; the model’s entire contribution is a tool call, a data structure expressing a wish. And a guarantee about shape says nothing about truth: “A schema, misused, makes fabrication easier to consume, not rarer.” For the failure catalog, see Why Do AI Agents Hallucinate?
What is an agent loop?
An agent loop is the cycle at the center of every agent: the model reads the run’s history and chooses one next action, your code executes it and appends the result, and the cycle repeats until a stop condition fires. It fits on an index card, and the book claims every agent you have seen is built on it.
Each pass has four beats. Observe: lay the instructions, goal, history and latest result on the desk. Reason: one model call decides what happens next. Act: the decision arrives as a tool call or a final answer. Result: your code runs the tool and appends what came back, failures included. The model owns one beat out of four, so most of what can go wrong lives in code you can test. The book’s summary line: “you wrote the loop; the model writes the path.”
Two details carry most of the debugging value. The model is stateless, so the message history is the agent’s entire memory; drop an append and the model repeats itself. And interleaving short reasoning with each action, the pattern called ReAct, keeps every step tied to fresh evidence. The original paper found that this interleaving “overcomes issues of hallucination and error propagation prevalent in chain-of-thought reasoning by interacting with a simple Wikipedia API” on question answering and fact verification (Yao et al., 2022).
How does an agent loop stop?
The loop leaves by one of three exits, ranked by trust: a verified check a program can run, the model’s own judged “done,” and a capped budget on steps, tokens, time or money. The book’s rule: “The model’s ‘done’ is testimony; a green test is evidence.” The cap is not optional: “Set the cap before you write anything else.” A stop condition that only the model controls is no guaranteed exit at all.
The post What Is an Agent Loop? walks a five-pass trace beat by beat, and the three-minute agent loop explainer animates it. Stop conditions for agent loops covers budgets and error halts.
Why do agent errors compound?
Agent errors compound because whole-run success is roughly the product of per-step success rates: a task needing n steps, each succeeding with probability p, succeeds about pⁿ of the time. Small per-step failure rates become large whole-run failure rates, and in practice real agents do worse than the formula.
The book’s illustration: at 95% per step, twenty chained steps succeed about 36% of the time (0.95²⁰ ≈ 0.36). “Exponentials do not negotiate.” The multiplication is the optimistic case, because it assumes steps fail independently. They don’t: a mistake lands in the transcript and conditions every later step. Chapter 2’s conclusion is the one to keep: “Per-step accuracy is a ceiling, not a forecast.”
The levers are three: shrink the number of model-driven steps, raise effective per-step reliability by verifying each step, and checkpoint so a failure costs a phase instead of the run. The post on why agent errors compound covers the studies that measured the snowballing, and the compounding error calculator runs the arithmetic for your own step count.
Should I just use a framework?
Not to start. A framework adds plumbing around the loop (persistence, retries, tracing, memory management, multi-agent orchestration), and every item on that list is a harness part. None of it changes what the model does on a single pass, which is why, in the book’s words, “a framework can make an agent more dependable and cannot make it smarter.”
The rule follows the compass’s fourth bearing. Build the bare loop while you are learning or running one well-scoped task, and graduate when you hit a named pain: runs that must survive restarts, traces you actually need, histories that outgrow the desk. “Adopt for a named need, never for the feeling that serious systems use frameworks.” Agent frameworks (LangGraph and smolagents are two examples of the category) decompose into the same four parts.
The same reasoning applies one level up, to whether you need an agent at all. Chapter 1 frames it as a ladder: plain code, a single model call, a workflow, an agent. Stay on the lowest rung that solves the problem. Anthropic’s engineering essay makes the identical recommendation: “finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all” (Schluntz and Zhang, 2024). The Should this be an agent? tool puts your task on that ladder in ten questions.
What is an agent harness?
An agent harness is everything you build around the model to turn it into a working agent: the loop, the tool implementations and what they may touch, the care of the message history, the stop rules, and later the logging, recovery and guardrails. Chapter 3 puts it plainly: “An agent, in one line, is a model plus a harness.”
The minimal agent has exactly four parts. A model client sends the history and tool definitions to a stateless service. A set of tools, each a name, a description, an argument schema and the function that runs. The message history. And the loop that ties them together.
The figure draws the model outside the harness frame on purpose. The model is the judgment you rent; the harness is the part you own, test and debug. Since the loop itself is about ten lines, the difference between a demo and a dependable agent lives almost entirely in the harness, where each component prevents a named failure: a runaway loop, a forgotten tool result, a double-sent email.
How much harness you need scales with how long the system must live, how many people must trust its output, and how unattended it runs. The post What Is an Agent Harness? follows one ticket-triage agent from week one to month six; the AI agent architecture guide maps the parts at reference depth. The complete minimal program, in annotated pseudocode, is in Appendix A (in the full book).
How do agents plan and correct themselves?
Agents plan by decomposing a goal into steps, either all at once up front or one step per pass, and they improve a single step by reasoning in writing before answering. They correct themselves reliably only when the error signal comes from outside the model, such as a failing test or a validator.
Chapter 4 sets the two planning shapes against each other. A plan written before the first observation is a guess about a world the model has not seen; Chapter 3 says of the blind plan-then-execute design, “The design concentrates all of its judgment at the point of maximum ignorance.” An interleaved loop adapts at every step but never holds the whole task in view, so it wanders. The mature arrangement keeps an explicit, written plan inside a loop that still observes and replans: “plan globally, revise locally.”
Reasoning techniques work for a mechanical reason. The model spends roughly the same computation per token, so the only way to give a hard question more thought is to let it write intermediate steps first: “Thinking, for a language model, is writing.” That is why chain-of-thought helps on multi-step tasks, and why a trace is a map of places to dig, not a proof.
Can an agent correct its own mistakes?
Rarely on its own, and reliably once something outside the model locates the error. Asked to review their own answers without outside feedback, models often get worse. Huang and colleagues found that models “struggle to self-correct their responses without external feedback, and at times, their performance even degrades after self-correction” (Huang et al., 2023). Yet a separate study the book cites, by Tyen and colleagues, found that models which cannot find their reasoning errors correct them well once told where the error is.
Hence the sign the rest of the book points back to: “A real verifier beats the model grading itself.” A verifier, or oracle, exercises the work instead of contemplating it: the test suite runs, the schema validator takes the output apart, the query executes or fails. The division of labor writes itself: “let the world find; let the model fix.”
Worked example: does a dependency-update job need an agent?
Here is how the fundamentals combine into one design decision. The task, invented for illustration, comes from a platform team: “keep our service’s dependencies current and open a pull request each week.”
Climb the ladder first. Listing outdated packages is plain code; the package manager already reports them. Bumping versions, running the test suite and opening the pull request are fixed steps you can draw in advance, so they form a workflow with no model at all. One step resists the flowchart: when a bump breaks the build, the fix depends on what the failure says. That juncture is genuinely agentic, and it is the only place the model should own the control flow.
Check the compass. Verifiability is excellent: the test suite is a verified exit, so the loop ends on “tests pass,” not on the model’s word. Context is manageable if the harness feeds back the failing test and the relevant diff, not the whole repository. Simplicity says keep the agent inside the workflow shell rather than letting it run the whole job.
Do the arithmetic. Suppose, purely as an illustration, that each model-driven step succeeds 95% of the time. An agent that ran the whole job in twelve unverified steps would succeed about 54% of the time (0.95¹² ≈ 0.54). Confine the agent to a four-step repair loop and it starts at about 81% (0.95⁴ ≈ 0.81), and the test run after each edit catches failures before they compound. Shrinking n and verifying each step are two of the three levers from Chapter 2.
How much harness does the repair loop need?
A small one, sized to the risk. The repair loop needs a step cap, a token budget, tools that can read files, edit files and run tests (no network, no write access outside the branch), and a rule that a capped run opens a draft pull request labeled “stopped, not finished” with the transcript attached. A human reviews every pull request.
| Part of the job | Rung on the ladder | Who decides the next step | Exit |
|---|---|---|---|
| List outdated packages | Plain code | Your code | Command completes |
| Bump versions, run tests | Workflow | Your code | Test results recorded |
| Repair a broken build | Agent (bounded loop) | The model | Tests pass, or the cap fires |
| Open the pull request | Workflow | Your code | Human approves or rejects |
The result is a workflow shell with one agentic step inside it, which is the shape Chapter 1 predicts most production systems take. The agent cost-per-task estimator will price the repair loop, including the history it re-reads on every pass.
Where does each idea live in the book and on this site?
Each concept has one chapter where the book defends it and, usually, one page here that works it through.
| Concept | Chapter | Go deeper | Glossary |
|---|---|---|---|
| Agent, workflow, chatbot | Chapter 1 (free) | Agents vs workflows decision rule | workflow |
| Agent-washing and the ladder | Chapter 1 (free) | Should this be an agent? | agent-washing |
| Tokens, the desk, sampling | Chapter 2 (free) | Why do AI agents hallucinate? | token |
| Compounding error | Chapter 2 (free) | Why agent errors compound · calculator | the compass |
| The loop, ReAct, three exits | Chapter 3 | What is an agent loop? · explainer | stop condition |
| The harness, four parts | Chapter 3 | What is an agent harness? | harness |
| Building one from scratch | Appendix A | Build an AI agent from scratch | augmented LLM |
| Planning, reasoning, verifiers | Chapter 4 | What is the ReAct agent pattern? | chain-of-thought |
What are the limits of these fundamentals?
These fundamentals describe the shape of every agent, but they do not make any particular agent reliable, and some of the numbers behind them will age. The arithmetic, the control-flow distinction and the asymmetry between self-review and outside verification are durable; the specific percentages are dated snapshots.
Three limits apply. First, pⁿ is a model, not a law: when steps are verified and retried, or when an error is harmless to later steps, real runs can beat it, and the book treats it as a way to reason about design rather than a forecast. Second, the self-correction studies were run on the models of their day; models may get better at spotting their own slips, though a measurement will still beat an opinion where a measurement exists. Third, the definitions here are working definitions for engineers. Outside engineering, “agent” often means an autonomous employee, so ask which meaning a speaker intends.
The one question to keep
Remember one thing, the compass’s first bearing: before trusting any agent, ask what signal tells you it worked. An agent, in the book’s words, “is a cost you pay for adaptability you can name. If you cannot name the adaptability, keep your money.”
The best next step costs nothing. Read Chapter 1 free, then Chapter 2, and when you want the loop, the harness and the planning chapters, see the formats.
The chapters behind this guide
- Chapter 1: What Is an Agent? Free
- Chapter 2: The Engine: How Language Models Work Free
- Chapter 3: The Agent Loop In the full book
- Chapter 4: Planning, Reasoning, and Self-Correction In the full book
Tools and explainers for this topic
Tool
Agent cost-per-task estimator
Estimate what one agent run costs in tokens: the fixed prompt, the history it re-reads every step, retries and subagents. Free AI agent cost estimator.
Tool
Compounding error calculator
A free compounding error calculator for AI agents: whole-run success from per-step reliability, and the reliability a long task needs.
Tool
Should this be an agent?
When to use AI agents, and when plain code, one model call or a workflow does the job better. Answer ten questions and see where your task sits on the ladder.
Explainer · 3 min
The agent loop: four beats and three exits
A three-minute animated explainer of the agent loop: the four beats of every pass, the history that is the agent's only memory, and three exits ranked by trust.
Articles in this cluster
14 min
Agents vs Workflows: One Question Decides Which You Need
Agents vs workflows comes down to one question: who decides the next step, your code or the model? Learn the rule, then read Chapter 1 free.
14 min
What Is an Agent Harness? The Part You Actually Build
What is an agent harness? The loop, tools, history, stop rules and recovery around the model, what breaks without each, and when to adopt a framework.
12 min
What Is an Agent Loop? The Cycle Every Agent Runs
What is an agent loop? The four beats every agent repeats, how ReAct fits, and the three exits ranked by trust, with a worked trace. Read the walkthrough.
12 min
Compounding Errors in AI Agents: Why Small Mistakes Snowball
Compounding errors in AI agents are worse than pⁿ: self-conditioning, snowballing and correlated errors. See the evidence and the redesign that fixes it.
Questions readers ask
- Is an LLM an agent?
- No. A large language model on its own is a function that predicts the next token of text; it executes nothing and remembers nothing between calls. It becomes part of an agent when code places it in a loop, gives it tools it can request, keeps the history of what happened, and decides when to stop.
- What is the difference between an AI agent and a workflow?
- In a workflow, your code decides which step runs next, along paths drawn before any request arrives; the model only fills in content at each step. In an agent, the model decides the next step at runtime from what it just observed. If you can draw the flowchart in advance, you have a workflow.
- Do I need a framework to build an AI agent?
- No. The core loop is about ten lines of ordinary code. Frameworks add plumbing such as persistence, retries, tracing and multi-agent orchestration. Adopt one when you hit a concrete need you would otherwise build yourself, not because serious systems are expected to use one.
- Why does my agent fail after working 99 times?
- Because an agent samples its output and chains many steps, small per-step failure rates multiply into large whole-run failure rates, and a mistake written into the history makes later mistakes more likely. Verifying steps against an outside check and capping the run do more for reliability than rewording the prompt.
- How much math do I need to understand AI agents?
- Arithmetic is enough. The book explains the engine, the loop and compounding error with intuition, worked examples and one multiplication, p to the power n. No training, calculus or linear algebra is required to build and evaluate an agent well.