Closing: Exercises, Further Reading, and the Questions We Get
Prerequisite: every prior lesson in this course — this is the closing lesson, and it does not introduce new architecture. After this lesson, you can: run this course's central question against your own backlog instead of just Sarah's, recognize the objections people most often raise against the two-axis model and how to answer them, and know where to go next.
The whole course, compressed
If you had to compress this whole course onto a post-it note, here's the version that fits: the anatomy of an agent is always the same (Brain, Planning, Tools, Memory, a loop that turns suggestion into action) and it sits on two independent axes, not one. Application (headless or conversational) is about who's waiting on the result. Implementation (stochastic or deterministic) is about who's deciding what happens next. This course's own reading of the pattern is that collapsing those two axes into one was a large part of the "agents don't work" fatigue from 2024 and 2025 — a diagnosis from watching how teams built, not a cited industry study — and Sarah's triage brief, back in lesson five, showed why: her system wasn't one quadrant, it was four layers, each in a different one, and her actual job was knowing which piece belonged where.
That's the question this entire course exists to answer, and it's worth stating plainly now that you've seen it applied a dozen times: not "which framework should I use," but "for this piece of my system, which quadrant does it belong in, and do I know why." Everything else (the tooling, the vendor, the demo) is downstream of getting that one question right.
The questions this material gets, answered directly
A framework comparison usually ends with a verdict: this one wins. That's not how this course closes, because it's not how the two-axis model works. Claw-style agents and Rasa CALM aren't competing for the same job, they're built for different quadrants. The objections below are the ones that come up most often when people first sit with that idea, answered the way they came up.
Five exercises to run against your own backlog
The point of this course was never Sarah's system — it was giving you a question you can run against your own. Here's how to do that this week.
Write one sentence each for: who is waiting on it, who decides what happens next, what failure looks like at three in the morning, and which quadrant it's actually in. If your answers don't match the quadrant it's built like, you have a migration ahead of you, whether or not anyone's noticed yet.
Take a real brief, not a hypothetical one. Break it into layers the way Sarah's triage system got broken into four. Place each layer in a quadrant. Anywhere you land in Conversational + Stochastic, ask directly whether a human reviews every action that quadrant takes. If not, that layer needs to migrate.
Pick a single agent-touching piece of your system. Write ten representative inputs and the correct output for each, then run them. Most systems fail at least one on the first pass. That failure is your actual starting point, not a footnote.
Take a recent incident or demo and calculate the real token cost per turn against your provider's own pricing page, then multiply by expected volume. An uncomfortable number usually means one of three things: wrong quadrant, missing caching, or missing tool routing. All three are fixable once you can see the number.
Draw the state that flows between two layers of your system and type the boundary precisely. If you can't write down what crosses that boundary and in what shape, the handoff is fragile, and production will find that out before you do.
Further reading, credited by name
Everything in this course descends from work this course didn't invent. Read the sources directly rather than trusting the summary: that's the same first-party instinct this course has been asking of you the whole way through. These are the practitioners and primary docs this course leaned on most directly, named so you can go verify anything in this course against them yourself, not because each claim above traces to one specific citation in this list.
| Topic | Source |
|---|---|
| The Claw ecosystem | The NanoClaw repository (~500 lines, readable in an afternoon); the IronClaw documentation, the clearest existing statement of a security-first approach to this architecture |
| Rasa and CALM | The Rasa CALM documentation; the Rasa changelog across the 3.10-3.16 releases; the CALM paper's own walkthrough of its "commands" abstraction |
| Eval engineering (lesson 9 leaned on this directly) | Hamel Husain's and Chip Huyen's writing on evaluation for production ML systems; the OpenAI Evals framework, useful here more for its structure than as a drop-in tool |
| Agent security | Simon Willison's running commentary on prompt injection, which predates and outlasts most of the frameworks discussing it |
| The AI Product Engineer role (lesson 10) | The Pragmatic Engineer's coverage of the broader Product Engineer title shift, and, more than any single article, your own backlog |
A brief you actually have to ship teaches this faster than any further reading list, including this one.
Pick one system you're responsible for. Answer, in one sentence each: who's waiting, who's deciding, and what quadrant it's actually in versus what quadrant it's built like. That's the whole course, applied once, for real. Revisit any lesson from here.
Reply here and it goes straight to Rod. Same as replying to one of his emails.
