On 7 June 2026, Peter Steinberger — the developer behind OpenClaw — posted two sentences.¹

“Here’s your monthly reminder that you shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”

No diagram. No repository. The AI-coding timeline spent the following week arguing about it, and then it stopped arguing, because he was right.

I want to be careful with that sentence, because it is his and it should stay his. It is not our reframe, we did not think of it, and the whole of this book sits downstream of somebody else’s twelve seconds of typing. What follows is an argument about what the sentence left out — which is only interesting because the sentence itself is correct.

What actually ended

Name the old posture precisely, because the reframe is meaningless without it. You wrote a prompt. You read what came back. You typed the next thing. The agent was a tool and you held it the entire time, one turn after another, and when you stopped typing, everything stopped.

The thing being replaced was never the prompt. It was you. You were the loop — the component that noticed the last output, decided what came next, and re-issued the instruction. Steinberger’s line is an observation that the most-loaded component in the system was a human being doing clerical control flow.

The new posture is a small system that finds the work, hands it out, checks it, records what is done and decides the next thing, while you watch instead of type. That is a genuine architectural upgrade over narrating every step to an agent like you are dictating to a secretary.

Three voices, one claim, no dissent

The consensus assembled fast, and it deserves crediting in order.

Addy Osmani named the discipline. His essay Loop Engineering gave the pattern a handle and an architecture — scheduled automations for discovery and triage, worktrees for parallel isolation, skills that encode project knowledge, plugins and connectors, and sub-agents that separate ideation from verification.² It is the best public treatment of the subject and this book will argue with it later, so it is worth saying now that it gets almost everything right.

Boris Cherny, who built Claude Code, is reported to have said the same thing from the vendor side — that he no longer prompts the model, he writes the loops that prompt it.³ I have not found a primary transcript for that one, so treat it as reported rather than quoted, and do not let any argument rest on it.

What is striking is the absence of a real counter-position. Within a week the field had gone from “interesting” to “obviously”. The reframe won.

Winning that fast is the problem

Here is the difficulty with consensus arriving before the design work does. Design the loop is a change of unit, not a design. It tells you what you are building. It does not tell you what a loop is made of, which parts you actually get to choose, or which of those choices decides whether the thing is worth running at all.

Seven weeks on, the public answer to those questions is still, in substance: pick a trigger, write a better prompt, add some tools, let it run.

That is designing two surfaces out of five.

A loop has five surfaces you design, or five surfaces you default. The next chapter names all five and puts them in the order that matters. The nine chapters after that take them one at a time, run them over two loops that actually ran, and finish with an audit you can apply tonight.

What this book is

It is worth being blunt about the shape of what you are holding, because it is unusual for us.

This is a map, not a territory. Every one of the five surfaces has a deeper room behind it — in several cases an entire book of ours, written since the first edition of this one — and the job here is to hand you the anatomy, the ordering, and the right door. When a concept has its own home, you will get its essential claim in a sentence or two and then a link, and I will not be re-teaching it. A reader who finishes this book and reads nothing else will have the map and none of the territory. That is the intended outcome, not a shortcoming.

Seven weeks is a long time

The first edition of this book went out a fortnight after the original post. It argued that the axis predicting whether a loop is worth running is not what starts it but who holds its state machine — where “what is done, what is next” lives between turns.

In the weeks since, that axis has turned up as load-bearing machinery in three later books of ours, written from three different directions — one from architecture, one from scheduling, one from overnight operations — and one of them names it explicitly as the idea it is reusing. I will show you that receipt properly in Chapter 5 rather than repeat the argument here.

The calibration point is not that we were first. The discourse got to the reframe its own way and compressed it better than we did. The interesting part is what seven weeks of building corrected, and this edition puts two corrections in the open rather than quietly revising them out.

So the reframe is settled and the design question is wide open. Everyone agrees you should be designing the loop. Almost nobody has said what a loop is made of.

Let us do that.

Strip any agentic loop — a bash one-liner, an overnight sweep, a watcher that fires on a red build, a full orchestrator running a dozen pipelines — and the same five surfaces are underneath. They are not stages of a pipeline; the loop does not pass through them in order. They are the five things you decide about it, whether or not you notice you are deciding.

The anatomy

Four of those names will feel familiar even if you have not used them. The fifth will not, so define it here: residue is what the loop leaves behind for the next loop to read. Not its output — its output is for you. Residue is the part of the output that is structured well enough that a future run can load it and start from a better position than this run did. Most loops have none, and most people running loops have never been asked the question.

Two smaller clarifications before the argument. The aim is not the prompt; a prompt is a message and an aim is a property of the loop, which is Chapter 4’s job. And the closer gets its proper definition in Chapter 6 — for now, read it as “the thing with the power to send the work back”.

The ordering rule

The anatomy on its own is a taxonomy, and taxonomies are cheap. What makes it a diagnostic is the ranking.

That is a strong claim about a whole field, so it should be argued against the best available work rather than the worst.

What the best public architecture looks like

Osmani’s Loop Engineering names five components: scheduled automations for discovery and triage; worktrees so parallel agents do not tread on each other; skills that encode project knowledge; plugins and connectors for the outside world; and sub-agents that separate ideation from verification. Then — plus — persistent state, in markdown files or a Linear board, living outside conversations, because model context resets between runs.²

Read it back and look at the shape rather than the content. Everything you need is in there. Durable state is present, correct, credited — and sixth, as an addendum to a numbered five. Verification is present too, folded into component five as a property of sub-agents, and reinforced elsewhere in the piece with the sharpest line anyone has written on the subject: the model that wrote the code is way too nice grading its own homework.²

So the complaint is not omission. It is rank. And rank matters because lists teach ordering: people build the numbered things and get to the “plus” when there is time, and there is never time.

The correction was in the replies on day one

The second piece of evidence is more damning, because it did not require anyone to write an essay. Under Steinberger’s original post, one reply landed the whole of surface four in three sentences:

“designing the loop is half of it. the other half is putting something in the loop that can say no: a test, a type check, a real error. a loop with nothing to push back is the agent agreeing with itself on repeat.”

That was available on day one, to everyone, for free. Seven weeks later it is still the fifth bullet.

Why five, and not four or six?

Fair question, and worth answering before someone else does.

Four collapses residue into state, and they are genuinely different. State is what survives this run — enough for a fresh worker to resume. Residue is what the next run can read to start smarter. A checkpoint file is state and not residue: it is perfectly durable and it teaches the next run nothing it did not already know.

Six starts adding implementation. Which model, how many agents, what the budget is, which tools are mounted — all real decisions, all choices made within a surface rather than surfaces of their own. “How many sub-agents” is a question about the shape of a single pass. “What can say no” is a question about the loop.

That asymmetry is the whole explanation for the bad ordering. It is not laziness and it is not ignorance. It is that three of the five surfaces have no visible state when they are working, so nothing in the daily experience of building a loop pushes you toward them.

Everyone designs the alarm clock. Nobody designs the memory.

The next five chapters take the surfaces one at a time, in order. Then Chapter 8 fills the card in for two loops that actually ran, Chapters 9 and 10 deal with the two things this book got wrong, and Chapter 11 hands you the audit.

Start with the one everybody already designs — because demoting it properly is what makes room for the rest.

The first edition of this book sorted agentic loops into four types by what starts them, and treated that sort as its structure. Seven weeks of building later, the sort has barely earned its keep. I have not once looked at a struggling loop and thought: ah, wrong trigger class.

So the demotion starts here, aimed inward. A book that demotes somebody else’s framing while quietly keeping its own is doing something worse than being wrong.

What the trigger genuinely buys you

Give it its due first, because it is not nothing. A trigger decouples the loop from your attention. A loop that fires on a clock or on an event runs while you sleep, and that is the entire economic premise of overnight work: cognition happening on a different schedule from yours, with the results waiting when you wake up.

That is real value, and it is the value the whole discourse is excited about. It is also, as far as this book is concerned, the only thing the trigger decides.

The four types, said once

For completeness, here is the taxonomy, compressed into the paragraph it deserves.

Self-paced linear is the Ralph loop, and it is worth crediting properly because it is where most people’s intuition about agentic loops comes from. Geoffrey Huntley coined it in July 2025: “Ralph is a technique. In its purest form, Ralph is a Bash loop.”⁶

Huntley’s own description is the honest one: “a bash loop that feeds an AI’s output (errors and all) back into itself until it dreams up the correct answer. It is brute force meets persistence.” His verdict on his own invention is better still — deterministically bad in an undeterministic world — and his operating rule is the one to keep: sit on the loop, not in it.

The non-obvious property inside that one-liner is worth extracting, because people mistake it for a limitation. Every iteration starts with a fresh context. That is the point, not a side effect. Practitioners report model quality degrading once a session fills up — the folklore name is the Dumb Zone, somewhere past roughly a hundred to a hundred and fifty thousand tokens. Treat that as a practitioner observation with a real mechanism behind it rather than a measured threshold; nobody has handed me a study. A bash loop sidesteps the whole problem by throwing the context away each pass.

Scheduled is the same shape with a clock instead of a completion check. Event-triggered fires on external state changing: a check goes red, a review comment lands, a new head commit appears. Agentically-initiated is the loop that starts its own loop, which is a genuine category change and gets Chapter 9 to itself.

There. That is the taxonomy, and this book will not use it again as a structure.

Handing the scheduled loop over

This is the first place the book does the thing it promised in Chapter 1, so let me do it visibly.

The scheduled loop is no longer this book’s to teach. It has its own book now, and that book is better on the subject than a chapter here could be: the externalised-liveness pattern, built from a goal with a self-checkable done-test, an explicit instruction to repeat until finished, and a self-deleting wake-up that asks the running job whether it is actually finished — with the cadence tuned to the prompt-cache window so the check-in is nearly free.

The one thing you need from it here is the layering, because it is the cleanest statement of the point Chapter 5 is about to make:

The full treatment — the three-line recipe, the cadence arithmetic, why thirty minutes rather than sixty — is in Ask Yourself If You’re Finished: Cron as the Poor Man’s Orchestrator. I am not going to restate its numbers here, for a simple reason: that research is not mine, and a figure repeated without its working is a rumour with a footnote.

Why the trigger does not sort

Here is the claim that earns the demotion, and it is testable against loops you already run.

Two loops with identical triggers can differ completely in value. A nightly sweep that writes structured findings into a durable map, gated by a check it cannot see, is a compounding asset. A nightly sweep that appends prose to a chat log is a way to spend money while asleep. Same trigger. Same cadence. Nothing in common that matters.

Now run it the other way. Two loops with identical state architecture and identical closers rarely differ much in value, whatever wakes them. Fire one on a clock and one on a webhook and you have changed the latency, not the machine.

The trigger does not sort. It schedules.

Which is why, if the only question you can answer about your loop is what wakes it, you do not have a loop. You have a cron job with an opinion.

One distinction the trigger cannot see

Before moving on, note something a trigger-shaped view of loops actively hides: not every pass of a loop is the same kind of work. Some passes read and explore; some passes decide. Those want different models, different permissions and different costs — a cheap explorer with a read-only toolbelt, then an expensive decider that inherits everything the explorer saw.

That is a seam in time, not a trigger, and it does not appear anywhere in a taxonomy of what starts loops. It has its own treatment in The Scout and the Senior, and the sentence worth carrying from it is that the lossy compression in most multi-agent designs sits at exactly the seam where judgement happens.

The trigger sets the clock. The next surface sets the ceiling — and it is not the prompt.

This is the shortest chapter in the book, and it is short on purpose. The aim is the surface with the best-documented owner in our canon, and the discipline this book is trying to model is: state the essential claim, then get out of the way. If a hub piece cannot do that on the surface where it would be easiest to show off, it will not do it anywhere.

Where the prompt and the aim come apart

In a conversation, the prompt and the aim are the same object, because you are sitting there to re-aim every turn. Drift is free to fix; you notice it in the next reply and steer.

In a loop, they separate, and the separation is the whole thing. The prompt is what gets sent on iteration ninety. The aim is what has to still be true on iteration ninety, when nobody has looked at the output since iteration three.

Tight intent, loose method

The essential claim, taken and no further: be precise about purpose and imprecise about procedure. Precise about what great looks like, who it is for, what success and failure both mean, and the two to five constraints that would make the output flatly wrong. Imprecise about the step-by-step, the exact format, and the wall of things not to do.

Most bad prompts get this exactly backwards — vague on purpose, suffocating on procedure — which is why they produce procedure-following with no purpose-serving. On a model that can actually think, a page of method is a tax on the attention that was supposed to go on the problem.

There is an honest boundary on that, and it should be said in the same breath rather than buried. North-star aiming is the right tool where the solution space is wide and the target is taste-shaped — design, writing, synthesis, “make this good”. Where the output feeds a machine and must match a schema, where there is one correct answer, or where a constraint is safety-critical, prescribe, flatly, and do not confuse latitude with laxity. The full treatment of how to tell those apart is in The North Star Prompt.

What changes when nobody is in the middle

Here is the part that belongs to this book rather than that one, because it is a property of loops specifically.

Push the idea far enough and the north star stops being a prompt and becomes a file. On one of our projects the directive lives in a NORTH_STAR.md that an autonomous loop reads first, every time it wakes, before doing one aligned bite of work and stopping.

That is not a stylistic choice. It follows from the anatomy. The aim has to be readable by something that has no memory of the last time it was aimed — which means it has to live where surface three lives, not in the head of whoever kicked the job off.

State the destination clearly enough and a self-directing agent can navigate without a turn-by-turn route.

The aim outlives the query

The second claim worth carrying comes from a different corner of the canon and it explains a failure mode people meet constantly without naming it.

Treat the query as a disposable probe and the parent intent as the invariant unit of work. In an investigation architecture that means holding the real purpose steady while individual search strings come and go. In a loop it means something more pointed: a loop that re-derives its goal from its own last output will drift, because each pass quietly overwrites the intent with the artefact. Twenty passes later it is optimising something adjacent to what you asked for, confidently, with no error anywhere.

Hold the intent somewhere a pass cannot rewrite it. The Intent Compiler is where that idea is developed properly, along with what you build on top of it.

A field note, and then the door

One receipt, two sentences, because it is the kind of thing people ask for. Running an agent against an inbox for two years, we deliberately made the agent prompts less prescriptive and more general — against every instinct, which is to anticipate every situation with a rule. With a clear north star the agent handled edge cases a rulebook could never have enumerated, because it was reasoning toward an intent rather than matching against a checklist.

That loop comes back in Chapter 7 for a different reason. For now, the door is The Index Is the Data.

The done-test, placed here

One more thing belongs to the aim, and putting it here saves Chapter 6 from having to reopen the subject.

An aim you cannot check without reading the transcript is not an aim. It is a mood. Every north star that drives a loop needs a companion sentence — a completion condition a machine, or a bored human at 7am, could evaluate in ten seconds without reconstructing what happened overnight.

That last line is the trap, and Chapter 6 owns it: a done-test the worker can read is a done-test the worker can write to. Note it and keep walking.

What a perfect aim cannot buy you

Close on the boundary, because it is what makes the ordering rule bite.

A perfect aim raises the ceiling on quality and does absolutely nothing about survival. Point a loop beautifully at the wrong hill and it will climb the wrong hill all night, cheerfully, at frontier prices, and tell you in the morning that it is finished. Aim decides how good the work can be. The next surface decides whether any of it still exists at breakfast.

Between any two turns of a loop, something has to hold the answer to three questions: where are we, what is finished, and what is next. Somewhere in the system that information exists, or the next turn cannot happen.

There are exactly three places it can live, and they form a ladder. Most people never choose — they inherit the top rung by default, which is the worst one.

The ladder

Rung two is the one people mistake for rung three, so sharpen it: a script that knows the steps still does not know how far you got. Fixed code holds structure, not position. Kill it at step seven of twelve and it restarts at step one, or worse, it restarts at step one and does not tell you.

Durability beats coordination

The principle underneath the ladder runs against the instinct, so state it as a reversal.

The instinct runs the other way because coordination is the visible problem. Agents talking past each other is dramatic and legible: you can watch it happen in a log. Durability failure is invisible — nobody notices that nothing was written down until the thing that was supposed to have been written down is needed.

The clearest public demonstration is two agents, unaware of each other, working the same pull request: one producing, one reviewing. Neither holds the other’s state; the PR does. Either can die mid-flight and the work survives, because the coordination medium is external and durable rather than living in somebody’s context window.⁷

That is two sentences of illustration and I will stop there. The end-to-end version, on loops we actually ran, waits for Chapter 8.

The receipt

The first edition of this book made that argument in June. Rather than make it again, let me show you what happened to it — because what happened is better evidence than the argument was.

In the weeks since, three later books of ours landed on the same axis independently, from three different directions. None of them is about loop taxonomy. All three arrived at “put persistence outside the model” because the alternative kept failing in the field.

“The agent is not the system of record. The system of record is the thing still true after the session dies.”

Three separate pieces of work, three separate problems, one axis. That is better evidence than a single argument — and it is still not a measurement, and I am not going to dress it up as one.

The doors, if you want the machinery rather than the map: Breaking the 1-Hour Barrier for the architecture, and Handover Notes for Robots for the operating discipline — shift logs, watchdogs, how much the night shift is allowed to touch.

What “durable” has to mean

Three tests, and no more than three, because a longer list turns into an implementation guide and this is a map.

The sentence everything else hangs off

I will state the conviction plainly, because the rest of this book is downstream of it.

State inside the agent evaporates. State outside it compounds.

Which also means the most expensive way to avoid writing something down is to invest in better agent coordination. Protocols, handoff formats, negotiation between workers — all of it is engineering effort spent on the problem you would not have if the state were in a file.

And rung three does one thing the ladder table does not show. Once the state is outside the agent, something that is not the agent can read it — which is the only reason the next surface is available at all.

The correction to the whole loop-engineering wave was published on day one, for free, in the replies. Nobody had to write an essay:

“designing the loop is half of it. the other half is putting something in the loop that can say no: a test, a type check, a real error. a loop with nothing to push back is the agent agreeing with itself on repeat.”

Seven weeks later it is still the fifth bullet in every architecture. That gap is the ordering rule in miniature.

What a closer is

A closer is any durable, mechanically independent check that can veto the producer’s output. A test suite. A CI gate that goes red. A separate evaluator model judging a stated success condition. A human who has to click before anything ships.

Notice the collapse: the closer and the durable medium are usually the same object. The pull request is both the blackboard that survives an agent dying and the place a red check blocks the merge. That is not a coincidence — it is the third durability test from Chapter 5 cashing out. Externality is what makes a veto structurally possible; you cannot be overruled by something that lives inside you.

The tooling has already shipped this as a feature. Goal-style stopping commands run a separate fast evaluator that judges the success condition after each turn, and the model doing the work is not the model grading it. The separation is not an implementation detail of the feature. It is the feature.

The correction

Here is what the first edition of this book got wrong, and it is the more interesting half.

I said a loop needs something that can say no. Independence, I thought, was the property that mattered: author and reviewer as different instances, so nothing grades its own homework. That is necessary. It is not sufficient, and the shortfall is not academic.

Two properties hold a check up, not one.

The reason it works is worth stating precisely, because it is the mechanism and not a slogan: intent cannot be gamed, only pursued. A goal like “produce something a knowledgeable reader would find genuinely useful” has no cheat code — the only path that satisfies it runs through doing the work. A gate like “contains a section titled X” has an obvious one.

So the split is: intent visible, rubric hidden. Saturate the worker in why. Keep the completeness checks with a reviewer who sees only the output and holds an answer key the author never had.

An honesty note, carried across from the source rather than invented here: nobody ran a controlled A/B on those two columns, and there is no gate-gaming rate to quote. Treat the contrast as mechanism, not benchmark. The full argument — where the pattern comes from, what it does not guard, and the five-step protocol for running it — is in Hidden Gates.

The same instinct, better phrased

Osmani gets there from the other side and in fewer words: the model that wrote the code is way too nice grading its own homework.² Same mechanism, no jargon.

At delivery scale it becomes a rule for the whole increment rather than a trick for a sub-agent. When generation is cheap, a large wrong system appears as fast as a right one, so the expensive work moves to the ends: framing and architecture upstream, independent verification downstream. Run each slice under tight intent, loose method, hard verification — with compile, tests, smoke and evals you do not let the builder own, and an independent gate before autonomy expands.

The line to keep from that piece is four words long: the generator does not grade its own work.

Autonomy is earned, not dialled

One more correction belongs here, and it is aimed at the most-quoted frame in the field.

Andrej Karpathy’s autonomy slider is a genuinely good picture: depending on the complexity of the task, you tune how much autonomy you are willing to give up for it, and you keep the AI on a leash so it does not get lost in the woods.⁸ He is also explicit that the leash is fast verification rather than a longer rulebook, which is exactly right.

The one misleading implication is in the word slider: it suggests autonomy is a level you choose. In practice it is a level you earn. You get to leave exactly as far as your closer can hold, and the way autonomy widens is by passing an independent gate, not by dragging a control to the right.

The closer is not a tax on autonomy. It is what buys autonomy.

Which reframes the whole surface. People treat verification as the brake and the loop as the engine. It is the other way around: every increment of unattended running you get is paid for by something that could have stopped it and didn’t.

Why this surface gets skipped

Not laziness, and not ignorance. A closer is invisible when it works and only visible when it fails — at 3am, silently, with nobody watching. And the failure mode is not a crash, which would at least be honest. It is a green tick over work that never happened.

A closer tells you the run was real. It says nothing about whether the run was worth having. That is the last surface, and it is the one that decides whether you own anything at the end of the night.

In production software the loop’s product is merged code. The question “what did it leave behind?” has an obvious answer: a diff, in a repository, that other people will read.

If you are building things that build things — a research system, a publishing pipeline, a knowledge base that is supposed to be worth more next year — the loop’s product is knowledge that makes the next loop better. That sounds like a softer goal. It is a harder one, because it makes “done” a property of the output’s shape rather than of the run.

The compounding test

Frame it as the decision it actually is, and make it before the first run rather than after the hundredth: is this thing meant to accumulate findings that you read, or to become the substrate the loops read from to decide what to investigate next?

The second only works if the entries are structured enough that a future agent can load them as priors. That structural requirement is the real design constraint on this surface, and it is worth deciding deliberately rather than discovering after a few hundred unstructured entries.

Capture was never the bottleneck

The general form of that failure is older than agents, and it has been worked properly elsewhere, so take the claim and move.

Capture appends. Compilation concludes. Capture writes things down in arrival order, never de-duplicates, never supersedes, and degrades as it grows — the 2016 answer and the 2024 answer sitting pages apart, both looking current. Compilation merges the eleven answers into one canonical claim with receipts, chains the versions by date, resolves the contradictions or escalates them, and builds a map reachable by someone who cannot name what they need. Capture gets bigger. Compilation gets smaller and sharper as it grows.

The diagnostic sentence from that work is the one to carry: a repeated question is a cache miss, not a comprehension failure. The whole argument, with its evidence and its economics, is in The Wiki Playbook.

Transferred to loops, it is one sentence: an accumulate-only loop is capture with a scheduler attached. You have automated the half that was never the bottleneck.

Where the compounding actually lived

One receipt, and I will keep it to the size it deserves.

I gave an AI one job for two years: read one email at a time, read the wiki, update it. Then do it again. Forever. That is the ingestion loop, and on its own it would have produced a very tidy pile.

The compounding lived in the second agent — a janitor that woke when a page got long and consolidated related claims, faded superseded ones, spun clusters into their own pages, and converted statements into edges so that more of the meaning ended up held in the connections than in standalone lines. Same toolset as the builder, same north star, no supervision.

How that graph is actually built and maintained — what a claim looks like, what an edge looks like, how the janitor decides — belongs to The Index Is the Data, and I am deliberately not re-deriving it here.

The rung above: did it work?

There is a further step, and it is the difference between a system that reads the past well and one that learns.

Outcome closure asks: did the authorised action work, and what should the worldview change because of the result? Without it you have a clever reader of the past rather than a metabolism. Intake without integration is hoarding; integration without activation is a museum; activation without outcome learning is bureaucracy with better tools.

One rule travels back from that work and should be obeyed from your first run, because retrofitting it is miserable: derived output ranks below source evidence. A hard-won synthesis can be filed back, but typed as derived — cache, not evidence; subordinate to its supports; stale when they change; first to be regenerated. Skip that and the system starts citing its own echoes, confidently, and you will not notice for months. Executable Worldview owns the full composition.

Three surfaces, one decision

Now the part this second edition exists for.

The first edition treated durable state, the closer and the compounding test as three separate arguments in three separate chapters. That was one chapter too many, twice over. They are not three problems. They are one decision seen from three angles.

The corollary is what gives you leverage. If you can only fix one surface this quarter, fix state — not because state is the most valuable of the three, but because the other two are downstream of it and become cheap the moment it is right. Try to add a closer to a loop whose state lives in a chat window and you will end up building a second agent to read the first agent’s conversation, which is a fantastically expensive way to avoid writing a file.

A loop that runs leaves nothing behind. A loop that compounds leaves a map that changes what the next loop is even able to ask.

The honest boundary

Not every loop should compound, and the test stops being a test if it becomes a virtue.

A loop whose entire job is keeping a precondition alive — the heartbeat from Chapter 3 — has no residue and should not pretend otherwise. A loop that watches a deploy and shouts if it goes red has no residue either. Compounding is a requirement for knowledge work, where the whole point is that next quarter should be cheaper than this one. It is not a general virtue, and demanding it of infrastructure produces the worst kind of over-engineering: a heartbeat with a knowledge graph attached.

That is the anatomy. Part II puts all five surfaces on loops that actually ran — including, honestly, the surface that was blank.

An anatomy is only worth having if it changes what you build. So here it is, filled in, for two loops that ran — one overnight, one for two years — with the alternative I rejected at each surface and why it fails.

The rejected answers matter more than the chosen ones. Every one of them is reasonable. Most of them are what I would have shipped without the card.

Loop A — the overnight publishing orchestrator

Thirteen publishing pipelines, running unattended through the night, with quality gates the workers were never shown and real send-backs when work came back thin. It worked well enough to leave running.

One honesty note before the walk-through, carried across from the source: that is a production observation, not a benchmark. There is no completion-rate figure here, no gate-gaming percentage, and no A/B. Read it as mechanism.

Surface 1 — Trigger

Surface 2 — Aim

Surface 3 — State

The part of that worth one extra sentence is the log, because it does a job people do not expect. Stall-detection is a temporal problem, and the model has no purchase on time. Written down, it becomes a text-comparison problem — three entries in a row that say the same thing — which is exactly the kind of thing the model is excellent at.

Surface 4 — Closer

Surface 5 — Residue

Loop B — the two-year wiki

The same card, at a completely different timescale, which is why it is here.

Trigger: one email arriving. Aim: build a worldview for a personal assistant, with one temporal directive — favour recent information over old. State: the wiki itself, on disk, readable by any agent that turns up. Closer: a janitor agent working under the same north star, deciding what to consolidate, fade or split off. Residue: the map — which is also the state, which is precisely why this loop compounds so hard.

That last coincidence is worth pausing on for one sentence: when a loop’s durable state and its residue are the same object, every run automatically leaves the next run better placed. Most loops have to be designed into that position. This one could not avoid it.

The card, side by side

The blank surface

Now the finding, and it is not flattering.

In both loops, residue was designed last. In Loop A it was retrofitted after several nights of watching the same incidents get rediscovered from scratch, each time at full price, because the log was treated as scratch. In Loop B it was the entire point of the exercise from day one — and it still took a second agent to achieve, because the ingestion half felt like the finished system for a long time before the janitor existed.

I offer that as evidence for the ordering rule and against my own practice. It is also the reason the audit in Chapter 11 asks the residue question last but treats a blank answer as the most serious verdict: the surface that is easiest to defer is the one that decides whether the whole exercise accumulated anything.

What the card actually is

Read those two walk-throughs again and notice that the useful column is not the one with the decisions in it. It is the one underneath.

The rejected answer is the one you would have shipped.

Run until done. Write a proper brief. Keep it all in the conversation. Tell the workers what good looks like. Treat the log as scratch. Every one of those is what a competent person does on a Tuesday, and every one of them is a surface left on its default setting.

That is what the card is for. Not a checklist — five questions with a plausible wrong answer attached to each, so that choosing takes ten minutes instead of six months of finding out.

Both of these loops are things I designed. The next chapter is about the loop that designs itself: the claim the first edition of this book put at the frontier, and where its value actually landed.

The best sentence anyone has written about agentic loops is not about loops. It is about code.

“You can never be more dynamic than code… when the agent can write code, it is effectively building its own custom feature every time.”

That is a transcript — spoken word, captured from video — so treat the wording as transcript-grade rather than as published prose. The idea inside it is exact.

Code as the step between model runs

The inversion is the whole thing. We are used to code as the model’s output: you ask, it writes, you review, you merge. What Theo is describing is code as the step between model runs — the agent emits a program whose job is to organise the next several model calls.

Once you see it, the limitation of the alternative is obvious. A hard-coded workflow primitive forces the agent into your pre-built shape: here are the phases you may use, here is how prompts get structured, here is how results come back. It is a cage built by someone who had to guess the problem in advance. Let the agent write the orchestration and the shape of the loop matches the shape of the problem — including the parts of the problem you did not anticipate.

The demonstration that made this concrete: an agent building a pull-request audit did not call a workflow feature. It wrote roughly 240 lines of throwaway JavaScript that defined its own phases, its own schemas, its prompts-as-functions and a pipeline — and then that code orchestrated the sub-agents through it.⁷ Not a bigger prompt. A program, written on the spot, thrown away afterwards.

The first edition of this book framed that as a genuine phase transition, and I still think that is right: the first three kinds of loop are loops you designed — fixed structure, changing content — and this one designs its own sub-loops at runtime. That is a change of category, not a change of degree.

Correction: where the value actually landed

The invariant you can carry between runs

When regeneration is cheap, the scarce reusable object stops being the code and stops being the runtime scaffolding. It becomes a compact, promptable invariant — a compressed statement of what kind of system should exist, which a capable agent expands into an implementation fitted to the local world.

The bar for one of those is a good bar: short enough for a human to carry; precise enough for an AI to regenerate. Too long and it stops travelling; too vague and independent expansions share a buzzword and nothing else.

Set that against a runtime meta-loop and the asymmetry is stark. The meta-loop is spectacular and it dies with the session. The sentence you can paste into the next session, and the session after that, and into someone else’s project, does not. Generative Design Patterns is where that argument is made properly.

The boring external scheduler

And the other duller place: what actually made long jobs finish, repeatedly, across dozens of runs, was three lines of discipline and an ugly Unix job — a goal with a done-test, an instruction to repeat until finished, and something outside the model that wakes it up and asks. Chapters 3 and 5 already sent you there; I am not going to link it a third time.

The carryable sentence beat the clever runtime.

The hard boundary on self-structuring

There is a limit on how far the self-structuring instinct should go, and it is not a matter of taste.

When a step has to be provable — when two runs over the same inputs must produce the same result, when provenance has to survive, when a budget must not drift because the prose felt confident — the middle of the pipeline cannot be another agent. An agent can narrate a merge; only deterministic code can make the merge auditable under load, across runs.

The shape that works is a pendulum: AI judgment → deterministic compilation → AI judgment. Variation at the ends, compilation in the middle. Put the model in the middle and provenance dissolves into prose; minority findings become tone; budgets become whatever fitted the context window today.

Applied to loops, it is one sentence: a self-structuring loop is fine at the ends of your pipeline and dangerous in the middle of it. The full argument is in The Intent Compiler.

Posture, not maturity

The reframe that resolves the whole chapter is that self-structuring is not a higher rung on a ladder everyone should climb. It is a posture, and you choose it by unit of production.

The line from that work worth carrying into any loop review is: the screen lies by omission. An automated path can hit every metric the dashboard displays and still delete the product, if the product was an insight that only appeared while somebody was watching. The Discovery Workshop, Not the PR Factory makes that case in full.

The costs, stated flat

Three of them, without hedging.

It is non-deterministic: the generated orchestration is sometimes simply invalid, and you find out mid-run. It is expensive, in a way that scales with how far the agent decides to take the structure. And it costs you legibility — you can no longer point at a fixed pipeline and say what will happen, which is a real loss and not a philosophical one.

All three are acceptable for exploration. None of them is acceptable where a regulator, a customer, or a rollback is downstream. That lane has its own doctrine, its own gates and its own authority machinery, and this book does not pretend otherwise.

Keep the category. Lower the rank. It remains the most interesting thing in the field, and it is not the thing that made my loops finish.

If the exciting architecture was not the wedge, the exciting spend is not either — which is the last thing this book needs to be honest about, including about itself.

You have seen the genre. Fifty-agent tournaments to pick between three pull requests. A dollar counter on screen, ticking. Four figures of inference in ten days, screenshotted from a billing dashboard.⁷

Those are somebody’s stated figures, read off their own screen in a video. Not audited, not reproducible, and not something to build an argument on. What is worth arguing about is what a reader should take from watching it.

Correction: the first edition was too clean about this

The honest version is one our own field notes arrived at later, after a week of watching a frontier capability be temporarily cheap:

The token-max week is a furnace, not a lifestyle brand.

When an unusual capability is temporarily included in a plan and about to become specialist-intervention expensive, the rational move is ugly and honest: keep feeding the furnace. Capture while the capability is still economically available. Do not stop the reaction in order to catalogue every product of the reaction — you can catalogue afterwards, and you cannot re-open the window.

So the burn is not automatically silly. Two things are.

What transfers from someone else’s spectacular run is never the agent count. It is the architecture: dynamic where the problem is unknown, artefact-producing, externally stateful, adversarially closed. Copy the intensity and you have copied the wrong variable.

The question that ends the argument

Arguments about spend never resolve, because both sides are talking about their own situation. Replace it with a question that has an answer.

If ground truth lives outside the model — a compiler, a test suite, a real error — then more agents buy you throughput. Correctness settles against the oracle no matter how many agents you add, and adding agents mostly protects the main context from clutter.

If ground truth lives inside your corpus — the answer is right or wrong depending on what got read — then the retrieval agent that shapes what reaches the answer is the accuracy mechanism, and a second agent is not a luxury.

Answer that and you know whether you are buying throughput or correctness, and whether the second agent is architecture or theatre. Sub-Agents: Speed vs Accuracy is the door.

A related cost lever, one sentence and a link: much of what people spend on frontier models goes on reading rather than deciding, and that work can be split along a time seam — a cheap explorer, then an expensive decider that inherits everything the explorer saw. The trap when you do it is that the lossy compression usually lands exactly at the seam where judgement happens. That is The Scout and the Senior.

The strongest objection to this book

Here is the best published pushback on the whole premise, printed at full strength because a quote you are about to answer deserves that.

“designing the loop is just procrastination with better posture if there’s no customer at the end of it. Because someone still has to decide what the loop optimizes for. What ‘done’ looks like. When to break. What counts as a failure worth stopping for.”

Three responses, and the first one is a concession.

It is correct, and it names two of the five surfaces. Someone has to decide what the loop optimises for — that is the aim. Someone has to decide what counts as a failure worth stopping for — that is the closer. Read carefully, the objection is not an argument against designing loops. It is an argument for exactly the ordering rule in Chapter 2: the parts that need a human decision are the parts nobody is designing.

It is why surface five asks what the loop left behind rather than how elegantly it ran. “No customer at the end of it” is the same failure as an accumulate-only loop, described from the commercial side instead of the epistemic one.

And it is why the anti-theatre rule is non-negotiable: every cycle must terminate in a deployed artefact, not a recommendation. The named failure is the meta-tooling trap — “build the build system” has produced more dead internal portals than working products — and its consulting analogue is a beautiful discovery engine generating synthetic futures while the client never gets a working agent shipped.

The same critique offers a second line worth taking seriously rather than swatting: the deterministic logic is the brain, the LLM is the narrator.¹¹ Chapter 9 already conceded most of that — when a step must be provable, the middle cannot be a model. Where it over-reaches is that a purely deterministic harness can only ever do what somebody already knew to specify. That is fine for a payments pipeline and useless for a research loop, which exists precisely to surface structure you did not know to look for.

Why a documented done-test beats a reward signal

One line of steel, borrowed and not developed, because it explains something about surface four that Chapter 6 left implicit.

Search beats learning when the evaluation function is already inside the human. Reinforcement learning is the right tool when nobody knows what good looks like and it has to be discovered by reward signal over many runs. That is a frontier-lab problem. For the loops in this book, you already know what good looks like, or you can document it in an afternoon. You do not need the loop to discover the objective. You need the loop to be scored against it, by something that is not the loop.

Which is the transferable part, and it is smaller than it looks: an aim, external state, an adversarial check, and an artefact at the end. Run that shape at a tenth the agent count and it still works. Run the agent count without the shape and you have bought an expensive consensus.

Enough doctrine. One page, five questions, one verdict.

Everything in this book converges on five questions. They take about ten minutes on a real loop, and their value is that they turn “my loop didn’t work” into a named surface with a book behind it.

The audit

The verdict

Not a score. A ladder of failure, and each rung has a different remedy.

How to prove me wrong

Chapter 2 made a promise, so here is the test. The ordering rule says the trigger decides least and the closer and residue decide most. That is falsifiable and I do not have the numbers.

Run the audit across ten real loops — yours, your team’s, whatever you can get honest answers about — and count which surface is blank most often. If it turns out to be the trigger, the ordering rule is wrong and this book is wrong with it. I would genuinely like to see that data, because right now the claim rests on a position and a set of field observations, which is exactly as much weight as I have put on it.

Where to go next

This book is the map. Every surface has a room, and this is the door list.

Where the human stays

One last quote, because it is better than anything I would write in its place. From the essay that named this discipline:

“Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.”

The loop changes the work. It does not delete you from it. What it deletes is the part of the job where you were doing clerical control flow — and what it hands you instead is five design decisions that nobody used to have to make.

The short version of everything

The reframe was the easy part and it is done. Steinberger compressed it, Osmani named it, and the field agreed inside a week. What survived seven weeks of actually building the things is smaller and duller than the discourse, and it fits in three clauses:

Put the loop’s state machine somewhere the loop can’t reach. Give it something it can’t see that can say no. Make sure it leaves behind something the next run can read.

Everything else — the trigger you spent an afternoon on, the prompt you rewrote nine times, the agent count — is real work at the two surfaces that decide the least.