The Four Layers: Prompt, Context, Harness, Loop
12 concepts · about 50 minutes · nothing to install · the short one you keep coming back to
An agent runs for forty minutes, spends fifty dollars, and produces nothing. Reading the log afterwards, you can see it tried the same three things over and over in slightly different words.
What do you change?
Almost everyone changes the prompt. It is the first thing they look at, and it is the only thing they can edit in ten seconds. So they rewrite it, start it again, and watch it burn another forty minutes.
The prompt was fine. Nothing in that system was ever going to notice that the run had stopped making progress, so nothing ever stopped it. The fix was about eleven words, in a different file, on a layer most people cannot name.
This course gives you the names. There are four: prompt, context, harness, loop. They are not four skills you choose between, and not four rungs you climb. They are four containers, each one inside the next, and each one has a different unit of work. Once you can see them, "my agent is broken" turns into a question with an address: which layer broke?
This is the shortest course in this section on purpose. It is a map, and a map you cannot hold in your head is not doing its job.
You should have driven a general agent at least once, through either door: Claude Code and OpenCode if you work with code, or Cowork and OpenWork if you do not. Spec-Driven Development helps but is not required. Nothing here needs a repository, a database, or an install. A chat tab and one agent you have used before is the whole setup.
📚 Teaching Aid
View Full Presentation — The Four Layers: Prompt, Context, Harness, Loop
Why these words are a mess right now
If the words in this section feel slippery when you read about them online, that is not you. It is a young field that got its vocabulary in the wrong order.
Not long ago there was one layer anybody could touch. You typed a message and read what came back. "Prompt engineering" named the entire skill because the prompt was the entire surface.
Then the tools grew outward, fast. A coding agent handed you a permissions file, a rules file, and hooks: that is a layer around the model, and you can configure it. Schedules and routines arrived: that is another layer around the first, and you can configure that too. Two new surfaces, in not much time at all.
The vocabulary did not keep up. Each surface got named by whoever wrote about it first, and the names collided. "Context engineering" sometimes means the window and sometimes means everything you did before the model ran. "Graph" gets used for three different things, which Concept 11 sorts out. And "harness" is the worst offender: most writing online uses it to mean the harness and the loop together, drawn with one pen.
That would be a harmless argument about words, except for one thing: a missing permission rule and a missing schedule are different bugs, on different surfaces, fixed by different people. One word for both means you go looking in the wrong place, which is exactly what happened in the story above.
So this course does two things. It gives you the four layers as containers. And it gives you a test that keeps working after the words drift again, which they will.
Key words in plain English
Read this once now. Come back whenever a term goes fuzzy. Every one of these gets a full explanation later.
| Term | Plain-English meaning |
|---|---|
| Prompt | The message you send. The ask, the examples, the format, the role. |
| Context window | Everything the model can see while it writes one response. Nothing outside it exists to the model. |
| Curator | Whatever decides what goes into the window, in what order, and what gets left out. |
| Beat | One complete turn of an agent: your instruction, then every tool call it makes, until it goes quiet. |
| Harness | The code around the model that runs one beat. |
| Loop | The system around the harness that starts beats, judges them, and remembers between them. |
| Heartbeat | Whatever starts a beat: a schedule, an event, a condition. |
| Spine | State saved outside the model, so the next beat knows what the last one did. |
| Stopping condition | A testable rule that says the work is finished. Testable by something other than the model. |
| Maker-checker | One agent does the work; a different agent or command checks it. |
| Human gate | A point where a person decides before the run continues. |
| Sub-agent | A helper with its own window that does one job and hands back a summary. |
| Graph | Many of these stacks wired together: what runs next, what state moves along each edge, who checks whom. |
You will meet several of these words again in Loop Engineering and Harness Engineering, which is deliberate. This course is the map. Those courses are the territory: they build what this one only names.
The picture
Containers, not a ladder. Every beat still assembles a prompt. The checker and the human gate sit on the loop, not inside the beat, because the thing that made the work cannot be its own final judge.
And here is the sentence the picture is really saying, which will come back three more times before you finish:
A good prompt fails inside bad context. Good context fails inside a bare harness. A good harness sits idle without a loop.
That is what "each one inside the next" means in practice. Nothing on an inner layer can rescue you from a missing outer one, and nothing on an outer layer can rescue a broken inner one.
Before you read on: ninety seconds that prove the most important claim here
The single sentence this course exists to install is easier to believe once you have watched it happen. Open the agent you already use. Point it at any small real task with a checkable result: a script that should run, a spreadsheet total that should balance, a link that should resolve.
Ask for the work, then read what comes back.
Fix this so it works, then tell me when you're done.
Now, before you trust the answer, go and check the thing yourself. Run the script. Add the column. Click the link.
Often enough that it will bother you, on any task with real surface area, you will find a confident "done, all fixed" attached to work that was never verified. Not because the model lied, and not because your prompt was weak. Because nothing inside that turn was ever going to check. Hold onto what that felt like. Concept 6 is the explanation, and it is the hinge the whole course turns on.
Fifteen minutes: the picture above, Concept 2 (the four units of work), and the table in Concept 9. Pin that table somewhere you will see it during your next bad debugging session.
Fifty minutes: straight through, doing the two short witness exercises and the diagnosis drill at the end.
Later: come back for the drill, not the prose. These recipes are meant to be looked up, not memorized. Exactly one sentence in this course is for memory, and it is at the very end.
Part 1: The shape
Concept 1: Containers, not a ladder
The most common way these four words get drawn is as a ladder. Prompt at the bottom for beginners, loop at the top for experts, and the implied promise is that once you are good enough you graduate from the lower rungs.
That picture is wrong, and it is wrong in a way that costs money.
Every beat still assembles a prompt. A loop that has been running unattended for six months, on a schedule, with a checker and a spine, is still sending a message to a model many times a day. If that message is vague, the loop makes vague work faster and on a timer. You never leave the inner layers behind. You wrap them.
So the relationship is containment. The prompt sits inside the window. The window is assembled for one beat. The beat is started, judged, and remembered by the run.
Where this picture can mislead you. Three wrong beliefs are easy to pick up from a nesting diagram, and it is worth killing them now:
- Outer does not mean later. You do not build these in order. Most of the time you rent three of them and own one, which is Concept 10.
- Outer does not mean more important. A careless prompt inside a beautifully engineered loop produces garbage on a schedule, with a receipt. The layers are not ranked. They are nested.
- These are not the same thing at four sizes. A nesting diagram can suggest four versions of one object, like measuring cups. They are four genuinely different objects, and what tells them apart is the next concept.
Concept 2: The unit-of-work test
Each layer is defined by the piece of work it is responsible for. Get these four straight and you can identify any of them in the wild, no matter what someone decided to call it.
| Layer | Unit of work | In plain words |
|---|---|---|
| Prompt | One model call | The thing you typed and hit enter on. Change the words and it is a different prompt. |
| Context | The window | Everything the model can see while it answers that one time: your message, the files, the earlier turns, the rules file, the tool results. |
| Harness | One beat | The agent rarely answers once and stops. It calls a tool, reads the result, thinks again, calls another. All of that, from your instruction until it goes quiet, is one beat. The harness is the code that runs it. |
| Loop | The whole run | What happens when nobody is typing. Something starts a beat. Something decides whether the beat's work was any good. Something remembers between beats. |
Now the test, and this is the part worth keeping when the vocabulary changes again:
When a blog post, a vendor, or a job description says "harness" or "context engineering" or "the agent loop," do not argue about the word. Ask: what unit of work are they talking about? One model call, the window, one beat, or the whole run?
If someone's "harness" includes the schedule, they have drawn two of this book's layers as one. That is not wrong of them; it is just a different map. Now you can translate instead of getting confused.
Part 2: The four layers, one at a time
Concept 3: Prompt, the unit is one model call
The prompt is the message you compose: who the model should be, what you want, what good looks like, examples of it, and the shape the answer should come back in. All of that is a single input, and it produces a single response.
The craft here is narrower than most people think. You are looking for the weakest ingredient and fixing only that one. If the shape of the output is wrong, add an example of the right shape. If the tone is off, name the audience. Rewriting all five ingredients at once tells you nothing about which one was the problem. AI Prompting in 2026 covers this layer properly.
This is the layer people over-invest in, and there are two honest reasons for it. It is the only layer you can practise without writing any code. And it is the only layer you can edit in ten seconds. Both of those are genuinely good things about it. Both become a trap the moment something is on fire, because under pressure people reach for what is easy to change rather than for what broke.
What it looks like when the prompt really is the broken layer: the model clearly understood the task and did roughly the right work, but the answer comes back in the wrong shape, at the wrong length, in the wrong voice, or missing a section you assumed was obvious. Nothing is factually wrong. It just is not what you asked for, and rereading your own words you can see why.
Concept 4: Context, the unit is the window
The window is everything the model can see while it writes one response. This is worth taking literally. A file you did not attach does not exist. A conversation from yesterday does not exist unless something put it back. The model is not withholding; it genuinely has nothing else.
Which creates the problem that defines this layer. There is always more material than fits, so something has to choose what goes in and in what order. That something is the curator, and whether or not you ever write one, a curator exists. Three jobs land on it, and the window forces all three:
Order comes first. Position changes how strongly material lands. Models attend more reliably to what sits at the beginning and end of a long input than to what is buried in the middle, a result documented well enough to have its own name, "lost in the middle."1 So burying the one constraint that matters in paragraph nine of an attachment is a real decision you made, even if you did not think you were making one.
Compression comes next, and it is not free. Summarizing forty pages into four is how you fit them, and a summary that dropped the exception cannot be un-dropped later. The information is gone from the run. This is the layer's quiet tax: every compression is a bet about what will not matter.
Dropping comes last, and it is a policy. Something has to decide what leaves when the window fills. If you do not set that policy, your harness will set it for you, at the least convenient moment, using a rule you never read.
Here is a test you can run on any setup in a minute:
Point at any document in your window and say which rule put it there. If the honest answer is "the retriever returned it," you have a search box, not a curator. That is fine for some jobs and quietly fatal for others. Give Your AI Searchable Context is where the retrieval side actually gets built; Agentic Coding, Parts 2 to 4, is where you learn to manage a window by hand.
What it looks like when context is the broken layer: the answer is fluent, confident, and factually wrong. Often it is correct about something else, an older version of the file, a different customer, the example in the docs rather than your case. That combination, confident plus wrong plus plausible-adjacent, is close to a signature.
Watch it yourself (two minutes). Take a question about a document you know well. Ask it twice, in two separate fresh chats. In the first, paste the whole document. In the second, paste only the first third and ask the same question.
Here's the document. Based only on what I've given you, what does it say about [the thing that lives in the last third]?
The second chat will answer. It will usually answer confidently. That is not the model being bad; that is the window being the whole world. You just changed the answer without changing a single word of the prompt.
Concept 5: Harness, the unit is one beat
You give one instruction. The agent reads three files, runs a command, reads the error, edits something, runs it again, and then goes quiet. You typed once. Roughly a dozen things happened. That whole stretch is one beat, and the harness is the code that runs it.
Its job list is short and unglamorous. Assemble the context. Call the model. Run whatever tools the model asks for. Feed the results back in. Handle the errors. Go again until the model stops asking.
You are already using one. Claude Code ships a harness. So does OpenCode, and so does Cowork. Every permission prompt you have ever approved, every rules file that got read at startup, every automatic check that ran before a commit, all of that is harness. Harness Engineering is the course that teaches you to build one on purpose rather than inherit one by default.
One thing here surprises people, and it matters more than it looks.
Sub-agents look like tools. They are not. A tool call goes out and comes back with a result: a file's contents, an API response, an error. A sub-agent opens its own window and runs its own beat. It is a nested copy of this entire stack, sitting inside one step of yours.
That buys you something real. Forty documents can be read by the sub-agent and stay out of your window entirely, and you get back three paragraphs instead of forty pages. It also costs you something real, and the cost is easy to miss: what comes back is a summary, written with full confidence, including the parts the sub-agent got wrong. You did not see the forty documents. Neither will anything downstream. The confidence of the summary is unrelated to the accuracy of the reading.
Concept 6: The limit that defines the harness
This is the hinge. Everything before it was description. Everything after it is consequence.
A runtime can stop a beat for plenty of reasons. A timeout fires. A token ceiling is hit. An exception is thrown. A permission gets denied. The model decides it is done. Notice that not one of those proves the work succeeded. They are all just reasons the beat ended.
Which leaves exactly one signal:
The only success signal a maker beat has by itself is the model's own claim that it is finished.
It edits a file, writes "done, all fixed," and stops without ever running anything. The beat ended. The task did not. This is what you watched happen in the ninety-second exercise near the top of this page.
Make it concrete with something that has real money attached. An agent is reconciling a bank statement. It queries the ledger, proposes forty matches, and reports that the statement balances. It never added the two totals. The beat ran perfectly: context assembled, tools returned, no error raised, no rule broken, no permission denied. Every signal available inside that beat says success. The claim is still false.
Sit with why no prompt fixes this. You can write "verify your work before reporting" in capital letters at the top of every message you send, and sometimes it will help, and sometimes the model will write "verified" without verifying, because writing "verified" is also just text. The thing that would catch this is not inside the beat. It cannot be, because a maker checking its own work is still the maker.
So the check has to come from outside, which means it belongs to the next layer out. That is not a design preference. It falls out of what a beat is.
Concept 7: Loop, the unit is the whole run
The loop is everything the beat cannot supply for itself.
A heartbeat starts each beat. A schedule at nine in the morning, an event when a pull request opens, or a condition that keeps firing until something is true. Without one, you are the heartbeat: you type, and when you stop typing, the work stops.
A spine is state saved outside the model, so the next beat knows what the last one did. Usually this is boring and that is the point: a file listing what is done, what is in progress, and what needs a person. The model has no memory between beats. The spine is the memory.
Outside stops, and this is where the loop earns its keep. Four of them, and the thing they have in common is the whole design:
- A success condition a command can prove. Not "the agent says the tests pass." The tests pass.
- A limit on beats, on spend, and on minutes. A ceiling that does not care how promising the next attempt sounds.
- A no-progress check. Something that notices when three beats in a row changed nothing and stops the run.
- A checker that is never the agent that made the work. This is the maker-checker rule, and Concept 6 is the reason it exists.
Read that list again and notice what is absent: none of them asks the model whether it is finished. That is the entire idea. Every one of them is a fact something other than the maker can establish.
Now go back to the story this course opened with. Forty minutes, fifty dollars, the same three things over and over. There was no no-progress check. The prompt was never the problem, and forty more minutes of prompt rewriting was never going to become one. Loop Engineering is where you build this layer, and Trusting the Checker is where you find out whether the checker you built is any good, which turns out to be its own hard question.
Concept 8: The human gate is an exit, not a stop
There is one more way out of a run, and it is a different kind of thing from the four above.
The stops are ways for a run to fail safely. The gate is a way for a run to succeed with help.
The reason this matters is a single idea that is easy to say and hard to hold onto: ambiguity is not an error.
An agent that meets a genuinely two-sided decision has not malfunctioned. Invoice 4471 matches two payments and both score 0.52. That is not a bug in the matcher; that is what the data looks like. But without a gate, the agent has exactly two options, and both are bad. It can fail, and throw away nine passes of legitimate work. Or it can guess.
Guessing is the dangerous one, and this is the part worth internalizing, because it runs against instinct. A crash is loud. A guess is silent, and it comes out looking exactly like a correct answer: same format, same confidence, same place in the report. Nobody downstream can tell the difference. A run that fails is a run you fix. A run that guessed is a number in a spreadsheet that is quietly wrong.
A gate is written in advance, not decided in the moment. The triggers are the ones on the left of the picture: confidence below a line you set, a value above a limit you set, or any action that would be hard to undo. And the answer does not end the run. It re-enters as new evidence, and the run continues from where it paused.
Part 3: Using the map
Concept 9: Which layer broke?
Here is the payoff. Each layer fails with its own signature, so the symptom points at the surface.
| What you see | Where to look first | What to change |
|---|---|---|
| Output shape is wrong, or the tone is off, but it understood the task | Prompt | The weakest ingredient: examples, instructions, output shape |
| The answer is confident, fluent, and factually wrong | Context | The curator: what got in, in what order, what got dropped |
| It reports success it never demonstrated, or a failed tool call passes unnoticed | Harness | The tools, the error handling, and what counts as a finished beat |
| Wrong answers reach a person or a system unchecked | Loop | The checker, and whether it has ever failed anything |
| It never stops, stops too early, or guessed when it should have asked | Loop | The stops and the gate |
Two honest notes on this table.
It is a search order, not a verdict. Failures cross boundaries all the time. Read every row as "look here first," not as "the blame lands here." Concept 12 goes into where it gets genuinely murky.
The trap it exists to break. Most teams debug at the wrong layer for a completely predictable reason, and it is not stupidity. An agent spends fifty dollars repeating itself, and the response is to rewrite the system prompt. The prompt was fine. There was no no-progress check. But the prompt is the layer you can edit in ten seconds, and under pressure people reach for what is easy to change rather than for what broke. Naming the layer out loud, before touching anything, is the whole discipline. It costs five seconds and it is the difference between one fix and six.
Concept 10: Which layers do you actually own?
You do not build all four on every project. Much of the time you are renting three of them, and knowing which is which changes what advice even applies to you.
| Layer | Mode 1: solving a problem with a general agent | Mode 2: manufacturing a worker |
|---|---|---|
| Prompt | Mostly yours. The platform owns its own system instructions and tool descriptions. | Yours, written once and reused. |
| Context | Partly yours: what you attach, when you clear. Compaction and retrieval belong to the harness. | Yours. You write the curator. |
| Harness | Rented, and partly configurable through tools, skills, hooks, and project instructions. | Yours. |
| Loop | Mostly rented. The platform sets the loop, though it may expose caps and approval settings. | Yours. Every stop is something you wrote. |
In Mode 1, "add a no-progress check" is not an instruction you can act on. There is no file for it. Your job at the outer two layers is a different one: know the rented behaviour. Where does your harness compact the window, and what does it throw away when it does? What does it retry silently? What happens when it runs out of room mid-task? Those are answerable questions about a product you already use, and the answers change how you work.
In Mode 2, all four are yours, and nobody is going to cap your beats for you.
Reading a page like this in Mode 1 and concluding "I already do all of this, because my tool does all of this."
Your tool does it for its own work. The worker you are about to build has no tool doing it for yours. Claude Code caps its own beats; it does not cap the loop you write. That gap is exactly where a demo turns into a production incident.
Concept 11: Where graphs fit
Graph engineering is the most talked-about word in this space right now, and the first thing to say about it is what it is not.
It is not a fifth ring around the other four. The four layers are scopes of one execution path: one message, one window, one beat, one run. A graph is a different kind of thing entirely. It is a topology: what runs next, what state passes along each edge, and who is allowed to check whom.
The thing to get right is what a node can be, because this is where the word gets oversold. A node is not necessarily an agent. It may be a plain function, a router, one tool call, one model call, one beat, a whole loop, or a full agent. A human gate is a node. So is a measurement that no loop is allowed to argue with. When enough of the nodes happen to be complete agents, you have a multi-agent system, but that is one case rather than the definition.
Three different things get called graphs, and this book teaches all three:
- An execution graph decides what runs next and what state moves between steps.
- A memory graph keeps entities, findings, and their sources alive beyond the run that produced them, so a later agent can query what an earlier one established.
- A governance graph records which components feed, check, approve, and constrain which others. A graph of loops that only ever reads its own reports is perfectly consistent with itself and grounded in nothing.
Why the renewed attention, when graphs are older than computing? Because a node can now be adaptive rather than fixed. One graph can wire deterministic steps and agentic loops into the same governed workflow, which was not worth doing back when every node was a single model call. The four layers are what make an agent substantial enough to serve as one powerful kind of node. Not every node needs to be one.
Two cautions worth carrying, both from people who measured rather than guessed. Anthropic reported from its own multi-agent research system that agents typically use about four times the tokens of a chat, and multi-agent systems about fifteen times.2 Agent-heavy topologies only pay when the task is worth that multiplier. And Anthropic named the limit plainly: work where all the agents need the same context, or where the parts depend heavily on each other, is a poor fit today, and they specifically included most coding in that.3
Graph Engineering is where this gets built, and it is honest about telling you when not to build one.
Concept 12: When the framework fights you
A map you never argue with stops being a map and becomes a ritual. So here is where this one gets uncomfortable, on purpose.
Some failures are genuinely two-layer. A dropping policy that quietly discards the oldest turns is a context decision, and it may only ever bite because the loop lets runs go long enough to fill the window. Which layer broke? Both, honestly. You will find the cheaper fix on one of them, and which one is cheaper depends on your system, not on this table.
Some diagnoses point at one layer and place the fix on another. This is the most useful case, and it is not a flaw. When an agent reports success it never demonstrated, the diagnosis is layer 3, because that is a fact about what a beat can know. The fix is layer 4, because an outside checker is the only thing that can catch it. The framework did its job precisely when it sent you somewhere other than where the symptom appeared.
Some failures are not any of the four. Sometimes the model simply cannot do the task at the quality you need, and no arrangement of containers conjures a capability that is not there. Naming layers is a way to stop guessing. It is not a way to make a weak model strong. If you have genuinely cleared all four and the work is still bad, the honest next moves are a better model, a smaller task, or a different approach, and Trusting the Checker is how you find out which.
And not every project wants all four. A one-off task you will run once does not need a loop, and building one is its own kind of overshoot, expensive in exactly the way this section keeps warning about. The layers describe what exists. They do not oblige you to build each one.
Part 4: Practice
The drill: name the layer
Eight failures. For each, name the layer you would look at first and the one change you would make. Write your answer down before opening the key, because recognizing an answer is much easier than producing one, and only one of those is the skill.
1. You asked for a competitor summary as a table with five named columns. What came back is three excellent paragraphs of prose. The content is accurate.
Answer
Prompt. The model understood the task and did the work; only the shape is wrong. The fix is an example of the table you want, not a longer explanation of why you want a table. This is the layer's cleanest signature: right work, wrong container.
2. Your agent confidently explains that your pricing tier caps usage at 5,000 requests. Your pricing page says 50,000. The agent read the page.
Answer
Context. Confident, fluent, and wrong about a document that was supposedly in the window is close to a signature. Something got compressed, truncated, or replaced by an older copy. Run the curator test: which rule put that page in the window, and did it put in all of it?
3. An overnight run reports "all tests passing, changes committed." In the morning the test suite has never been run and the build is red.
Answer
Harness for the diagnosis, loop for the fix. This is Concept 6 exactly: the beat's only success signal was the model's own claim, so nothing inside the beat could catch it. That tells you the fix cannot live inside the beat either. You need an outside stop: a success condition a command can prove. If you tried to solve this by adding "always run the tests" to the prompt, reread Concept 6.
4. A run burns through your budget in an afternoon. The log shows the same three approaches attempted repeatedly with slightly different wording.
Answer
Loop. No no-progress check, and probably no spend limit either. This is the story this course opened with. The prompt is the tempting place to look and it will waste your afternoon too.
5. An invoice-matching agent processed 300 invoices overnight. It reports 300 matched. Spot-checking finds a handful where two payments were equally plausible and it picked one, silently.
Answer
Loop, specifically the missing gate. Nothing malfunctioned: the agent met a genuinely ambiguous decision and had only two options, guess or fail. It guessed, and the guess reads exactly like the 290 correct answers. Write the trigger in advance (confidence below a line, value above a limit) and route those cases to a person.
6. You sent a sub-agent to read forty support tickets. It came back with a clean three-paragraph summary. Two of the claims in it turn out to be wrong.
Answer
Harness. A sub-agent is a nested copy of the whole stack, not a tool call, so its summary carries full confidence regardless of how well it read. You did not see the forty tickets and neither will anything downstream. The fix lives in what you require it to hand back: quotes, ticket IDs, receipts you can check, rather than conclusions you have to trust.
7. A long session goes well for twenty turns. Then the agent starts contradicting a decision you both agreed on early, as if it had never happened.
Answer
Context. The window filled and something left. The dropping policy was set by your harness, not by you, and it dropped the thing you most needed kept. The fix is to make the decision durable outside the conversation (a rules file, a spec, a note that gets re-attached) rather than trusting it to survive as chat history.
8. You have cleared all four layers on a hard research task. The prompt is precise, the window holds exactly the right material, the harness is verified, the loop stops and checks properly. The output is still mediocre.
Answer
None of them. This is the case Concept 12 exists for. The layers describe where things can break; they do not manufacture capability. Honest next moves: a stronger model, a smaller and sharper task, a different approach, or accepting that this one needs a person. A framework that always has an answer is a horoscope.
Now do it on your own failure
The drill above is calibration. This is the transfer, and it has no answer key, because your system is the only place the answer exists.
Think of the last time an agent produced something wrong or expensive in real work. Then answer three questions, in writing, in this order:
- What is the unit of work that went wrong? One model call, the window, one beat, or the whole run?
- What did I actually change in response? Be honest about whether that was the same layer.
- What would have caught it? Name the specific thing, on the specific layer.
If you want to argue it out, this works well in a chat tab:
Here's an agent failure I had recently: [describe what you asked for, what came back, and how you found out it was wrong]. I'm trying to work out which of four layers broke: the prompt (one model call), the context window (what the model could see), the harness (one beat, the code that runs tools and decides the beat is over), or the loop (the whole run: what starts it, what stops it, what checks it). Ask me whatever you need to narrow it down, then tell me your best guess and what would have caught it earlier. Push back if I've picked the wrong layer.
The reason this last exercise matters more than the drill: the eight cases above were written to have clean signatures. Your real failure was not. Getting it wrong once, on something you actually lived through, teaches more than getting all eight right.
What to carry out of here
One line per concept, and then the sentence.
- Concept 1. Four containers, each one inside the next, not four rungs on a ladder. Every beat still assembles a prompt.
- Concept 2. Each layer is defined by its unit of work: one model call, the window, one beat, the whole run. That question survives any change in vocabulary.
- Concept 3. The prompt is one model call. Fix the weakest ingredient, not all five. It is the easiest layer to edit, which is exactly why it gets blamed for other layers' bugs.
- Concept 4. The window is the model's entire world for one response, and a curator always exists: it orders, compresses, and drops. Point at any document and name the rule that put it there.
- Concept 5. A beat is one instruction and everything that follows until the agent goes quiet. Sub-agents are not tools; each one opens its own stack and hands back confidence it did not earn.
- Concept 6. The only success signal a maker beat has by itself is the model's own claim that it is finished. Nothing inside the beat can fix this.
- Concept 7. The loop supplies what the beat cannot: a heartbeat, a spine, and four outside stops, none of which ask the model whether it is done.
- Concept 8. The human gate is an exit, not a stop. Ambiguity is not an error, and a guess is more dangerous than a crash because it looks like an answer.
- Concept 9. Each layer fails with its own signature. Name the layer before you reach for a fix.
- Concept 10. In Mode 1 you rent three layers and configure one. In Mode 2 all four are yours. "My tool does this" is about your tool's work, not your worker's.
- Concept 11. Graphs are not a fifth layer. They are a topology, the nodes are not all agents, and the token multipliers are real.
- Concept 12. The map is a search order, not a proof. Some failures cross layers, some are the model itself, and not every project wants all four.
And the one sentence, the only thing on this page worth memorizing:
A good prompt fails inside bad context. Good context fails inside a bare harness. A good harness sits idle without a loop. So when something breaks, name the layer before you reach for a fix.
That is why an agent that works in a demo so often dies in production. The demo needed only the inner layers. The outer ones were never built. The model was not the problem. The layers around it were missing.
Where to go next
You now have the map. The rest of this section is the territory, and each course owns exactly one layer:
- Harness Engineering builds layer 3, where a request you make becomes a rule that is enforced.
- Loop Engineering builds layer 4: the kinds of heartbeat, the spine, maker-checker, and the human gate.
- Trusting the Checker answers the question layer 4 raises the moment you build it, which is whether the checker at its centre is any good.
- Graph Engineering is the topology past one execution path, and it assumes the other two.
- Leaving the Laptop closes the section: once a loop is trusted, where should it actually live?
Layers 1 and 2 have homes too, behind you: AI Prompting in 2026 for the prompt, and Agentic Coding, Parts 2 to 4, for the window.
The people shipping working agents are not the ones writing the cleverest prompts. They are the ones whose loops know when to stop, and when to ask.