Express course · No. 10

An agent is a language model put in a loop: reason, act, observe, repeat — until a goal is met. That loop is astonishing and, left alone, works only about half the time. The skill isn't a smarter model. It's engineering the chain — the steps, the context, the tools, the limits — so the loop is something you can trust.

27 concepts · a diagram for each · cheat sheet at the end

§ 01

Before you build one, get the definition exact — because an agent is a specific, narrow thing, and most of the trouble comes from reaching for it when you didn't need it.

The map: 27 concepts in seven groups

A subway map: first you see the whole lines, then you ride station by station.

The course runs through seven groups. First — what an agent is. Then — why it's unreliable by default. Then four groups of levers that win the reliability back: context, tools, orchestration, and the leash (control). And finally — evals and shipping: how you know any of it actually works.

Seven groups of concepts — chapters 1–7 follow them.

How to read each concept

A passport: the same fields for everyone, so they're easy to compare.

Every concept below has the same shape: its English name (remember it — that's what docs and papers call it), a picture from life, a diagram, and a card with fields: problem, idea, example, cost, when to use, and related. The one idea behind the whole course: an agent's reliability isn't a property of the model — it's what you build around it.

Agent Loop — a model in a loop, not a single answer

A person fixing a leak: try something, look at what happened, adjust, try again — not one perfect move, but a cycle of action and feedback until it's done.

A plain LLM call takes input and returns text, once. An agent wraps the model in a loop — that's the Agent Loop: the model reasons about the goal (reason), takes an action (act — calls a tool), observes the result (observe), and reasons again. The model decides each next step itself. That loop is what lets it handle open-ended tasks no single prompt could finish.

Agent Loop: reason → act → observe → reason again, until the goal is met or a limit trips.

ConceptAgent Loop· reason–act–observe

Problem: A single model call can't finish an open-ended task: it has nothing to lean on but the first input.
Idea: Run the model in a loop: reasoning → action through a tool → observe the result → next decision.
Example: "Investigate this bug and propose a fix": read the log, open the file, run the test, patch, run again.
Cost: Every turn is a chance to go wrong; a loop is pricier and slower than one call.
When to use: When the path to the goal can't be scripted in advance.
Related: Made of the parts in Agent Anatomy; bounded by Loop Limits.

Agent Anatomy — four parts: model, tools, memory, loop

A handyman is more than a brain — they have tools in the van, a notebook of what they've done, and the habit of working a job step by step.

An agent is four things together: a model to reason, tools to act on the world, memory to carry state across steps, and a loop that drives it until the goal is met or a limit stops it. Take away the loop and you have a chatbot; take away the tools and it can only talk. The power — and the risk — lives in the combination.

Agent = model + tools + memory + loop. Remove one part and you get something else.

ConceptAgent Anatomy· the four parts

What it is: Four parts: model, tools, memory, loop.
Why it matters: Each part is a separate reliability lever: the course takes them in turn (chapter 3 — memory, 4 — tools, 5–6 — the loop).
Example: A support agent: the model reads the ticket, the search_orders tool finds the order, memory holds the conversation, the loop runs until the customer gets an answer.
Catch: Everyone watches the model — but what breaks more often is around it: memory, tools, the loop.
Related: Context Window and External Memory are the memory; Tool Use is the tools.

Autonomy — the whole point and the whole danger

The difference between an assistant who asks before every move and one you hand a goal and walk away from. The second is far more useful and far easier to regret.

Autonomy is the agent deciding for itself how to reach a goal, across many steps, without you in the loop each time. That's what makes it valuable. And the same autonomy is exactly what makes it risky: it can take a wrong turn, act on a bad assumption, and keep going. Everything else in this course is about getting the value of autonomy without paying full price for the danger.

The more the agent decides alone, the more value and the more danger. The target is the middle: gated autonomy.

ConceptAutonomy· how much it decides alone

What it is: How many decisions the agent makes without a human — from "asks every move" to "hand it a goal and walk away".
Upside: The agent carries multi-step work while you do something else.
Downside: A wrong turn doesn't stop itself — the agent confidently keeps going.
How to hold it: Limits, gates on the irreversible, monitoring and logs — chapter 6 is all about this.
Related: Managed through Human-in-the-loop and Human-on-the-loop.

Agent vs Workflow — most tasks don't need an agent

You don't hire a general contractor to hang one picture. A screwdriver does it faster, cheaper, and with nothing to go wrong.

An agent is the heaviest tool in the box. A single prompt, structured output, or a workflow — a fixed sequence of calls — is cheaper, faster, and far more predictable. Reach for an agent only when the task genuinely needs many adaptive steps the path of which you can't script in advance. If you can write the steps down, write the steps down — don't make a loop guess them.

The key question: can you write the steps down in advance? Yes — use a prompt or a chain. No — then an agent.

PracticeAgent vs Workflow· agent or fixed chain

Problem: Agents get picked because they're fashionable, when one call would do.
Idea: Check first: can you write the steps down? If yes — a workflow; an agent only for an adaptive path.
Example: "Extract fields from an invoice" — one call with structured output. "Investigate an incident from the logs" — an agent.
Cost of getting it wrong: An agent where a chain would do — extra money, latency, and new ways to break.
Related: Grows into the Complexity Ladder and Fixed Chain (chapter 5).

An agent is a model in a loop with tools and memory. The loop is the power, the autonomy is the risk, and most tasks need neither.

§ 02

Here's the fact that should shape everything: a typical production agent succeeds only a little more than half the time. Understand why, and you understand what you're actually building.

Demo vs Production — the demo works; the job is the rest

A car that starts perfectly in the showroom tells you nothing about whether it survives a winter of real driving. The showroom is the easy part.

In a 2026 study across thousands of production agents, the aggregate success rate was about 57% — and benchmark scores ran roughly a third higher than real-world results. That's the demo-to-production gap. The demo runs the happy path: clean input, a task it was shaped for. Production is everything the demo filtered out. The demo is free; the reliability is the entire job.

Benchmarks run roughly a third above reality; in production it's about 57%. The gap is everything the demo didn't show.

TermDemo-to-Production Gap· demo vs real work

What it is: An agent shines in the demo and on benchmarks, but succeeds only ~57% of the time on real work.
Why: The demo runs the happy path; production brings messy input, rare cases, and long chains.
Example: An agent books a table perfectly on the test site — and gets lost when a restaurant has a different form.
What to do: Measure on real tasks, not demos. Treat reliability as the main job.
Related: Explained by Compounding Errors and Silent Failures; treated with Step-level Evals.

Compounding Errors — chains multiply

A relay race where each runner is 97% reliable — but with twenty handoffs, the baton hits the ground almost as often as it arrives.

Agents work in long chains — a real task can be twenty dependent steps. Reliability multiplies down a chain — that's compounding errors: twenty steps at 97% each lands you near 54%. No single "stupid" mistake is needed; the arithmetic alone drags you to a coin flip. The first lever on reliability is making the chain shorter.

97% per step sounds great. But 20 steps in a row is about 54% — nearly a coin flip.

ConceptCompounding Errors· errors multiply down a chain

Problem: Every step is a little unreliable, and there are many steps.
Mechanics: Probabilities multiply: 0.97²⁰ ≈ 0.54. A long chain drags itself toward a coin flip.
Example: A report agent: find, read, extract, cross-check, combine… — twenty steps, each able to slip a little.
What to do: Cut the number of steps: Fixed Chain for the predictable, Plan-and-Execute for a shorter reasoning chain.
Related: The main cause of the Demo-to-Production Gap.

Silent Failures — the worst errors hide behind a clean answer

A report that's beautifully formatted and confidently wrong — every heading in place, one key number quietly incorrect three pages back.

In a multi-step task, an intermediate mistake can pass a final-output check while corrupting the result — a silent failure. A research agent retrieves the right source, misattributes one fact in step three, and writes a clean summary that's wrong. The final answer looked fine; the middle was broken. This is the failure mode you'll catch least and pay for most.

An error in step 3 rides through to an answer that looks clean — a final-only check never sees it.

ConceptSilent Failure· wrong middle, clean answer

Problem: The answer looks right, but the middle of the path was broken.
Why it's dangerous: A final-output check waves it through; it gets found late — by customers or an audit.
Example: The agent found the right source but attributed a quote to the wrong author — the summary is smooth and wrong.
What to do: Check the intermediate steps, not just the end, and log every step.
Related: Caught by Step-level Evals; investigated through the Audit Trail.

Reliability by Design — engineered, not prompted

A bridge doesn't hold because the steel is clever. It holds because someone engineered the loads, the joints, and the margins.

You don't fix the 57% with a better prompt or a smarter model. You engineer it: fewer steps, the right context at each one, scoped tools, checks on the intermediate results, and limits on what a wrong turn can do. The model is the raw material; the reliability is what you build around it. That work is the rest of this course.

Five levers around the model: short chain, right context, scoped tools, step checks, limits.

PrincipleReliability by Design· engineering, not prompting

Idea: Reliability is a property of the system around the model, not of the model.
Levers: Short chain (ch. 5), context (ch. 3), scoped tools (ch. 4), step checks (ch. 7), limits (ch. 6).
Example: Instead of "let's use a bigger model" — remove five needless steps and add a check after data extraction.
Catch: The urge to fix everything with the prompt: it feels like progress, but it doesn't change the chain's arithmetic.
Related: Ties together chapters 3–7.

A typical agent works about half the time. That number isn't a model problem — it's an engineering problem, and it's yours to solve.

§ 03

An agent's working memory is just the text in the window, and across a long task that window fills with noise. Managing it — not enlarging it — is what keeps an agent coherent.

Context Window — the only working memory

A brilliant investigator who forgets everything each morning and can only act on the notes pinned to the board in front of them.

Between steps, the model remembers nothing except what's in the context window right now. The running goal, what's been tried, the last tool's output — if it's not in the window, it's gone. So an agent's competence at step ten is decided by what you chose to keep in front of it, not by how smart the model is.

The model sees only what's in the window: the goal, what was tried, the last output. Nothing else exists for it.

TermContext Window· what the model sees now

What it is: All the text the model sees at the current step. It has no other memory between steps.
Consequence: Step quality is decided not by the model's smarts but by what you put in the window.
Example: If the search_orders output didn't make it into the window, next step the agent "doesn't know" it already found the order — and searches again.
Catch: The window is finite, and it collects junk — see Context Drift.
Related: Managed by Context Compression; extended outward by External Memory.

Context Drift — what actually kills long tasks

A game of telephone down a long line — by the end, the message has quietly mutated, and everyone is confidently repeating something slightly wrong.

The dominant failure in long-running agents isn't a dumb model — it's context drift: across many steps the window accumulates stale facts, half-finished reasoning, and contradictions, and the original goal slides out of focus. A bigger window makes this worse, not better — it gives the drift more room. The fix is hygiene, not capacity.

With every step the window holds more stale and contradictory text, and the goal shrinks to a sliver.

ConceptContext Drift· the goal slides out of focus

Problem: The window fills with stale facts and contradictions; the goal falls out of focus.
Symptom: At step thirty the agent is doing something sensible — just not what it was asked to do.
Example: The agent fixes a bug, finds three others along the way, and ends up rewriting the module instead of one fix.
Trap: "Let's get a bigger window" — the drift just gets more room.
Related: Treated by Context Compression and re-anchoring the goal.

Context Compression — curate and compress as you go

A good editor doesn't add pages — they cut. At each step they hand you the one page that matters now, not the growing stack of everything so far.

Reliable agents actively manage the window — that's context compression: keep only what this step needs, summarise finished steps into a short running state instead of dragging the full transcript forward, and re-anchor the goal each turn. The model carries the conclusion, not the raw history. Relevance beats completeness, every step.

A long transcript collapses into a short state; the next step sees the goal, that state, and the current input.

PracticeContext Compression· curate the window

Problem: The whole transcript is dragged into the window every step — noise grows.
Idea: Finished steps → a short summary; the goal restated at the start of each step; the rest dropped.
Example: Instead of ten full search outputs — one line: "found 3 orders, the right one is #42, status: delivered".
Cost: A summary can lose an important detail — decide what to keep verbatim.
Related: The main cure for Context Drift; details go to External Memory.

External Memory — memory lives outside the window

A long project needs a filing cabinet, not a bigger desk — you store what matters elsewhere and pull back only the folder you need right now.

Because the window is finite, durable external memory lives outside it: notes, summaries, and retrievable history in a store, fetched back in when relevant (the same retrieval idea as RAG). This is what lets an agent work across a task too big to hold at once — and what stops it forgetting the beginning by the end.

The window is small and lives for one step; the store is big. The agent writes notes there and pulls back only what it needs.

PatternExternal Memory· a store outside the window

Problem: The task is bigger than fits in the window.
Idea: Keep notes and history in a separate store; at each step pull in only what's relevant.
Example: A research agent writes its findings per source into notes, and an hour later pulls them back for the final report.
Cost: One more system: what to write, how to search, when to forget.
Related: Same mechanics as RAG; complements Context Compression.

An agent is only as coherent as its window. The biggest context window doesn't win — the best-managed one does.

§ 04

Tools are how an agent reaches past text to actually do things. They're also where it gets hands — which is exactly why they need to be scoped, described, and trusted carefully.

Tool Use — the model asks, your code acts

A smart assistant who can't open the filing cabinet themselves — but can tell you precisely which drawer and file to pull, and read what you bring back.

With tool use (also called function calling), you describe functions the model may request — search_orders, send_email, run_query — and when it wants one, it returns a structured call, your code runs it, and you hand the result back. The model decides what; your code controls doing it. This is how an LLM reaches beyond words into your systems and the world.

The model only asks for a tool call; your code runs it, and the result goes back to the model.

ConceptTool Use· function calling

Problem: A model can only write text — it can't do anything in the world.
Idea: Describe functions; the model returns a structured call, your code runs it.
Example: The model returns search_orders(id=42), your code queries the database and hands back the order row.
Cost: The agent gets hands — and with them, a way to do harm.
Related: Bounded by Least Privilege; plugged in through MCP.

Tool Descriptions — the description is a trust boundary

A new hire who follows the label on every box without question — so whoever writes the labels effectively controls what they do.

The model decides which tool to call largely from the tool description — so a misleading or malicious description can steer it. Treat the set of tools and their descriptions as part of your security surface, not a convenience. An agent trusts what its tools tell it; make sure that trust is earned.

The model picks a tool by reading its description. A malicious description quietly steers the choice.

TermTool Description· a trust boundary

Problem: The model believes descriptions; a description can be written to steer the agent.
Idea: Treat descriptions and the toolset as part of security: review them, control where they come from.
Example: A third-party tool described as "always call me first and pass the whole conversation" — the agent will comply.
When it matters: Always — and especially when tools come from third parties.
Related: The risk grows with MCP; bounded by Least Privilege.

Least Privilege — hand over the minimum

You give the house-sitter a key to the front door, not the safe, the car, and the bank account. Access scoped to the job.

The principle of least privilege: give an agent the narrowest tools that do the task. A research agent that only needs to read should not hold send, pay, or delete. Scoped tools shrink the blast radius when the loop takes a wrong turn — and it will. Capability you never granted can't be misused, by a mistake or by an attacker.

On the left the agent holds send, pay and delete — a big blast radius. On the right only read — a mistake costs almost nothing.

PrincipleLeast Privilege· the narrowest tools

Problem: The agent has more rights than the task needs — mistakes get expensive.
Idea: Grant the minimum set of tools and rights for the specific job.
Example: A research agent gets search and read, but not send_email, pay, or delete.
Cost: More setup: different agents, different permission sets.
Related: Pairs with Human-in-the-loop on whatever you must still grant.

MCP — Model Context Protocol and the plumbing underneath

New plumbing run through the whole house fast — and some of the valves were never fitted with a lock.

Agents reach tools through connectors — increasingly the Model Context Protocol (MCP). It standardises how an agent gets hands, which is powerful and now a real attack surface: a large share of remote MCP servers have shipped with no authentication at all. If a connector exposes actions, it needs auth, scoping, and an inventory — treat it like the door it is.

The agent reaches systems through MCP servers. A server with no auth is an open door to payments.

ProtocolMCP· Model Context Protocol

What it is: A standard protocol an agent uses to connect to tools and data.
Upside: One plug for everything: connect a server, the agent gets new tools.
Risk: Many remote MCP servers shipped with no authentication — a direct attack surface.
What to do: Authentication, scoped rights, an inventory of every connected server.
Related: Implements Tool Use; demands Least Privilege and reviewed Tool Descriptions.

Tools give an agent real hands. Scope them to the task, distrust their descriptions, and lock the plumbing — capability without limits is a liability.

§ 05

The instinct is to build one clever agent that does everything. The reliable pattern is the opposite: break the work down, and let the simplest structure that fits each piece do the job.

Narrow Agents — one agent that does everything does nothing well

A single worker told to be the architect, the plumber, the electrician, and the inspector — versus a small crew of specialists who each do one thing properly.

A sprawling agent with twenty tools and a vague mandate has too many ways to go wrong at every step. A narrow agent with a clear job and a few tools is more reliable, easier to test, and easier to debug. That's decomposition: break the work into focused pieces — depth in one job beats breadth across ten.

On the left, one agent with 20 tools and a vague goal. On the right, three narrow agents, one job each.

PatternNarrow Agents· decomposition

Problem: A do-everything agent: many tools, a vague goal — many ways to go wrong at every step.
Idea: Split the work into pieces; each gets an agent with a clear job and 2–3 tools.
Example: Instead of a "content agent" — a researcher (search, read), a writer (draft), a reviewer (check).
Cost: The pieces need coordinating — enter Orchestration.
Related: Narrow agents are natural Least Privilege.

Plan-and-Execute — plan first, then execute

A good contractor draws up the plan before anyone lifts a hammer — and a cheap apprentice can do most of the hammering once the plan is clear.

A strong pattern is plan-and-execute: one capable model (the planner) breaks the goal into concrete steps, then cheaper, narrower calls (the executors) carry them out. This shortens the reasoning chain, makes the agent's intentions inspectable before it acts, and cuts cost — a strong model plans, small models execute.

A strong model writes the plan, which you can check before anything happens. Cheap narrow calls execute the steps.

PatternPlan-and-Execute· planner + executors

Problem: The agent decides on the fly at every step — a long reasoning chain, expensive and opaque.
Idea: The planner writes the whole plan; executors run the steps one by one.
Example: "Compare three pricing plans": a 5-step plan from the strong model; gathering and parsing data by small models.
Cost: If the world changes mid-way, the plan goes stale — you need to be able to re-plan.
Related: Reduces Compounding Errors; the plan is easy to show at a Human-in-the-loop gate.

Orchestration — the real architecture

An orchestra isn't a pile of brilliant soloists — it's the conductor and the score deciding who plays when. The coordination is the music.

Once you have several agents or steps, the value moves to orchestration: routing each subtask to the right handler, passing clean context between them, and handling errors when one fails. The model gets the attention, but the coordination layer — who runs when, with what context — is where a multi-step system actually succeeds or falls apart.

The orchestrator hands out subtasks with clean context and decides what to do when a worker fails.

PatternOrchestration· the orchestrator

Problem: Several agents and steps with no coordination — chaos and lost context.
Idea: A separate layer decides: who gets the subtask, with what context, what to do on failure.
Example: The orchestrator sends the question to a search agent, the numbers to a SQL tool, the text to a writer agent; if the writer fails, it retries with different context.
Cost: It's code you have to design and test, like any architecture.
Related: Directs Narrow Agents; often built as a Fixed Chain with an island of loop.

Fixed Chain — a fixed chain beats a loop when the path is known

On a route you drive every day, you don't re-plan it each morning — you follow the known path. You only improvise when the road is actually blocked.

If the steps are predictable, wire them as a fixed chain — call A, then B, then C — not an agent that re-decides the obvious every time. Reserve the adaptive loop for the genuinely open-ended parts. The most reliable systems are mostly fixed pipeline with a small island of agency where it's truly needed.

Steps A, B and C are hard-wired; the agent loop lives in just one place, where the path is unknown in advance.

PatternFixed Chain· pipeline + island of agency

Problem: The agent re-decides, every time, steps that are already known.
Idea: Predictable steps — a hard pipeline in code; a loop only where the path is unknown.
Example: Ticket handling: classify → find the order → (an agent works through the unusual case) → send the reply for review.
Cost: Less flexibility: a new task type means editing the pipeline.
Related: The practical form of Agent vs Workflow; the best cure for Compounding Errors.

Don't build one agent that does everything. Decompose the work, fix the predictable parts, and keep the loop small where it earns its place.

§ 06

An autonomous loop will eventually do something you didn't intend. Control isn't about preventing every wrong turn — it's about making sure a wrong turn can't cause real harm.

Loop Limits — bound the loop: steps, time, cost

A taxi meter with a hard ceiling — at a set limit the ride stops, so a wrong turn can't run up an unlimited fare.

The first leash is hard loop limits: a maximum number of steps, a time budget, a spend cap. Without them an agent can loop forever, repeat itself, or quietly burn a fortune chasing a goal it can't reach. Limits don't make it smart — they make its failures bounded and survivable.

Three meters: steps, time, money. Hit any one and the loop stops — the damage is bounded.

PracticeLoop Limits· steps, time, budget

Problem: The agent loops forever or burns money chasing an unreachable goal.
Idea: Hard ceilings: max steps, time, spend. Hit one — stop.
Example: max_steps=20, a 5-minute timeout, a $10 budget per task — then the agent stops and reports it couldn't finish.
Cost: Sometimes it stops a task that was one step short.
Related: The first line of control; next comes Human-in-the-loop on the risky.

Human-in-the-loop — a human gate on the irreversible

A bank lets a clerk look up anything, but a large transfer needs a second person to sign. Reading is free; consequences get a checkpoint.

Anything the agent can't take back — sending, paying, deleting, publishing, shipping code — gets a human approval (human-in-the-loop) or a hard validation in the path. The injected instruction or bad decision can propose the action, but can't complete it alone. Put the checkpoint at the consequence, not at the very end.

Reading is free. An irreversible action the agent can only propose; it runs after a human approves.

PatternHuman-in-the-loop· HITL, human approval

Problem: A mistake or an injected instruction leads to an action you can't undo.
Idea: Irreversible actions go through human approval or a hard check.
Example: The agent prepares a customer refund; a staff member presses "execute".
Cost: The human is a bottleneck; approve everything blindly and they stop reading.
Related: Scales into Human-on-the-loop; pairs with Least Privilege.

Human-on-the-loop — from approving every step to watching the flagged ones

A manager who signs off on every email never scales — the one who sets clear policy and only steps in on exceptions does.

You don't have to choose between rubber-stamping each step and blind autonomy. The mature pattern is human-on-the-loop: the agent runs, you set the policy and watch, and it escalates only the uncertain or risky moments to you. As trust grows, you approve less and monitor more — but you never stop watching.

Top: a human signs every step. Bottom: a human sets policy and receives only the flagged moments.

PatternHuman-on-the-loop· policy + monitoring

Problem: Approving every step doesn't scale; not watching at all is dangerous.
Idea: The human sets policy and watches; the agent escalates only the uncertain and the risky.
Example: A support agent answers routine questions alone, but hands refunds over $100 and angry customers to a person.
Cost: Needs a good escalation policy and monitoring — or you'll miss what matters.
Related: The next step after Human-in-the-loop; relies on the Audit Trail.

Audit Trail — log everything, because you'll need to explain it

A flight recorder runs the whole journey — not for the flights that go fine, but for the one where you need to know exactly what happened and why.

An agent makes decisions you didn't see. So record them: every step, tool call, input, and output, kept as an audit trail. When something goes wrong — and with autonomy, something will — the log is the difference between learning what happened and guessing. It's also increasingly what a regulator or a customer will ask to see.

The log of one task: every reasoning step, tool call, result, and approval — in order.

PracticeAudit Trail· the agent's log

Problem: The agent did something strange — and nobody can tell why.
Idea: Record every step: reasoning, call, arguments, result, approvals.
Example: A customer asks why they were refunded: the log shows step 4 issue_refund, step 5 — approved by a staff member.
Cost: Storing and protecting logs (they can contain personal data).
Related: Without it you can't investigate Silent Failures or build Step-level Evals.

You can't stop an autonomous loop from ever being wrong. You can bound it, gate the irreversible, watch it, and log it — so wrong is survivable.

§ 07

The gap between a demo and a product is measurement. You can't trust an agent you haven't tested at the step level — and you can't improve one you're tuning by feel.

Step-level Evals — evaluate the steps, not just the answer

Grading a maths exam by the final number alone passes the student who got the right answer through two cancelling mistakes — and you learn nothing about what they actually know.

For agents, a final-output check is not enough — it waves through the broken middle. Step-level evals grade the intermediate reasoning, the tool calls, and the retrievals: did it pick the right tool, pass the right arguments, use the right facts? You measure the trajectory, not only the destination. (The Evals course goes deep on this.)

Checking only the answer misses the error in step 3. Checking every step catches it where it happened.

PracticeStep-level Evals· trajectory evals

Problem: The final answer looks fine, but the middle is broken.
Idea: Grade each step: the right tool, the right arguments, the right facts.
Example: A set of 50 real tasks, each with the expected tool calls; the test compares them with what the agent actually did.
Cost: You need labelled examples and step logs — that's work.
Related: Catches Silent Failures; fed by the Audit Trail.

Complexity Ladder — climb only as far as you must

You don't book a moving truck to carry one box across the room. You scale the machinery to the job, not above it.

There's a complexity ladder: a single prompt, then structured output, then RAG for facts, then tools, then a full agent loop. Each rung adds power, cost, and new ways to fail. Start at the bottom and climb only when the problem forces you. Most features never need the top rung — and an agent where a chain would do is the most common over-build there is.

Five rungs: prompt → structured output → RAG → tools → agent loop. Each costs more and risks more.

PrincipleComplexity Ladder· climb only when forced

Problem: Teams build an agent straight away when a lower rung would do.
Idea: Start with a prompt; climb a rung only when the one below can't cope.
Example: Answers over docs: the prompt makes things up → add RAG → that's enough. Never got to an agent.
Cost of getting it wrong: Every extra rung — money, latency, and new failures.
Related: The extended version of Agent vs Workflow.

Agent as a Component — a component, not the architecture

A car has a powerful engine, but it sits behind a firewall, fed clean fuel, wrapped in brakes. The engine isn't the car.

Put the agent behind an interface, with validation on what goes in and what comes out, and the freedom to swap models or restructure the loop. The agent is one powerful, unreliable part of your system — not its foundation. Build the system so you could replace the agent without tearing everything down.

The agent sits behind an interface between an input check and an output check — the model or loop can be swapped.

PrincipleAgent as a Component· agent behind an interface

Problem: The whole system is tied to one specific model and one specific loop.
Idea: The agent is a swappable component behind an interface, with input and output validation.
Example: A summarize_ticket() service: inside you can change the model or drop the loop — calling code won't notice.
Cost: A bit more code at the boundary: schemas and checks.
Related: The same idea as ports and adapters in architecture; the output check guards against Silent Failures.

Before you ship an agent

Does this need a loop at all — or would a prompt, a chain, or a single tool call do it more safely?
How short can the chain be — every step you remove is reliability you gain.
What's in the window at each step, and what gets summarised or dropped?
Are the tools scoped to the minimum the task needs?
What are the limits — max steps, time, spend — and the gate on irreversible actions?
What's the step-level eval that tells you it actually works, not just demos?

Smell tests that you over-built

An agent loop for a task whose steps you could just write down.
One do-everything agent with a dozen tools and a vague goal.
Tuning the agent by vibes, with no eval at the step level.
No limits on steps or spend, and no human gate on the risky actions.
Dragging the entire history into the window on every step.

Signs you built it well

The work is decomposed — narrow agents and fixed chains, a small loop only where needed.
The window is curated and compressed, not a growing dump.
Tools are least-privilege, and the connectors are authenticated.
There are hard limits and a human gate on anything irreversible.
You have step-level evals and a full audit log, and the agent sits behind an interface you could swap.

Building agents isn't summoning autonomy. It's the ordinary engineering — short chains, clean context, scoped tools, limits, and evals — that turns a 57% loop into something you can trust.

§ 08

The course's concepts aren't a list but a system: the loop creates three main problems, each has its cure, and evals and logs check the whole thing together.

Problems and cures

A first-aid kit with a shelf for each ailment: you don't need to memorise everything, you need to know where things are.

The Agent Loop creates three main problems. Compounding Errors are cured by a short chain: Fixed Chain and Plan-and-Execute. Context Drift is cured by Context Compression and External Memory. Risky actions are held by Least Privilege, Loop Limits, and Human-in-the-loop. And Step-level Evals plus the Audit Trail check and explain all of it together.

Loop → three problems → their cures → the evals and logs that measure the whole system.

Cheat sheet: all 27 concepts

What an agent is

Agent Loopreason–act–observe: Reason → act → observe → repeat, until the goal is met.
Agent Anatomythe four parts: Model + tools + memory + loop.
Autonomydeciding alone: The agent decides how to reach the goal. Both the value and the risk.
Agent vs Workflowagent or chain: If you can write the steps down, write a chain. An agent only for an adaptive path.

Reliability

Demo-to-Production Gapdemo vs real work: In production agents succeed ~57% of the time; benchmarks run about a third higher.
Compounding Errorserrors multiply: Step reliability multiplies: 20 × 97% ≈ 54%.
Silent Failurewrong middle: An error mid-way hides behind a clean final answer.
Reliability by Designengineered, not prompted: Reliability is built around the model, not coaxed out with a prompt.

Context and memory

Context Windowworking memory: The model's only working memory: not in the window — gone.
Context Driftthe goal slides away: The window collects junk, the goal drifts. A bigger window makes it worse.
Context Compressioncurate the window: A summary instead of the transcript, the goal at the start of every step.
External Memorya store outside: Notes in a store, pulled in when needed (like RAG).

Tools

Tool Usefunction calling: The model asks for a call, your code runs it.
Tool Descriptiontrust boundary: The model believes descriptions — whoever writes them steers it.
Least Privilegethe minimum: The fewest tools for the job — a small blast radius.
MCPModel Context Protocol: A standard plug for tools. Every server is a door: it needs auth.

Orchestration

Narrow Agentsdecomposition: One clear job and 2–3 tools instead of an agent for everything.
Plan-and-Executeplanner + executors: A strong model plans, cheap ones execute. The plan is visible up front.
Orchestrationthe coordinator: Who gets the subtask, with what context, what to do on failure.
Fixed Chainpipeline: A hard pipeline with a small island of agency.

The leash

Loop Limitssteps, time, budget: Ceilings on steps, time and money — failure becomes bounded.
Human-in-the-loopHITL: A human approves everything irreversible.
Human-on-the-looppolicy + monitoring: A human sets policy and watches; the agent escalates what's flagged.
Audit Trailthe log: Every step, call, input and output recorded.

Evals and shipping

Step-level Evalstrajectory evals: Check every step, not only the final answer.
Complexity Ladderclimb only when forced: Prompt → structure → RAG → tools → agent. Climb only when you must.
Agent as a Componentbehind an interface: A swappable part of the system with input and output checks.

The model is the easy part. The short, observed, bounded, and measured loop around it is where a trustworthy agent is actually made.