Loop engineering is not a while loop with an LLM in it. It's how Apollo runs unattended.

It’s hour six of an overnight coding run. The agent has been iterating for hours: write a change, run a test, write another. At 6am it posts its summary. Feature complete. All tests green. Ready for review. A human opens the app and the button does nothing, because the agent tested the function in isolation and never opened the page it was attached to. Nobody lied. The loop asked the only witness available, the model that did the work, whether the work was done, and the witness said yes.

That is the failure loop engineering exists to close, and it is worth naming precisely: loop engineering is the durable outer structure a long-running agent runs inside: a goal-as-contract, an executor, an external verifier the executor cannot talk its way around, and a proof trail. Not a prompt. Not a bigger model. A structure that sits around the model and decides, from outside it, whether the run actually landed.

This post defends that definition against the cheaper one most teams reach for first: a “loop” as just a while-loop with an LLM inside it, re-prompted until it announces success. That version is seductive because it requires almost no engineering — and it is the exact shape of the 6am failure above, for a specific, documented reason.

The naive version: a while loop with a model inside

Here is the loop almost everyone builds first, because it is the loop that requires the least thought. Prompt the model with a task. Let it work. Ask it, in plain language, “are you done?” If it says yes, stop. If it says no, or if it times out, prompt it again with whatever context survived. Repeat.

This is not a strawman — it’s the default shape of every “keep going until finished” agent wrapper, popular because it’s three lines of orchestration code around an API call, and for short tasks with an obvious finish line it works fine. The trouble starts where the value is supposed to start: long-running, ambiguous, multi-step work, the only kind worth automating unattended.

The while-loop myth treats the model’s own report as the finish line, and the model’s own report is not independent evidence. It’s the same process that did the work, describing the work, with the same blind spots. If the model forgot to check something while building, it forgets to check that same thing while grading — because it’s the same forgetting.

Why the loop can’t grade itself

Anthropic’s own engineering team ran into this directly while building harnesses for long-running coding agents, and wrote it up plainly: their agents showed “a tendency to mark a feature as complete without proper testing,” making changes and even running unit tests or curl commands against a dev server, but consistently failing “to recognize that the feature didn’t work end-to-end.” The fix Anthropic reports isn’t a smarter prompt — it’s giving the agent tools to observe the running system (browser automation, not its own narration), which “dramatically improved performance” precisely because it stopped the agent from taking its own word for it.

That is the mechanism, plainly: a self-check is not a check, it’s a repetition of the reasoning that produced the thing being checked. The practitioner term for this, coined outside Apollo and worth crediting rather than re-inventing, is loop engineering. Boris Cherny, who built Claude Code, said the shift plainly in mid-2026: “I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.” The AI Builder Club’s 2026 guide picked the term up from there and formalized it as “the discipline of designing the loop an agent runs inside, what it does between tool calls, when it checks its own work, and how it decides it’s finished, instead of hand-writing each prompt” — useful downstream coverage, but Cherny’s line is the origin. The synthesis tying the loop to a contract and a proof trail is ours.

Loop engineering is the durable outer structure a long-running agent runs inside: a goal-as-contract, an executor, an external verifier the executor cannot talk its way around, and a proof trail. Say it again because it is the whole post: the fix is not a better self-check. It’s removing the self from the check.

What loop engineering actually is, structurally

If the self-check is the disease, the cure is not “check twice.” It’s moving the check to somewhere the executor cannot reach: an outer loop, a wrapper around the agent’s execution cycle running as a separate process the agent is never aware of. It does its job and produces an output; a process outside that turn compares the output against the actual goal and decides whether to continue, stop, or restart it.

So the engineered loop has four durable parts, each removing a point where the naive loop trusted the executor to grade itself. Here is where “how do you run this, concretely” stops being abstract: Apollo is built as three layers — System of Record, System of Intelligence, System of Action — so these four parts each get a fixed address, instead of living inside one long-running prompt.

A goal-as-contract states the measurable end state and the evidence that proves it, written before the run starts, so “done” has a definition that predates the work and can’t be redefined by whoever is doing it. We made that case in a goal is a contract or it’s a wish: a goal in prose is a wish, a goal as a checkable condition is a contract. Apollo’s own contract and loop reference documents this as the schema every long-running agent runs against — built to live in the System of Record, the same place a deal or a ticket lives, so a goal can’t quietly mutate mid-run the way a scratch note in a prompt can.

An executor does the work: reads the contract, acts, and its write access is scoped to the task’s artifacts — nothing in the verifier, nothing in the contract itself. In Apollo’s shape, the executor is a run of the System of Intelligence, fenced by where it’s allowed to write, not by how politely it’s asked to behave.

An external verifier reads the executor’s output and checks it against the contract from structurally outside the executor’s reach, a point worth its own post, the verifier can’t live in the executor’s repo: a verifier the executor can edit is not a verifier, it’s a mirror. Apollo’s System of Action is the only layer allowed to write outcomes back into the System of Record, and it’s built to do that only on a pass from a verifier the executor never touches.

A proof trail records what the verifier found, not what the executor claimed, so “done” becomes an artifact you can audit later rather than a sentence you have to trust in the moment — living in the System of Record too, next to the contract it grades against, not in a side channel nobody remembers to check.

A loop that lets the worker decide when the work is finished isn’t a verification step. It’s a formality the worker was always going to pass.

The executor cannot be the verifier

This is the point teams resist longest: it feels fine to let a strong model check its own output, especially one good enough to have done the work. It isn’t — if the same process authors the change and grades it, the grade is not independent of the thing it’s grading. It’s a close cousin of a failure covered at the verdict layer in never letting a model grade its own homework: a judge from the writer’s own family scores its style as correctness. This post is one layer out: even an honest, cross-family verdict is worthless computed inside the executor’s own write-scope — which is exactly why Apollo’s System of Action, not the executor, is the only thing allowed to act on one.

Loop engineering is the durable outer structure a long-running agent runs inside: a goal-as-contract, an executor, an external verifier the executor cannot talk its way around, and a proof trail. The write-scope boundary is what makes “external” a real word instead of a decoration.

The proof trail: done is a checkable event, not a feeling

Even with the boundary in place, one gap remains: a verdict that only exists in the moment is still, in practice, a claim someone has to remember happened, and memory of a verdict degrades like any other memory. Our post on why an eval is the only honest definition of “it works” argues the verifier has to run the real thing, not a mocked stand-in that proves the code executed without proving the behavior was correct — a claim about the rigor of the check. This post’s claim is about what happens after: the result has to be written down, not spoken and forgotten, because a verdict living only in a chat transcript is exactly as fragile as the self-report it replaced.

A proof trail is unglamorous by design: a timestamped record of what the contract asked for, what the executor produced, what the verifier found, and whether it passed — the difference between “I’m pretty sure that ran clean last week” and pointing at the line that says so. A goal-as-contract without a proof trail is a promise with no receipt, and a long-running agent operating unattended for hours is exactly the setting someone, later, needs one. That’s also why the contract, verifier, and proof trail need an actual system of record built for agent action, the same way financial contracts live in a ledger, not in whoever’s memory happened to be paying attention that quarter.

What this costs, honestly

None of this is free, and this post says so plainly rather than selling the structure as an upgrade with no downside. A goal-as-contract has to be authored, in advance, precisely enough that a machine can check it — a vague goal produces a vague contract, which can’t be verified, relocating the problem one level up. An external verifier has to be built and maintained separately from the executor, doubling the surface you’re responsible for keeping correct. A proof trail costs storage and the discipline to write to it every cycle, not just the ones that went well.

The trade is worth it anyway: every one of those costs is paid once, up front, by whoever designs the loop. The alternative, the naive self-checking loop, pays its cost later, unpredictably, in the worst currency there is: a run that looked finished, that everyone believed was finished, that wasn’t.

The turn

Step back and this is an old problem in new clothes. Every team that has shipped anything has faced the same temptation: let the person who did the work also declare it good, because it’s faster, because they’re right there. Every team that has learned the hard way arrives at the same fix: a boundary between doing and judging — not because the doer is untrustworthy, but because nobody, human or model, is a neutral witness to their own effort.

The model in an agent loop isn’t the expensive part anymore. It’s fast, cheap by the hour, and gets better every few months without anyone lifting a finger. What doesn’t improve on its own is the structure around it: the contract that says what done means before the run starts, the boundary that keeps the worker from grading itself, and the record that lets someone check, later, that it happened the way it claims to have happened. That structure is the part worth engineering, and it’s the part Apollo is built around: the System of Record holds the contract before a run starts, the System of Intelligence is fenced so the executor can act but never regrade itself, and the System of Action is built so nothing lands back in the record until a verifier outside both of them says pass. The model was always going to show up smart. The question loop engineering answers is whether anyone can trust what it says about its own work — and the answer, run on that structure, is: you don’t have to trust it, you get to check it.

---

This is the mechanism Apollo is built around, not bolted on after the fact: a contract in the System of Record, an executor in the System of Intelligence with a bounded write-scope, a verifier it can’t reach into, and a System of Action that only writes back what the verifier already passed. If your agents report their own success and you believe them because the report sounds confident, you already have the 6am problem — you just haven’t been in the room yet when someone opens the app.