Mentor Handbook · 00 Before You Teach

The whole arc: five layers, one harness

By the end of this chapter you can stand at a whiteboard on Monday morning, draw one stacked picture, and tell the cohort the entire five-day story in five minutes — so that every student knows where we are, what we've already built, and what we bolt on next at every hour of the week. This is the map you keep on the wall all week and point back to constantly.

This chapter is about the shape of the whole thing. If the students hold this map in their heads, every later lesson has a home to land in. If they don't, each day feels like a disconnected trick. So you have to own this arc completely — you'll redraw it a dozen times before Friday.

Let's build the story the way you'll build it for them: one plain idea, one picture, then the stack.

Start with the thing at the center: a brain with no body

Strip everything away and there is a language model at the center of what we're building. Text goes in, one chunk of text comes out. That's the entire contract. It has no memory of yesterday. It cannot open a file. It cannot run a command. It cannot even remember what it said thirty seconds ago unless you hand that back to it. It is a pure function: same input, one output, then it forgets everything.

🧠 Metaphor

The model is a brilliant colleague locked in a room with no doors, no windows, no hands, and no memory. You can slide a note under the door and a note slides back — that's all. The colleague is genuinely smart. But smart is useless if it can't see your code, can't touch your files, and forgets the whole conversation the instant you stop talking. Everything we build this week is the room's furniture: a slot to pass files, a pair of hands, a notebook so it remembers, a save-point so a fire doesn't lose the work. The colleague never changes. We build the room around it.

The model as a brilliant colleague sealed in a windowless room: smart, but with no hands, no eyes, and no memory until we build them.

Say that plainly and let it sit. The surprise of the workshop is that the smart part — the model — is the part we don't build. We rent it. Everything we write is the unglamorous room around it. And that room has a name.

The room has a name: the harness

The harness is all the code that wraps the model and turns it from a text-in-text-out function into something that feels like a colleague who gets work done. When you use Claude Code or Cursor or pi, you are mostly using the harness. The model is a commodity underneath — the same one everyone rents. The harness is the product.

🎤 Say this at the board

"Here's the secret of this whole week. The smart part — the model — you cannot build; it took a billion dollars and a data center. But you don't need to. You rent it, for pennies. The part that makes it a coding agent — the part with your name on it — is the harness. That's the part we build. And it's small enough to fit in your head."

We build that harness in exactly five layers, and here is the rule we never break: we never add a layer for its own sake. We add each layer at the exact moment the previous version visibly falls over without it. Every day, the students will feel the pain first, and then we build the thing that fixes the pain. That's the rhythm of the week.

The five layers, one at a time

Let me walk you up the stack the way you'll walk them up it, day by day. Each layer gives the model one power it did not have, and each is roughly one day.

Layer 1 — the loop (Monday). A single question-and-answer is not enough to fix a bug. Real work is reason, act, look at the result, reason again. So the first thing we build is a loop: call the model, let it ask for an action, run that action, feed the result back, and go around again until it says "done." That loop is the heartbeat of every coding agent alive.

🧠 Metaphor

The loop is a cook tasting the soup. Add salt, taste, decide it needs more, add salt, taste again, stop when it's right. A cook who dumps in salt once and walks away is the raw model. A cook who tastes-adjusts-tastes in a loop is the agent. The magic isn't any single action — it's the going around again after seeing the result.

Layer 2 — tools and guardrails (Tuesday). A loop is a heartbeat with nothing to do until the model can actually touch your machine. So we give it hands: read_file, write_file, edit_file, run_bash. Each hand is a tool — a small function the model is allowed to call, described to it with a schema so it knows how to call it. But hands that can edit files can also delete them, so in the same breath we build guardrails: the harness pauses and asks a human before anything dangerous, and a sandbox keeps even an approved mistake from spreading.

🧠 Metaphor

Tools are the hands and the tool-belt. The guardrail is the fire door on the workshop: the work flows freely, but before anything that could burn the place down — deleting files, running a destructive command — a door swings shut and a human has to open it. You don't wire the workshop so nothing can ever happen; you put one strong door at the one dangerous spot.

Layer 2 as hands plus a fire door: the model gets tools to touch your machine, and a single strong gate that stops it before anything destructive.

Layer 3 — the context engine (Wednesday). Every file it reads and every command output it sees gets stuffed back into the conversation so the model can remember it. But the conversation is a fixed-size box — the context window — and on a long task it fills up and overflows. A naive loop just crashes at that wall. So we build a context engine: it watches how full the box is, and when it nears the limit, it summarizes the old turns into a compact digest and keeps going. Alongside it, a memory file (a CLAUDE.md) so the agent starts every run already knowing the shape of your project.

🧠 Metaphor

The context window is a whiteboard of fixed size. As the agent works, it fills the board with notes. When the board is nearly full, a bad agent just... stops, out of room. A good agent does what you do: it steps back, rubs out the twenty scribbled lines, and writes a two-line summary — "we found the bug is a renamed field; we're mid-fix" — freeing the board to keep working. Compaction is erasing the working, keeping the conclusion.

Layer 4 — durability (Thursday). Real agents get interrupted. You hit Ctrl-C, the network blips, the laptop sleeps. If the agent's only memory is a variable in a running program, that interruption throws away a twenty-minute task. So we make the harness write every step to disk — the messages, the tool results, the exact spot in the loop — so that a fresh process can reload the log and replay to precisely where it stopped, instead of starting over.

🧠 Metaphor

Durability is the save point in a video game. Without it, dying at the boss sends you back to the very start — an hour lost. With it, the game quietly saved after every room, so death just reloads you outside the boss door. The running process is disposable, like the console you can unplug; the save file on disk is the real memory. Kill the process, reload the log, and the agent walks right back to where it was.

Layer 4 as save points: every step is written to disk, so a killed process reloads the log and replays to exactly where it stopped.

Layer 5 — orchestration (Friday). Some jobs are too big for one whiteboard. "Audit this whole service for security bugs" is really twenty small investigations, and cramming all twenty into one context window makes the agent lose the thread. So the top agent learns to spawn sub-agents — each a fresh copy with its own clean whiteboard — hand each a narrow task, and fold their answers back. Plus a human-in-the-loop gate for the moves that should never be fully automatic.

🧠 Metaphor

Orchestration is a manager delegating. A manager facing a huge audit doesn't read every file personally — they'd drown. They split it: "you take the login code, you take the payments code, report back." Each junior starts fresh, focused, unburdened by the others' work, and hands up a short summary. The manager stitches the summaries into one answer. Sub-agents are junior colleagues with clean desks.

The one picture that holds the whole week

Now put it all together. This is the drawing you keep on the wall from Monday to Friday, and the single most important figure in the course. Draw it as a stack, bottom to top, and add a checkmark to each layer as the week completes it.

The master map: a borrowed model at the base, then loop, tools+guardrails, context engine, durability, and orchestration — one layer per day, all week on the wall.

🎓 Teaching note

Draw this stack ONCE, live, on the very first morning — bottom box first, then build up. Then leave a copy pinned to the wall (or a slide you can jump back to) all week. Every single day, start by pointing: "here's where we are." End every day by adding a green checkmark to the layer you just finished. By Friday the whole stack is checked, and the students feel the week as a build, not a series of lectures. That running checkmark is worth more than any single explanation.

✨ The click

The number that lands the whole thesis: the model at the bottom took roughly a billion dollars and a data center to make. The five layers on top — the entire harness, the part with your name on it — are, across the week, only a few hundred lines of code you could rewrite on a plane with no internet. "The expensive part you rent for pennies. The part that makes it yours is small enough to hold in your head." Say that and watch the room lean in.

Why this exact order, and not another

Students will ask why we build loop → tools → context → durability → orchestration in that sequence. The honest answer is the best one: each layer is meaningless until the one below it exists, and each becomes painful to live without the moment the one below it works.

You can't have tools without a loop to call them in. You don't feel the context-window pain until your tools produce enough output to overflow the window. You don't need durability until your tasks run long enough that an interruption actually hurts. And you don't reach for sub-agents until a single agent visibly drowns in a job too big. So the order isn't arbitrary — it's the order in which the pain arrives. We build each fix exactly when the students feel the wound.

🏭 In production today

This is not a teaching-only ladder — it's the real anatomy of the tools they use every day. Claude Code has all five: a tool-use loop, a permission system with allow/deny lists and modes, a context compactor (you've seen "compacting conversation…" scroll by), durable sessions you can resume, and a sub-agent dispatcher. pi has the same five in a smaller, readable body — which is why it's our reference: it proves you can hold all five in one head. Cursor and Hermes are the same five ideas again. When a student finishes Friday, they haven't built a toy version of these tools — they've built the actual architecture, just smaller.

⚠️ Where students trip

The number-one confusion in this opening session: students think the model is the agent — that "the AI" is the smart thing doing the work, and the code is just plumbing. Flip it hard and early. The model is a stateless function that forgets everything and can't touch anything. The agent — the thing that reads, reasons, asks, edits, verifies, survives a crash, and delegates — is the harness. Say it as a slogan: "the model is rented; the agent is built." If they leave Monday believing that, every later day makes sense.

The layers as a pain-then-fix ladder: each capability is added at the exact moment the previous version visibly breaks.

A whole session, seen through the map

Close the opening with a concrete story so the abstraction becomes a scene. A student opens a terminal in a real project and types: "the login test is failing — find out why and fix it."

The agent reads the test file, then the source it imports (tools, Layer 2). It runs the test with bash, sees the traceback, and reasons about the cause (the loop, Layer 1). Halfway through, the conversation has grown large from all it's read, and the harness quietly compacts the old turns (context engine, Layer 3). It proposes an edit and pauses to ask before touching your code (guardrails, Layer 2). Each step is written to disk as it goes, so if your laptop slept mid-task it would resume, not restart (durability, Layer 4). And on a bigger job — "audit the whole service" — it would have split the work across sub-agents (orchestration, Layer 5).

▶️ Live demo

If you have a working agent handy (even a rough one), run this exact scenario live in the last five minutes of the opening session — "fix the failing login test" — and narrate which layer is firing as it happens: "that's the loop… that's a tool… watch, here's the permission gate asking me." Students see the whole stack move in one thirty-second clip. That single demo is the promise of the week made concrete: "by Friday, you will have written every piece of what you just watched." Nothing sells the course like seeing the finished thing move.

Every part of that scene is a part they will write. Nothing in it is exotic once each layer is built — and the quiet surprise of the week is how few lines each layer takes.

You can now teach

The model as a brain with no body — a stateless, hands-free, memory-free function — and why the smart part is the part we rent, not build.
The harness as the room built around the model, and the slogan that anchors the week: "the model is rented; the agent is built."
The five layers in order — loop, tools + guardrails, context engine, durability, orchestration — each with a one-line metaphor (cook tasting soup, hands + fire door, whiteboard you erase, video-game save point, manager delegating).
The one stacked map, drawn live and left on the wall all week, with a green checkmark added each day.
Why the order is forced: each layer arrives exactly when the previous version visibly falls over — the pain-then-fix ladder.
The production link: these same five layers are the real anatomy of Claude Code, pi, Cursor, and Hermes — the students build the actual architecture, just smaller.

‹ previousHow to use this handbook next ›Why an agent needs a harness