← Courses
Advanced11 modules·35 lessons·~15 hours
Agent Engineering
Agents are the most over-applied pattern in applied AI and the hardest to make reliable. This course covers the loop, tool design, memory, multi-agent coordination, and evaluation, with as much attention on when not to build one as on how.
An agent is a model that decides its own next step. That freedom is bought with reliability, predictability, cost, and your ability to debug what happened, and most systems described as agents would work better as something simpler.
This course takes that seriously. It opens by arguing against building agents, then spends seven modules on doing it well anyway, because when the path really cannot be known in advance there is no substitute and the engineering is genuinely hard.
It is the deepest material on this site. Expect specifics: termination conditions, schema design, memory eviction, orchestration patterns that hold and ones that deadlock, and how to tell whether any of it is working.
The first three modules are free. The rest ask you to sign in or subscribe.
WHAT YOU WILL BE ABLE TO DO
- →Place any system on the autonomy spectrum and justify where you put it
- →Design tool schemas that a model can actually use correctly
- →Budget an agent's context instead of letting it grow until something breaks
- →Know the point where a second agent stops paying for itself
- →Make a loop survive tool failures, non-termination, and long-horizon tasks
- →Evaluate an agent on its trajectory, not just its final answer
BEFORE YOU START · Comfortable calling a model API and writing the code around it. The Applied AI Engineering course, or equivalent experience, covers what is assumed here.
Course content
- ○What the loop actually carries between stepsEvery agent pattern is a variation on one loop, and the interesting part is not the control flow but what accumulates in the message list. Understanding that accumulation explains the cost curve, the drift, and most of what goes wrong later.Free14m
- ○Thinking between actions, and what it costsInterleaving a short reasoning step before each action is the most widely used agent pattern. This lesson covers what it actually buys, the three places it helps most, and the specific way it degrades over a long run.Free13m
- ○Planning ahead versus deciding as you goCommitting to a plan first makes a run cheaper, more predictable and easier to check, and it is wrong whenever the plan cannot survive what the first step returns. This lesson is how to tell which case you are in, and the hybrid that usually wins.Free13m
- ○Stopping is a design decision, not a budgetBudgets stop a runaway agent. They do not tell it when it is finished, and the difference between those two things is where most agent quality is lost. This lesson covers the four ways to define done and what to return when you never got there.Free14m
- ○Project: build an agent loop from scratchPROJECTOpen your editor and build the thing this module described: a bounded loop with three tools, a finish action, and full logging. About three hours, and you will end with an agent you can point at and a trace you can read.Free180m
- ○Designing an API for a consumer that cannot read the docsA tool set is an API whose only user is a model with no memory of your codebase and no way to ask. That constraint changes granularity, naming and error design in specific ways, and most tool sets are built as though a person were reading them.Free14m
- ○Tool results are the biggest thing in your contextThe most overlooked lever in agent engineering. What comes back from a tool is usually the majority of the context and almost nobody designs it, which is why runs get expensive and lose the thread at the same time.Free14m
- ○Writing errors an agent can act onAn error message is a prompt. It is the only instruction you get to inject at the exact moment the agent is deciding what to do next, and most systems waste it on a stack trace.Free13m
- 🔒Why an agent's threat model is not your application'sEvery security model you have used assumes code decides and data is inert. An agent erases that line, because the text it reads is the same channel as the instructions it follows. This lesson replaces the assumption before the next three lessons build on it.Sign in13m
- 🔒The dangerous text is the text your own code fetchedInjection through a chat box is the easy case, because you know that text is untrusted. The hard case arrives inside a tool result your own code requested, wearing your system's clothes. This lesson maps where untrusted text actually enters an agent and what to do at each door.Sign in14m
- 🔒Deciding what the agent may do, not what it may sayOnce you accept that an injection will eventually succeed, the only thing that bounds the damage is what the agent was permitted to do at that moment. Identity, scoping, and the actions that need a second signature.Sign in14m
- 🔒What a sandbox buys, and the exit everyone leaves openAgents that write code or drive a browser need somewhere to run that is not your machine. What isolation actually contains, why the network is the exit that matters, and how to decide the blast radius before the run rather than after.Sign in13m
- 🔒Memory is four problems wearing one wordDiscussions about agent memory go in circles because four different problems share the name. Separating them turns an unbounded design question into four bounded ones, each with a known answer.Sign in13m
- 🔒What to drop when the context fillsEvery long run eventually has more history than budget. The order in which you discard things decides whether the agent stays coherent or quietly loses the thread, and the default of dropping the oldest messages is close to the worst option available.Sign in14m
- 🔒State that has to survive the processOnce a run can pause for approval, be retried, or outlive a deployment, its progress has to live somewhere durable. This lesson covers what to checkpoint, why steps must be safe to repeat, and how retrieval changes when an agent is the one searching.Sign in14m
- 🔒The two reasons to use more than one agentMulti-agent designs are usually adopted for reasons that do not survive examination. Two hold up, both are about context rather than intelligence, and knowing which one you are invoking tells you how to build it.Sign in13m
- 🔒The two patterns that account for most of the valueOrchestrator-and-specialist and critic-and-refiner cover nearly every multi-agent system worth building. This lesson is how each works, the design decisions inside them, and why free-form agent conversation is not a third option.Sign in14m
- 🔒Where coordination costs more than it savesMulti-agent systems have a point past which adding agents makes things worse, and it arrives earlier than people expect. This lesson covers the four costs that grow with agent count and the ways a system stalls without anything reporting a failure.Sign in13m
- 🔒Why a 95 percent agent fails most of its tasksThe arithmetic that governs every agent design, stated properly. Once you have it, most reliability decisions answer themselves, and several popular ones turn out to be the wrong lever entirely.Sign in13m
- 🔒Making a run safe to repeatA long agent run will be interrupted, and the dangerous moment is the step that was in flight. This lesson covers idempotency for agents specifically, why the model is a bad place to track what has been done, and how to resume without redoing side effects.Sign in14m
- 🔒Where a human belongs in the loopHuman review is the strongest control you have and the easiest to waste. This lesson covers which steps deserve a person, how to present a decision so it gets real attention, and why a checkpoint everyone approves is worse than none.Sign in13m
- 🔒Project: make your agent survive being killedPROJECTTake the agent you built in module 2 and make it resumable. Checkpoint every step, make one side effect idempotent, then kill the process mid-action and prove it recovers without doing the thing twice.Sign in150m
- 🔒You cannot debug what you cannot replayA request log tells you an agent run happened. It does not tell you why the agent decided what it decided, which is the only question anyone ever asks. Why the run rather than the request is the unit of observation, and what a trace has to contain to answer that question later.Sign in13m
- 🔒What to keep, what to drop, and what you must not store at allFull traces are the most useful thing you can keep and the most expensive, and they are a copy of your customers' data in a second system. Sampling that keeps the runs worth having, retention that survives a slow complaint, and the redaction that has to happen before anything is written.Sign in12m
- 🔒Why scoring the final answer tells you almost nothingAn agent that reaches the right answer through eight wrong turns scores identically to one that went straight there, and the two are not the same system. This lesson is what to look at instead, and why it changes which problems you can fix.Premium13m
- 🔒The measures worth keepingSix measures cover almost everything useful about an agent, and four of them need no judgement at all. This lesson is what each one tells you, which failure it points at, and the order to build them in.Premium14m
- 🔒Evaluating a conversation, not a requestOnce an agent talks to a person across several turns, every method so far breaks, because there is no fixed input to replay. This lesson is how to evaluate something whose input depends on its own previous output.Premium13m
- 🔒The one number a business will ask you forEvery measure so far is internal. This is the one that decides whether an agent stays funded, and it is a number many teams cannot produce when asked, because it counts the failures as well as the successes.Premium13m
- 🔒Project: measure the agent you builtPROJECTPoint the four deterministic measures at your own agent, build a twenty-case set, and produce the two numbers you will be asked for: what it scores, and what one change did to it.Premium150m
- 🔒Standardising how an agent reaches its toolsBefore a protocol layer existed, every team wrote the same adapter between their agent and every tool it used, N times over. What a tool protocol standardises, what it deliberately does not, and why a shared tool surface moves the trust problem rather than solving it.Premium13m
- 🔒What any agent framework has to solve, and how to judge oneNaming this year's frameworks is a lesson with a one-year shelf life. Naming the six problems every framework must solve is one you can use to evaluate the next one, and to answer the interview question without betting on a vendor.Premium14m
- 🔒The four agents companies actually buildCoding, browser, research and data agents are where most agent work and most agent hiring is. Each has one property that dominates its design, and knowing which one is what separates a specific answer from a generic one in an interview.Premium14m
- 🔒The four prompts, and what they are really askingAgent design questions come in four recognisable shapes, and each has a stated subject and a real one. Knowing which is which turns a broad question into a specific answer, because the stated one is the easier one to answer by mistake.Premium14m
- 🔒The sentences that mark someone who has run oneThe final lesson. Six specific things a candidate says that could only come from operating an agent rather than building one, and the three claims that reliably mark the opposite.Premium12m
Every lesson links into the question bank so you can practise what you just read against real interview questions. Locked lessons still show their full summary, so you always know what is behind them.