Week 0: The Demo That Said It Booked a Table
Prerequisite: none. This is a five-minute orientation, not a lesson. After this, you can: decide whether this course is worth 33 lessons of your time, before spending any of them.
A model said it made a reservation. It didn't.
Somewhere in this course's Week 3 material, a fast, cheap model is asked to confirm a pub booking as the last step of a three-step plan. It responds with confident, well-formed prose: reservation secured. No tool was ever wired to it. No pub was contacted. Nothing happened. The model didn't malfunction. It did exactly what a language model does when you ask it to produce text that sounds like a completed action: it produced text that sounds like a completed action.
That's the gap this whole course is built around, and it's worth naming plainly before you commit any time here. A system that talks like an agent and a system that acts like one are not the same thing, and the difference isn't obvious from watching a demo succeed. It's only visible when you go looking for it, which is exactly what this course spends five weeks teaching you to do.
The real running example
This course doesn't use synthetic toy problems. It runs one real logistics scenario, organizing a 160-person meetup in Edinburgh with a hard 5 PM deadline, through five weeks of growing difficulty: first as a demonstration of why a longer chat history isn't agency, then as a testbed for context and model-selection decisions, then as the proving ground for real tools, real memory, and a real multi-agent architecture built and debugged on camera. If you've built something that felt like an agent but never quite trusted in production, this is very likely why: the parts that make a system trustworthy (tool design, memory that survives past one session, defense against a poisoned input) are exactly the parts a working demo can hide.
Two disciplines, not one
Most material on agents teaches prompting. This course teaches the two disciplines underneath that decide whether an agent survives contact with anything real: designing tools it can call safely, and giving it memory that holds up past a single session. You'll see both fail in this course, on purpose and in detail, including in the course's own worked labs: a plain-text document dump that causes a model to blend two near-identical documents into one wrong, confidently-stated answer; a Planner that plans correctly and an Executor that narrates instead of acting. Each failure has a specific, named fix, not a vague "be more careful."
Why this course is five weeks, not a weekend
Thirty-three lessons is a lot, and it's worth saying why: each week only makes sense once the last one has landed.
What actually makes something an agent versus a longer chat loop, why context windows lose track of buried information, and the model-tiering economics behind running a Planner and an Executor as two different models.
Every way a model can actually call a tool, from CLI wrappers to MCP to A2A, worked end to end, so the narration-not-action gap from this page's own example gets an actual fix.
From reactive loops to a hand-built ReAct agent to the Planner-Executor architecture's own four named failure modes.
Not "add a vector database": the full taxonomy, all nine CRUD++ operations, and how a memory store gets defended against a poisoning attack at the write path.
Sovereign-agent v0.1.0, built in an 18-hour window: eight architectural decisions, eight real failures, and why structural correctness isn't the same thing as semantic correctness.
A shorter course could teach you to call a tool. It can't show you the tool call that fails silently under a real API rate limit, or the memory store that gets poisoned by its own write path, because those failures only show up at the depth this course actually goes to.
What you can do after Week 1
By the end of Week 1 you can tell whether something calling itself an agent actually has a body that can act, explain why a bigger context window doesn't fix a model losing track of information in the middle of a long prompt, and know exactly when to split a task between a deliberating model and a fast one instead of running one model for everything. By the end of the course, you will have built a reasoning agent and a memory subsystem yourself, and you can look at any agent framework, including your own, and say specifically which bug classes its architecture actually removes and which ones it just hides.
From AI Model to AI Agent Engineering: the Edinburgh case study, and the one-sentence test for whether something is actually an agent.
Reply here and it goes straight to Rod. Same as replying to one of his emails.
