Table of Contents
1. From LLM to Agent — What's the Difference?
Chapter 1 was entirely about a plain LLM: you give it text, it predicts and returns text, and it's done. It never checked whether its chocolate cake recipe was actually correct, never tasted the batter, never opened the oven to see if the cake was really done. It just described a plausible process, in one shot, from memory-like statistical patterns.
An agent is what you get when you take that same LLM and put it in a loop with tools and a goal, instead of asking for one response and stopping. The LLM is still the reasoning core — still predicting tokens the same way, with the same inconsistency risks from Chapter 1 — but now it's being used to decide what to do next, not just what to say, and it can check its own work against reality along the way.
- Plain LLM: "How do I make a chocolate cake?" → describes a recipe from learned patterns. It never finds out if the cake actually turns out well.
- Agent: "Make me a chocolate cake." → writes a plan, checks what's actually in the pantry (a tool call), adjusts the recipe, follows the steps, checks the batter, bakes it, does a toothpick test at 25 minutes, and keeps going until the cake is actually, verifiably done — or reports back that it couldn't finish and why.
Claude Code is a real-world example: it doesn't just describe what code to write, it reads your actual files, writes the actual edit, runs your actual test suite, reads the actual failure output, and loops until the tests actually pass. That loop — plan, act, observe, adjust, repeat — is what turns a text predictor into an agent.
2. The Basic Architecture of an Agent
| Component | What it does |
|---|---|
| Goal / instructions | The task the agent is trying to accomplish — a user request, plus whatever system-level instructions shape its behavior. |
| Perception / context | What the agent currently "sees": the conversation so far, file contents it has read, results from tools it has already called. |
| Reasoning core (the LLM) | The same next-token-prediction engine from Chapter 1, now used to decide the next step — which tool to call, what to write, when to stop. |
| Tools / actions | Functions the agent can actually invoke to affect or query the real world: read a file, edit a file, run a shell command, run tests, search the web, call an API. |
| Memory / state | Short-term (what fits in the current context window) and sometimes longer-term (notes, task lists, a persisted store) tracking of what's been done and what's left. |
| Orchestration loop | The control flow that repeatedly asks the reasoning core "what next?", executes the chosen action, feeds the result back in, and checks whether the goal is met. |
| Stopping condition | The logic that decides the agent is done — task complete, a safety/iteration limit reached, or an explicit decision to give up and report back. |
This loop is often called the agent loop (or, in the research literature, a "ReAct" pattern — Reason and Act, interleaved):
┌──────────────────────────────┐
│ Goal: "Fix the failing │
│ test in checkout.js" │
└──────────────┬───────────────┘
▼
┌───────────▶ ┌──────────────────────────────┐
│ │ THINK │
│ │ LLM reasons: "I should read │
│ │ checkout.js and the failing │
│ │ test first." │
│ └──────────────┬───────────────┘
│ ▼
│ ┌──────────────────────────────┐
│ │ ACT │
│ │ Calls a tool: read_file(), │
│ │ run_tests(), edit_file()... │
│ └──────────────┬───────────────┘
│ ▼
│ ┌──────────────────────────────┐
└──────────────│ OBSERVE │
│ Tool result (file contents, │
│ test output) added to context│
└──────────────┬───────────────┘
▼
Goal actually achieved? ──No──▶ back to THINK
│
Yes
▼
Report result and stopNotice what's different from Chapter 1's flow: the LLM is no longer just predicting the next word of a final answer — at each turn of this loop it's predicting the next action, and then that action's real-world result gets fed back in as new, grounded information for the next round of thinking. That grounding step — checking against something real instead of just continuing to predict — is the single biggest architectural difference between an LLM and an agent.
3. Smart Agent vs. Not-So-Smart Agent
Two agents can be built on the exact same underlying LLM and still perform very differently, because "smart" is mostly a property of the architecture around the LLM — how it uses tools, plans, checks its own work, and recovers from mistakes — not just the raw capability of the model doing the predicting.
| Trait | Not-so-smart agent | Smart agent |
|---|---|---|
| Tool use | Guesses at facts or output from memory instead of checking. | Grounds itself in reality — actually runs the code, reads the actual file, checks the actual test result. |
| Planning | Attempts the whole task in one big leap. | Breaks the task into smaller, independently checkable steps. |
| Verification | Declares "done" the moment it produces an answer. | Checks its own work — reruns tests, re-reads the diff — before declaring done. |
| Error handling | Repeats a failing action unchanged, or claims success anyway. | Notices the failure signal and adapts its approach. |
| Memory over a long task | Loses track of the original goal or constraints as the loop grows long. | Actively re-grounds itself in the original goal at each step. |
| Confidence calibration | Always produces a confident-sounding answer, even when uncertain. | Recognizes genuine uncertainty and flags it, or asks a clarifying question. |
The grounding vs. guessing distinction is the one worth sitting with, because it connects directly back to Chapter 1. A plain LLM predicting "this loop will run correctly" is making a probabilistic guess based on learned patterns — exactly the same kind of guess that produced two different chocolate cake recipes on two different runs. An agent that instead executes the code and reads the actual output has swapped a guess for a fact.
This is also why it's a category error to evaluate "the model" in isolation and assume that tells you how good "the agent" is. A highly capable model wrapped in a not-so-smart loop — no verification, no grounding, no error recovery — will still produce unreliable results. You have to evaluate the whole system: model plus architecture plus tools.
4. If There's No Single "Correct" Answer, How Do You Evaluate Agent Output?
Here's the direct answer: you stop trying to check whether the output matches one specific correct answer, and instead check whether it has the properties a good answer would have. There's no one "correct" chocolate cake recipe to match word for word — but there absolutely are checkable properties a good recipe has: it includes a leavening agent, the oven temperature is safe, the ratios are sound, the steps are in a workable order. Every eval method below is a variation on that idea.
Method 1 — Execution-based / ground-truth checks
Some parts of a task do have an objective, checkable answer even when the surrounding explanation doesn't. If you ask an agent to predict what a specific test case will output, there is exactly one real, verifiable answer — even though the agent's wording of the explanation can vary infinitely. This is the golden-dataset approach: don't grade the prose, grade the checkable prediction against the verified real output. It's the strongest, least ambiguous signal available.
Method 2 — Rubric-based / criteria scoring
For parts of a task that genuinely don't reduce to a single checkable fact — like a full code review — define the properties a good answer must have, and score against each one independently:
| Criterion | What it checks |
|---|---|
| Correctness | Did it correctly identify the real, known-injected bugs? |
| Completeness | Did it miss any of them? |
| False-positive rate | Did it flag things that aren't actually bugs? |
| Actionability | Are the recommendations specific and fixable, not vague? |
| Consistency | Does it produce the same core findings across repeated runs? (Chapter 1) |
Method 3 — LLM-as-judge
For dimensions that are hard to check with a fixed rule but that a careful reviewer could still recognize — clarity, tone, whether an explanation actually addresses the question — a separate LLM call can grade the output against the rubric, or compare two candidate answers. This scales far beyond a purely human review process, though it inherits its own version of the consistency problem from Chapter 1 and needs the same discipline (pinned model version, low temperature, structured scoring format) to be trustworthy.
Method 4 — Pairwise / preference comparison
Instead of asking "is this answer good, in isolation" — a hard absolute judgment — ask "is this answer better or worse than that one." Humans and LLM judges are both measurably more reliable at relative comparisons than absolute scores, and a preference judgment never requires a single correct reference to exist at all.
Method 5 — Self-consistency as a scored dimension, not a nuisance
Chapter 1 covered running the same task multiple times and checking whether findings agree across runs. In an eval context, that agreement rate isn't just a mitigation — it's a metric in its own right. An agent that finds the same real bug in 5 out of 5 runs is more trustworthy than one that finds it in 2 out of 5, even if both technically "found the bug" at least once.
Method 6 — Human spot audits, to calibrate everything above
None of the automated methods above are trustworthy by default — a rubric can be miscalibrated, an LLM judge can be systematically too lenient or too harsh, execution checks can miss the point of the task. Periodically sampling a subset of outputs for real human review is what keeps the rest of the system honest over time.
Putting it together
In practice, a real eval doesn't pick just one of these — it layers them. For the "analyze this 100-line JavaScript file" example from Chapter 1: the specific, known bugs that were deliberately injected into the golden dataset get checked with execution-based/ground-truth scoring. The quality of the explanation around each finding gets scored with a rubric. Whether the agent's overall review is better than a previous agent version's review might use a pairwise comparison. And running the whole thing several times and checking agreement measures consistency as its own signal. No single one of these needs — or assumes — that there was ever one "correct" review to match against.
5. Key Takeaways
- An agent is an LLM wrapped in a loop with tools, memory, and a goal — the LLM decides the next action, not just the next word, and real tool results get fed back in as grounded information.
- The core architectural pieces are the same across most agents: goal, perception/context, the LLM reasoning core, tools, memory/state, an orchestration loop, and a stopping condition.
- The biggest difference between a smart and a not-so-smart agent is architecture, not raw model power: grounding claims in real tool results instead of guessing, planning in checkable steps, verifying its own work, recovering from errors, and knowing when to flag uncertainty.
- Because two agents on the same model can perform very differently, evals must test the whole system — model plus loop plus tools — not just the underlying LLM.
- With no single correct answer to compare against, evaluation shifts from "does this match the one right answer" to "does this have the properties a good answer would have" — checked via execution-based ground truth, rubric scoring, LLM-as-judge, pairwise comparison, self-consistency, and human spot audits, layered together.
6. Glossary
| Term | Meaning |
|---|---|
| Agent | An LLM operating inside a loop with tools, memory, and a goal, able to take actions and use their real results to decide what to do next. |
| Agent loop / ReAct pattern | The repeating think → act → observe cycle an agent runs until its goal is met or it stops. |
| Grounding | Checking a claim against a real, verifiable result (e.g., actually running code) instead of relying on the model's prediction of what's likely true. |
| Tool | A function an agent can call to affect or query the real world — read/edit a file, run a command, call an API. |
| Rubric | A checklist of properties/criteria a good answer should have, scored independently rather than as one pass/fail verdict. |
| LLM-as-judge | Using a (typically separate) LLM call to score or compare candidate outputs against a rubric or against each other. |
| Pairwise / preference comparison | Judging which of two candidate outputs is better, rather than scoring either in isolation. |
| Execution-based evaluation | Scoring an answer by checking a real, verifiable outcome rather than comparing wording. |
This is Chapter 2 in the Eval Basics series. The next chapter moves from theory to practice: how do you actually design a Golden Dataset — the concrete tasks, test cases, and verified answers an eval framework runs an agent against? — continue to Chapter 3: Building a Golden Dataset (Worked Example) →