🔁 Loop Engineering

Find the next piece of work → plan → act → check the result → continue or stop. This is the agentic loop, and it fits on one page.

Because designing the cycle replaces writing prompt after prompt. You stop saying “do this” and start saying “repeat until it looks like this.”

A loop is a graph with a cycle. The five steps are nodes; the transitions are edges; “stop” is the only edge that leaves the cycle.

The rule that says when the loop is done. It could be “the test passed,” “two iterations with no improvement,” “spent X dollars,” or “a human approved it.”

A loop without a stop condition is not an agent; it is an open faucet. And stopping almost always needs layers: a normal criterion + a cap + a human.

Stopping because of success ≠ stopping because of giving up. Both need to exist—and giving up needs to notify someone.

With each cycle, the agent carries something: the history, what it has already tried, what it has learned. That’s the loop’s state.

Loading too much clogs the context window, and the agent starts getting confused by its own trail. Loading too little makes it repeat mistakes it has already made.

Explicitly decide what passes between iterations — this is the seed of the state schema that Track 4 will formalize.

Run the same prompt in a loop until the goal is reached — the most “digestible” version of loop engineering, popularized through Geoffrey Huntley’s Ralph method.

Because it became the face of the technique — and the simple version ended up representing the whole idea. Many people started there and evolved; many people stopped there.

The simple version isn’t the wrong version; it’s the incomplete version. Real loop engineering means designing the cycle e the output test.

Loop closed measures the result and uses that measure to correct the next iteration. Loop open just repeats, without looking at the effect.

Without feedback, you don’t have an agent; you have an expensive cron job. Feedback is what makes the loop converge instead of just spending.

Closed = measure and correct. And the quality of the measurement becomes the ceiling for the quality of the loop — the topic of module 2.2.

An outer loop that decides what to do and, inside each iteration, an inner loop that executes. E.g.: “for each file in the list, refactor until the tests pass.”

This is where a loop starts turning into a graph without you realizing it: each outer iteration is a node; the inner loop is what runs inside that node.

Nested loops are the natural bridge to graphs. When the inner loops need to communicate with each other, the outer loop can no longer handle it.

The verifier is the step that decides “is it good enough yet?” It defines what the loop pursues — and therefore the quality ceiling the loop can reach.

A loop with a medium prompt and an excellent verifier converges on something good. A loop with an excellent prompt and a weak verifier converges on something that seems good.

Invest where the bottleneck is. In practice: write the verifier before of the prompt.

Compile → lint → automated test → another model judging → human. Each step costs more and catches a different type of error.

You don't choose one: you stack them. Run the cheap ones every iteration and the expensive ones only when the cheap ones pass.

A deterministic verifier (test) is always better than a probabilistic verifier (model) when one exists. Having a model make the judgment is the last resort, not the first.

When the same agent, in the same conversation, writes and then “reviews,” it almost always approves. It’s already convinced — the reasoning that produced the text is right there.

It’s the most common and most invisible flaw in a single loop. The report says “reviewed,” and no one reviewed anything.

Review requires clean context: whoever judges the work must not see how it was done, only the result and the criterion. That’s one reason graphs exist.

Every verifier compares the result with some reference: a passing test, an approved example, a written rule, a target number.

If the reference is vague (“make it good”), the verifier becomes a matter of opinion and the loop becomes luck. A concrete reference is what makes verification repeatable.

Write the reference before you run it. If you can’t write it, you probably still don’t know what you want—and no loop can solve that.

Tests that stop covering what changed, aging data, metric definitions that change behind the scenes without anyone noticing. The dashboard stays green.

It’s the most silent failure of all: measurement shifts from “checking reality” to “checking the paperwork” — one number checked against another number.

The verifier also needs maintenance and periodic audits. Who checks the checker? Someone has to.

Before writing the agent prompt, write down how you’ll know it got things right. Run the verifier against a deliberately bad result and see if it rejects it.

A verifier that never rejects anything isn’t verifying. Testing it against a known bad case is the only way to know it works.

Verifier first = the same logic as writing the test before the code. And later, it becomes a at the of your graph.

A loop sees only its own metric — and that’s why it will find all the ways to move this number, including those that betray its purpose.

This isn't a malfunction: it's the loop doing exactly what you told it to do, using a number that has silently drifted away from the reality it represented.

When a measure becomes a target, it stops being a good measure. A metric on its own always ends up being gamed.

The loop pursues a reference, but nothing inside it can ask whether the reference is right. The thermostat keeps the temperature at 20 degrees; it can’t ask itself whether 20 is the right temperature.

A perfectly execution-focused agent can spend months excellently optimizing the wrong thing. And no one inside the loop can tell.

Questioning the goal requires someone outside of the loop—one node up, in the graph, or a human.

The speed loop fights the quality loop; the hiring loop puts pressure on the culture loop. Like two badly configured air conditioners: one heats, the other cools, both “working.”

Examined on its own, each loop passes the test. The single-loop mindset has no vocabulary to describe the collision.

A collision between loops only shows up when you draw the edges between them — in other words, when you turn them into a graph.

Sensors go out of calibration, data pipelines rot, the metric definition changes behind the scenes. Verification slips from checking reality to comparing paperwork.

It’s the quietest failure — there’s no alarm, because the alarm depends on the same measurement that broke.

Needs an external, periodic check against reality. No one watches the watcher on their own.

In a single loop, everything happens in the same window: raw search HTML, a half-draft, old reasoning—all floating together when it's time to decide.

This mix is what produces the fake review in module 2.2 and makes the agent “forget” the original instruction from earlier.

Clean context by role is one of the graph’s concrete, measurable benefits — it’s not rhetoric.

A loop reads sources one at a time because a loop is, by definition, one thing after another. It has no way to open ten fronts and combine them later.

This is the only limit of the loop that no better prompt will fix it. And that's why it's the most honest argument in favor of the graph.

Splitting into N branches and joining them (fan-out / fan-in) is a graph primitive. A loop can’t do this, no matter how well it’s written.