You could stop after chapter six and you would already be operating in a different league from where you started. You have the surfaces, the context, the skills, the agents, and you have seen them wired into a system. That is genuinely enough to change how you work. So read this chapter as a view of the next mountain, not a task for tonight. I am writing it because once you have built context, there is a horizon past it, and you should be able to see it even if you do not walk to it yet.
Back in chapter one I named three eras. Prompt engineering, the blank box. Context engineering, building the world the AI works inside, which is most of this book. And loop engineering, which I promised to come back to. Here it is.
The one new idea
Everything so far has an invisible assumption baked into it: the AI does the work once, and then you check it. It drafts, you review. It researches, you read. Even an agent running a whole job runs it once and hands it back. There is a single loop, and you are the one closing it, every time, by looking at the output and deciding if it is good.
Loop engineering is what happens when the AI closes that loop itself. It drafts something. It checks its own draft against a set of criteria you defined. If the draft fails the criteria, it revises, and checks again. Only when the work passes does it come to you. You are no longer reviewing the first attempt. You are reviewing the third, the one that already survived its own inspection.
That is the whole idea. An agent that does not just produce, but produces, judges its own production against a standard, and fixes it before you ever see it. Say it plainly: the AI stops handing you first drafts and starts handing you drafts that already passed a test.
What changes about your job
This is the part worth sitting with, because it is a real shift in what you do all day.
In the prompt era, you do the work with help. You are the worker, the AI is the assist. In the context era, most of this book, you set up the AI to do the work well and then you review it. You are the reviewer. In the loop era, you stop reviewing every output and start defining what "good" means, then let the loop chase it. You are the designer of the standard and the inspector of the system, not the checker of each piece.
Put it as a sentence, because it is the sentence this whole book has been walking toward. Prompting is you doing the work. Context is you setting up the work. Loops are you designing the work and defining the test it has to pass. Your leverage moves up a level each time, and at the loop level you are barely touching the output at all. You are shaping the rules the output must satisfy.
Two loops made concrete
Abstract talk about loops helps nobody, so here are two you can actually picture. I am naming the mechanism behind each one exactly once, so that if you want to go looking, you know what to search for. Beyond that one word, I am keeping this conceptual, because the point of this chapter is to show you the horizon, not to hand you a build guide.
The self-checking draft. You ask an agent to write a post. Before it shows you anything, it checks its own draft against a short list you gave it. Does this speak to the right buyer. Does it follow a structure that works. Does it avoid the three tics I always cut. If the draft fails any of them, it rewrites and checks again, on its own, and you receive the version that passed. The mechanism here has a name, a self-check against criteria, and that is the whole thing to remember: the criteria are the test, the agent runs itself against the test. You have felt the pain this removes. You know the grind of getting a first draft and hand-fixing the same problems every time. This is that grind, handed to the loop. You stop fixing the same things and start defining, once, what "already fixed" means.
The scheduled pulse. The second kind of loop is not about self-correction, it is about self-starting. Remember the weekly note in chapter six, the one that reads what has been working and writes a summary before I even show up. Nobody triggers that each week. It runs on its own, on a rhythm, and the mechanism has a name too, a scheduled task. That is the second word to remember. A loop does not only fix its own work, it can run without you being there to start it. The work happens while you are asleep, and you meet the result in the morning.
Two mechanisms, two words. A self-check against criteria, and a scheduled task. Between them they describe most of what loop engineering feels like in practice: work that improves itself before you see it, and work that starts itself before you ask.
Where I am deliberately stopping
I am not going to teach you to build these here, and the restraint is on purpose. This chapter exists to change what you think is possible, not to add another setup to your weekend. You needed to see that the road continues past context, because knowing loops exist changes what you build in the meantime. You will structure your context and your skills a little differently once you know that someday an agent might run them in a loop against a standard you set. The horizon reshapes the ground you are standing on, even before you reach it.
So here is the honest map. The six chapters are enough to transform how you work, starting this week. Loops are the next mountain, and from where you are now standing, having built real context, you can finally see it. That is exactly the right place to be. You do not climb it by reading a paragraph. You climb it by building the foundation first, which you now know how to do.
When you do want to climb it, and want a hand doing it, that is the work I do. I help operators and small teams build their own version of this, the context, the skills, the agents, and eventually the loops, wired to their actual work rather than a generic template. If that is where this book leaves you, wanting the built system rather than just the map of it, that is what Build and Coach is for, and you know where to find me.