Curation in progress
Agents & MCP
Thirteen modules for someone whose agent already works on the happy path. It starts by replacing the word 'agent' with a loop - model, tool call, result, repeat - and asks the question almost nobody can answer about their own system: what did the model actually receive on turn three. Then tools and function calling, schemas and argument validation, and what goes wrong when there are forty of them. MCP end to end: hosts and clients and servers, tools and resources and prompts, stdio against streamable HTTP, and building, testing and distributing a server yourself. Context engineering as a budget rather than a window - compaction, memory that is not a vector database, retrieval into the loop, and context rot. Planning and decomposition, and when planning makes an agent worse. Multi-agent orchestration, including the case for one agent. Then the parts that decide whether it survives contact with users: least privilege and sandboxing, prompt injection through tools and the lethal trifecta, evaluating a trajectory rather than an output, where the tokens go, and tracing a run you have to reproduce. It stops where inference-engineering starts: how the model is trained or served is not this course.
- Modules
- 13
- Lessons
- 60
- Watch time
- 51h 19m
- Free to open
- 4
What an agent actually is
Replace the word 'agent' with a mechanism you could draw on a whiteboard.
- 01.01The loop, not the modelDraw the agent loop: model, tool call, result, repeat, and say where each step can fail.
- 01.02Agent or workflow — and why it mattersDecide whether a task needs an agent at all, or a fixed pipeline that is cheaper and testable.
- 01.03What the model actually sees each turnReconstruct the exact payload sent on turn three of a conversation with two tool calls.
- 01.04Stopping, and the loop that will notBound a loop so it terminates on success, on budget and on repetition.
- 01.05Your first agent, end to endBuild a working single-tool agent and watch every message in the loop.
Tools and function calling
Give a model hands, and make the hands safe: function calling, tool schemas, validating arguments, errors and retries, and having too many.
- 02.01Function calling, concretelyExpose a function to a model and handle the call it makes.
- 02.02Designing a tool the model can useWrite a tool description precise enough that the model picks it for the right reason.
- 02.03Validating what comes backTreat model-supplied arguments as untrusted input and validate before executing.
- 02.04When a tool failsReturn an error the model can act on instead of one that ends the run.
- 02.05Too many toolsExplain why tool choice degrades with count, and what to do instead.
MCP: the protocol
Understand Model Context Protocol as a wire format, not a product.
- 03.01What MCP actually solvesSay what problem MCP solves that a bag of function definitions does not.
- 03.02Hosts, clients and serversName the three roles and which one your code is in any given integration.
- 03.03Tools, resources and promptsChoose the right MCP primitive for a capability instead of making everything a tool.
- 03.04Transports: stdio and HTTPPick a transport and explain what changes about deployment and trust.
- 03.05Reading somebody else's MCP serverAudit a third-party server before you let it into your loop.
Building an MCP server
Ship a server of your own and know why each part is there: a first server, exposing resources, testing it, and packaging it for other people.
- 04.01Your first MCP serverBuild, run and connect a server exposing one real tool.
- 04.02Exposing data as resourcesServe read-only context without turning it into a tool call.
- 04.03Testing a server without an agentExercise a server directly so failures are yours, not the model's.
- 04.04Packaging it for other peopleShip a server somebody else can install without reading your source.
Context engineering
The loop's real constraint is the window. Manage it deliberately.
- 05.01Context is the budgetAccount for every token in a long run and find where it went.
- 05.02Compaction without losing the threadCompress a long run so the agent keeps what matters and drops what does not.
- 05.03Memory that is not a vector databaseChoose between a scratchpad, a file, a database and embeddings for agent memory.
- 05.04Putting retrieval inside the loopLet the agent fetch what it needs instead of pre-stuffing the prompt.
- 05.05Context rotRecognise when more context is making answers worse, and prove it.
Planning and decomposition
When a plan beats a bigger prompt: plan-then-execute, scratchpads, subtasks and checkpoints, and the cases where planning makes an agent worse.
- 06.01Plan, then executeSplit a task into a plan step and an execution loop, and say when that helps.
- 06.02Thinking out loud, on purposeUse a scratchpad so the model's reasoning is inspectable rather than implied.
- 06.03Subtasks and checkpointsBreak long work so a failure costs one step, not the whole run.
- 06.04When planning makes it worseSpot the tasks where a plan adds latency and error without adding accuracy.
Multi-agent orchestration
More agents is a design choice with a bill: when more than one is warranted, handoffs, subagents, orchestrator-worker, and committee cost.
- 07.01When one agent is not enoughJustify a second agent in terms of context, tools or permissions — not vibes.
- 07.02Handoffs and routingRoute a request to the right specialist and pass the state it needs.
- 07.03Subagents and context isolationUse a subagent to keep a noisy job out of the main context.
- 07.04Orchestrator and workersFan work out and merge it back without losing track of what failed.
- 07.05The cost of a committeeMeasure what multi-agent costs in tokens, latency and debuggability before committing.
Permissions and sandboxing
Decide what the loop may touch before it touches it: least privilege, sandboxed execution, human-in-the-loop gates, and handling credentials.
- 08.01Least privilege, for a loopScope an agent's credentials to the smallest set its task actually needs.
- 08.02Sandboxing what it runsRun model-authored code without giving it your environment.
- 08.03Human in the loop, where it countsPut an approval gate on the actions that are expensive to undo.
- 08.04Credentials an agent can reachKeep an agent's tools from becoming a path to every key in the environment.
Untrusted input in a loop
The security model that changes once the model can act: prompt injection through tools, the lethal trifecta, OWASP's LLM Top 10, and real defences.
- 09.01Prompt injection when the agent can actTrace how text in a fetched page becomes an action your agent takes.
- 09.02Private data, untrusted content, and a way outIdentify the three properties that together make exfiltration possible, and break one.
- 09.03The OWASP LLM Top 10, against your agentWalk your own agent against the list and say where it stands on each.
- 09.04Defences that survive contactRank the real mitigations and say why prompt-level pleading is not one.
Evaluating agents
Judging a process, not an answer: why output eval falls short, building a test set, trajectory eval, LLM-as-judge, and regression before deploy.
- 10.01Why grading the answer is not enoughExplain how an agent reaches a right answer the wrong way, and why that matters.
- 10.02A test set for something non-deterministicAssemble cases that catch regressions without pretending the output is stable.
- 10.03LLM as judge, and its failure modesUse a model as a grader while knowing what it is systematically bad at.
- 10.04Grading the trajectoryScore the steps an agent took: tool choice, order, and recovery.
- 10.05The eval that blocks a deployWire evals into CI so a prompt change cannot ship on a hunch.
Cost, latency and caching
Where an agent loop burns money and how to stop it: where tokens go, prompt caching, model routing, latency in a loop, and circuit breakers.
- 11.01Where the tokens actually goBreak a run down by token spend and find the step that dominates it.
- 11.02Prompt cachingStructure a prompt so the stable half is cached and the bill drops.
- 11.03Using a smaller model where it is enoughRoute steps by difficulty instead of sending everything to the largest model.
- 11.04Latency multiplies in a loopPredict wall-clock for an N-step agent and find what to parallelise.
- 11.05Budgets and circuit breakersCap what a single run can spend before it spends it.
Observability and debugging runs
Reading a trace of something that will not repeat: what to log, tracing a run end to end, reproducing a bad run, and monitoring one in production.
- 12.01Tracing a runCapture every step of an agent run so a failure can be read afterwards.
- 12.02What to log when the output is not stableLog the inputs, the tool calls and the decisions, not just the final answer.
- 12.03Reproducing a bad runReplay a failure closely enough to fix it, given temperature and tool state.
- 12.04Knowing it broke before a user says soAlert on the agent-specific signals: loop length, tool error rate, cost per run.
Shipping an agent
Put it in front of people and keep it there: scoping what it may do, building a real one, the failure modes users see, and rolling out safely.
- 13.01Scoping what it is allowed to doWrite down the agent's remit and enforce it in code, not in the prompt.
- 13.02The failure modes a user actually seesHandle the loop that stalls, the tool that 500s and the answer that is confidently wrong.
- 13.03Rolling it out without a big bangShip to a slice of traffic and know what would make you roll back.
- 13.04Keeping it working after the model changesSurvive a model deprecation or upgrade without re-discovering every prompt.
- 13.05Build one, properlyShip a bounded, evaluated, observable agent that does one real job.