Agent architecture · Second edition

Designing Loops, Not Prompts

The five surfaces of a loop, and where your design budget actually goes. The reframe won in a week. What it left open was the design question underneath it — and the two surfaces that decide whether a loop is an asset or an activity are the two every architecture lists last.

Scott Farrell · LeverageAI · Second edition, July 2026 · Companion essay to the Designing Loops, Not Prompts ebook

On 7 June 2026, Peter Steinberger — creator of 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."¹ The timeline spent a week arguing about it. Then it stopped arguing, because he was right.

The old posture is genuinely over. You wrote a prompt, read what came back, typed the next thing — holding the tool the entire time, one turn after another. The new posture is a small system that finds the work, hands it out, checks it, records what's done, and decides the next thing, while you watch instead of type. Addy Osmani named the discipline "loop engineering" the same week.² Boris Cherny, who built Claude Code, is reported to have said the same thing from the vendor side — that his job now is to write the loops.³ Three voices, one claim, no meaningful dissent.

Here is the problem with winning that fast. "Design the loop" is a change of unit, not a design. It tells you what you're building. It doesn't 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. Seven weeks on, most of the public answer to those questions is still: pick a trigger, write a better prompt, add tools.

That is designing two surfaces out of five.

What a loop is actually made of

Strip any agentic loop — a bash one-liner, a cron sweep, a PR watcher, a full orchestrator — and the same five surfaces are there. Every one of them is a decision you make, or a decision you make by default.

Now the ordering claim, which is the part worth arguing with.

I want to be fair about the evidence here, because the strongest case for it comes from the best writing on the subject rather than the worst. Osmani's architecture names five components: scheduled automations, worktrees for parallel isolation, skills, plugins and connectors, and sub-agents that separate ideation from verification — plus persistent state, in markdown files or a Linear board, living outside conversations because model context resets between runs.²

Read that again. Everything you need is in it. The durable state is present, correct, and sixth — an addendum to a numbered five. And lists teach ordering. That is the whole complaint: not omission, but rank.

The correction was available on day one, in the replies. The sharpest one under Steinberger's post: "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 is surface four, stated perfectly, in a reply, seven weeks ago. It is still not where the design budget goes.

Surface three: who holds the state machine

The question that sorts loops is not what starts them. It is where "what's done, what's next, what did we learn" lives between turns. There are exactly three answers, and they form a ladder of durability.

The cleanest demonstration is the one Theo Browne ran in public: 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 agent can die mid-flight and the work survives, because the coordination medium is external and durable. The principle it demonstrates is worth naming, because it is the opposite of the instinct:

Durability beats coordination. You don't make multi-agent work reliable by improving how agents talk to each other. You make it reliable by putting state where it outlives any one of them.

I made that claim in the first edition of this piece, in June. I want to show you the receipt rather than repeat the argument, because the interesting thing is what happened next.

In the weeks since, three separate pieces of our own canon landed on the same place independently, from three different directions. Cron as the poor man's orchestrator arrived at a three-layer split — ephemeral cognition, external liveness, durable memory — and put it bluntly: the agent is not the system of record; the system of record is the thing still true after the session dies. Handover notes for robots arrived at the same axis from operations: the scheduler holds persistence, not the model, and the agent's append-only shift log converts a capability the model lacks — feeling three hours pass — into one it excels at, comparing text. And the parent of both, Breaking the 1-Hour Barrier, had already specified the architecture: stateless workers, a stateful external kernel, a compressed state vector handed to a fresh agent each pass while the previous agent's context evaporates.

Those three books own this surface now. This one's job is to tell you it exists and that it ranks third out of five — and then get out of the way.

Surface four: the closer — and the correction

A closer is any durable, mechanically independent check that can veto the producer's output. A test suite. A CI gate. A separate evaluator model judging a stated success condition. Notice that the closer and the durable medium are usually the same object: the PR is both the blackboard that survives an agent dying and the place a red check can block the merge.

The first edition of this piece said a loop needs something that can say no. True, and incomplete — and the incompleteness is the more interesting half.

Hidden Gates pinned down what "independent" has to mean. Two properties hold a check up, not one. The first is newsroom-desk separation: author and reviewer are different instances, so nothing grades its own homework. The second is the one most people miss — an information asymmetry. The reviewer knows something the author structurally cannot: the gates. Tell a capable worker the acceptance criterion and you have handed it a target; the cheapest path to a green tick is now the one that clears the criterion without doing the work. Show it the intent instead, and there is no cheat code — intent can only be pursued.

Osmani gets to the same instinct from the other side, and more memorably than I will: "the model that wrote the code is way too nice grading its own homework."² Our own delivery doctrine states it as a rule for the whole increment — tight intent, loose method, hard verification, with compile, tests, smoke and evals you do not let the builder own.

One pitfall, because it is the expensive one: running several copies of the same judge and treating their agreement as verification is an echo, not a check. Independence has to be mechanical — a different property, checked a different way, against something outside the model. The auditor is not the janitor works that through properly; the sentence to keep is that independence is part of warrant.

And this is where the popular framing needs adjusting. Andrej Karpathy's autonomy slider — tune how much autonomy you hand over for the task at hand⁶ — is a good picture with one misleading implication: that 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 expands is by passing an independent gate, not by dragging a control to the right.

Surface five: what the loop leaves behind

In production software, the loop's product is merged code. If you are building things that build things — a research system, a publishing pipeline, a compounding wiki — the loop's product is knowledge that makes the next loop better. That changes what "done" means, and it is a design decision you make before the first run, not a cleanup task after the hundredth.

The test is one question:

Most people build the accumulate half, because it is the obvious half — an agent that writes findings down. The half that makes it compound is consolidation, and it is the half that gets skipped. The Index Is the Data is the two-year receipt for this: one AI, one instruction — read one email, read the wiki, update it, repeat forever — plus a second agent, a janitor, that consolidated related claims, faded superseded ones and converted statements into edges. The compounding lived in the second agent.

The general form of the failure has a name in the wiki playbook: capture was never the bottleneck; compilation is. Capture appends forever and degrades as it grows. Compilation merges, dates, resolves and maps — and gets smaller and sharper as it grows. If you build only one loop for your knowledge base, build the consolidation loop.

There is a further rung, and Executable Worldview owns it: outcome closure. Did the action work, and what should the worldview change because of the result? Without that, you have a clever reader of the past rather than a metabolism. One rule travels back here and should be obeyed from day one — derived output must rank below source evidence, or the system starts citing its own echoes.

Two corrections to the first edition

The first edition of this piece made the "agentically-initiated dynamic loop" the frontier: a loop that writes its own sub-loops at runtime. The anchor was Theo's line, and it is still the best sentence on the subject: "You can never be more dynamic than code… when the agent can write code, it is effectively building its own custom feature every time."⁵ The mechanism it names is real — code as the step between model runs rather than code as the model's output.

Correction one. The line is true; my implication about where the value lands was not. Seven weeks of practice put the durable value in two much less exciting places. First, in the invariant you can carry between runs — a compact promptable pattern, short enough for a human to carry and precise enough for an AI to regenerate, which beats a runtime meta-loop because it survives the session. Second, in the boring external scheduler. And there is a hard constraint on how far self-structuring should go: when a step needs to be provable, the middle of the pipeline cannot be another agent — an agent can narrate a merge; only deterministic code can make it auditable across runs. Self-structuring is a discovery posture, not a delivery posture.

Correction two. The first edition filed token-maxing under theatre and moved on. That was too clean. The honest version, which our own field notes arrived at later: the token-max week is a furnace, not a lifestyle brand. When a frontier capability is temporarily cheap and about to become expensive, feeding the furnace is the rational move — capture while the unusual capability is still economically available. What is silly is mistaking the window for an identity, or copying the agent count instead of the architecture. Before funding another swarm, ask the question sub-agent economics puts at the centre: where does ground truth live? Outside the model, in a compiler or a test suite, and more agents buy you throughput. Inside your corpus, and the extra agent is the accuracy mechanism itself. Answer that and you know whether the second agent is architecture or theatre.

The strongest objection

It is worth quoting the best published pushback rather than a strawman: "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."⁷

That is correct, and it is why the residue surface asks what the loop left behind rather than how elegantly it ran. It is also why the anti-theatre rule in our own strategy doctrine is non-negotiable: every cycle of the engine must terminate in a deployed artefact, not a recommendation. Build the build system long enough and you have a beautiful portal and no product.

Run the audit on one real loop

Pick a loop you actually run. Answer five questions. The questions are the deliverable.

Blank at three or four and the loop is unfinished, whatever it reports in the morning. Blank at five and it is an activity with receipts: real spend, real output, no accumulating asset. That verdict is the whole point of having an anatomy — it turns "my loop didn't work" into a named surface you can go and fix.

The reframe was the easy part, and it is done. Steinberger compressed it, Osmani named it, and the industry agreed inside a week. Osmani's own closing instruction is the one worth keeping on the wall: "Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."²

Design the loop. But spend your budget on the surfaces nobody demos: where its state lives, what can refuse it, and what it leaves behind for the next run to read.