# An agent is a loop you have to engineer Express course on building reliable AI agents. 27 concepts — Agent Loop, Context Drift, Tool Use, Least Privilege, MCP, Plan-and-Execute, Human-in-the-loop, Step-level Evals and more — each with its English name, a diagram, and a card: problem → idea → example → cost. Why an agent works only ~57% of the time by default, and how engineering the loop fixes it. Ends with a relations map and a cheat sheet. - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~35 minute read - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/learn/ai-agents-express --- ## 1. What an agent really is 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. _Diagram: 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. _Diagram: Agent Loop: reason → act → observe → reason again, until the goal is met or a limit trips._ #### Agent 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. _Diagram: Agent = model + tools + memory + loop. Remove one part and you get something else._ #### Agent 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.** _Diagram: The more the agent decides alone, the more value and the more danger. The target is the middle: gated autonomy._ #### Autonomy (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. _Diagram: The key question: can you write the steps down in advance? Yes — use a prompt or a chain. No — then an agent._ #### Agent 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). > **Before you build an agent:** "Does this task truly need an adaptive, multi-step loop — or am I reaching for an agent when one call or a fixed chain would be cheaper and safer?" > 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. ## 2. The reliability problem 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.** _Diagram: Benchmarks run roughly a third above reality; in production it's about 57%. The gap is everything the demo didn't show._ #### Demo-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.** _Diagram: 97% per step sounds great. But 20 steps in a row is about 54% — nearly a coin flip._ #### Compounding 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. _Diagram: An error in step 3 rides through to an answer that looks clean — a final-only check never sees it._ #### Silent 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. _Diagram: Five levers around the model: short chain, right context, scoped tools, step checks, limits._ #### Reliability 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. > **The reliability question:** "When this agent fails — not if — where does the failure go, and how would I even know it happened?" > 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. ## 3. Context and memory 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. _Diagram: The model sees only what's in the window: the goal, what was tried, the last output. Nothing else exists for it._ #### Context 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.** _Diagram: With every step the window holds more stale and contradictory text, and the goal shrinks to a sliver._ #### Context 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. _Diagram: A long transcript collapses into a short state; the next step sees the goal, that state, and the current input._ #### Context 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. _Diagram: 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._ #### External 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**. > **The context question:** "At this step, is everything in the window earning its place — or am I dragging the whole history forward and hoping the model sorts it out?" > An agent is only as coherent as its window. The biggest context window doesn't win — the best-managed one does. ## 4. Tools and the real world 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.** _Diagram: The model only asks for a tool call; your code runs it, and the result goes back to the model._ #### Tool 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. _Diagram: The model picks a tool by reading its description. A malicious description quietly steers the choice._ #### Tool 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. _Diagram: On the left the agent holds send, pay and delete — a big blast radius. On the right only read — a mistake costs almost nothing._ #### Least 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. _Diagram: The agent reaches systems through MCP servers. A server with no auth is an open door to payments._ #### MCP (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**. > **The tool question:** "If this agent's loop went wrong at the worst moment, what's the most damage its current tools would let it do?" > Tools give an agent real hands. Scope them to the task, distrust their descriptions, and lock the plumbing — capability without limits is a liability. ## 5. Orchestration and decomposition 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. _Diagram: On the left, one agent with 20 tools and a vague goal. On the right, three narrow agents, one job each._ #### Narrow 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. _Diagram: A strong model writes the plan, which you can check before anything happens. Cheap narrow calls execute the steps._ #### Plan-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. _Diagram: The orchestrator hands out subtasks with clean context and decides what to do when a worker fails._ #### Orchestration (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. _Diagram: Steps A, B and C are hard-wired; the agent loop lives in just one place, where the path is unknown in advance._ #### Fixed 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**. > **The orchestration question:** "Am I asking one big agent to do this whole job — when a few narrow steps, mostly fixed, with a loop only where it's needed, would be more reliable?" > 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. ## 6. The leash 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**. _Diagram: Three meters: steps, time, money. Hit any one and the loop stops — the damage is bounded._ #### Loop 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. _Diagram: Reading is free. An irreversible action the agent can only propose; it runs after a human approves._ #### Human-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. _Diagram: Top: a human signs every step. Bottom: a human sets policy and receives only the flagged moments._ #### Human-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. _Diagram: The log of one task: every reasoning step, tool call, result, and approval — in order._ #### Audit 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**. > **The control question:** "If this agent does the wrong thing at full speed, what stops it before real harm — and could I reconstruct afterward exactly what it did?" > 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. ## 7. Evals and shipping 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.) _Diagram: Checking only the answer misses the error in step 3. Checking every step catches it where it happened._ #### Step-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.** _Diagram: Five rungs: prompt → structured output → RAG → tools → agent loop. Each costs more and risks more._ #### Complexity 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. _Diagram: The agent sits behind an interface between an input check and an output check — the model or loop can be swapped._ #### Agent 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. ## 8. How it all connects 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. _Diagram: Loop → three problems → their cures → the evals and logs that measure the whole system._ ## Cheat sheet: all 27 concepts ### What an agent is - **Agent Loop** (reason–act–observe): Reason → act → observe → repeat, until the goal is met. - **Agent Anatomy** (the four parts): Model + tools + memory + loop. - **Autonomy** (deciding alone): The agent decides how to reach the goal. Both the value and the risk. - **Agent vs Workflow** (agent or chain): If you can write the steps down, write a chain. An agent only for an adaptive path. ### Reliability - **Demo-to-Production Gap** (demo vs real work): In production agents succeed ~57% of the time; benchmarks run about a third higher. - **Compounding Errors** (errors multiply): Step reliability multiplies: 20 × 97% ≈ 54%. - **Silent Failure** (wrong middle): An error mid-way hides behind a clean final answer. - **Reliability by Design** (engineered, not prompted): Reliability is built around the model, not coaxed out with a prompt. ### Context and memory - **Context Window** (working memory): The model's only working memory: not in the window — gone. - **Context Drift** (the goal slides away): The window collects junk, the goal drifts. A bigger window makes it worse. - **Context Compression** (curate the window): A summary instead of the transcript, the goal at the start of every step. - **External Memory** (a store outside): Notes in a store, pulled in when needed (like RAG). ### Tools - **Tool Use** (function calling): The model asks for a call, your code runs it. - **Tool Description** (trust boundary): The model believes descriptions — whoever writes them steers it. - **Least Privilege** (the minimum): The fewest tools for the job — a small blast radius. - **MCP** (Model Context Protocol): A standard plug for tools. Every server is a door: it needs auth. ### Orchestration - **Narrow Agents** (decomposition): One clear job and 2–3 tools instead of an agent for everything. - **Plan-and-Execute** (planner + executors): A strong model plans, cheap ones execute. The plan is visible up front. - **Orchestration** (the coordinator): Who gets the subtask, with what context, what to do on failure. - **Fixed Chain** (pipeline): A hard pipeline with a small island of agency. ### The leash - **Loop Limits** (steps, time, budget): Ceilings on steps, time and money — failure becomes bounded. - **Human-in-the-loop** (HITL): A human approves everything irreversible. - **Human-on-the-loop** (policy + monitoring): A human sets policy and watches; the agent escalates what's flagged. - **Audit Trail** (the log): Every step, call, input and output recorded. ### Evals and shipping - **Step-level Evals** (trajectory evals): Check every step, not only the final answer. - **Complexity Ladder** (climb only when forced): Prompt → structure → RAG → tools → agent. Climb only when you must. - **Agent as a Component** (behind 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. End of express course · 8 chapters · 27 concepts Next comes practice: build the smallest agent that does one real job end to end — one goal, two or three scoped tools, a step limit, and a log you can read. Then add a step-level eval before you add a single feature. But hold one idea above the rest: the model is the easy part. The loop around it — short, observed, bounded, and measured — is where a trustworthy agent is actually made.