Loop Engineering: What the Loop Compensates For

Loop Engineering is five weeks old. On June 7, Peter Steinberger posted on X that we should no longer be prompting agents but designing the loops that prompt them. Millions of views in twenty-four hours. Addy Osmani published the foundational essay the same day, Business Insider followed, Andrew Ng devoted a Batch letter to it. On the other side, a 1,800-comment Hacker News thread kept repeating that all of this is a while loop with an LLM call inside.

Both camps are talking about code, and they are talking about the same thing: the loop. One side thinks it changes everything, the other that there is nothing new about it.

Here, the loop almost never runs. That is what took me the longest to understand.

There is no compiler for a text

What is Loop Engineering? Designing the loop that prompts AI agents for you, instead of prompting them yourself. Look at any definition: the loop discovers the work, delegates it, verifies the result, decides to continue or stop. Everything hinges on “verifies”.

For developers, verification costs nothing. Tests pass or they don’t. The build compiles or it breaks. There is an external, deterministic judge that no model can charm, and it delivers its verdict in three seconds of CI. The loop had its stop condition written before agents even existed. That is why Loop Engineering is exploding among developers and almost nowhere else. Other professions are not behind. They simply have no judge.

Now tell me which linter detects that a paragraph is technically accurate and perfectly hollow. It does not exist, it will not exist any time soon, and that changes everything: when verification is expensive and fallible, you cannot afford to rely on it. The text has to be good coming out, not after five trips to court.

Eleven agents, eleven mandates

NOMO IA runs on eleven agents that pass the baton to one another. Research, writing, quality control, SEO/GEO optimisation, repetition detection, tone work, validation. Each one receives a precise objective and a set of rules, and each one is evaluated against a rubric that matches its objective, not the final result.

This is where it diverges from what the word “loop” suggests. The prevailing narrative describes an agent spinning on itself until a test passes. Here, there is not one loop: there are eleven gates, and a gate only opens if the previous link delivered what it, specifically, was asked for. The agent hunting repetitions has no opinion on SEO. The one checking sources does not care about tone. Each has a narrow mandate, and that is precisely what makes evaluation possible: nobody has to answer “is this good?”, a question an LLM will always answer yes to. You ask an agent to verify one thing, and you give it the means to say no on that one thing.

When an agent fails, we rerun it. Three times maximum.

What three iterations reveal

Three has always been enough. Not once in several months of production have I seen an agent need a fourth pass to fall back in line.

For a long time I took that as an engineering success. It is the opposite. If the loop never runs, it is not because I found the right stop condition: it is because the work happens elsewhere. It happens upstream, in the rules imposed on each agent before it writes the first line. Constrain a mandate tightly enough and the agent converges in one or two passes. The three iterations are not hard-won discipline. They are a safety net, and one that almost never triggers.

Which raises an uncomfortable question for Loop Engineering.

The loop as a confession

The prevailing narrative says value has moved from the prompt to the loop. What my experience tells is roughly the opposite.

A loop is what catches insufficient framing. It is useful exactly to the extent that the agent was poorly briefed, and it becomes spectacular when the agent was very poorly briefed: the more the loop has to fix, the more intelligent it looks. An agent that receives a narrow mandate, explicit rules and a rubric aligned with its objective produces something correct on the first pass, and the loop around it has nothing to do. It makes no demo. It makes no viral post either.

This is not an argument against loops. Where verification is free and the scope is huge, as in code, letting it run is perfectly rational: the cost of a failed pass is lower than the cost of framing properly. It is a calculation, not a revolution. It holds as long as the tests are green and tokens are cheap.

Elsewhere, the calculation flips. Ed Zitron sums up the underlying mechanics of the phenomenon: this narrative amounts to evangelising autonomous token consumption, something model vendors have an obvious interest in encouraging. Uber reportedly capped its engineers at $1,500 per month per AI tool after burning through its annual budget in four months. Here, a pass costs a few dozen cents and I could run twenty without it showing on the bill. I don’t, because it would serve no purpose: what a fourth pass would fix, a rule would have prevented.

The invisible work

The principle of the loop is fifty years old. CI pipelines, SOAR playbooks, the ReAct pattern: nothing new. What is new, and it is not nothing, is that the worker inside the loop now knows how to handle ambiguity. The scope of automatable tasks is genuinely expanding, up to a precise point: automation stops where cheap verification stops.

For code, that frontier is far away. For a text meant to convince a human to trust you, it is much closer than LinkedIn would have you believe. And on this side of the frontier, all the work is upstream: breaking an objective into eleven mandates narrow enough for an agent to hold, writing the rules, building rubrics that make it possible to say no about something precise. It takes weeks, nobody sees it, and nobody turns it into a carousel.

The loop, on the other hand, gets noticed. Maybe that is why it has a name.

NOMO IA is a multi-agent editorial infrastructure: eleven agents, eleven rubrics, and a loop that almost never runs.

Sources

FAQ

Does Loop Engineering work outside software development?

Only partly. An agentic loop depends on a stop condition, which means it depends on verification. In code, that judge already exists: tests pass or fail, the build compiles or breaks, and the verdict lands in seconds without any model being able to charm it. For a text, no such judge exists. No linter detects that a paragraph is technically accurate and perfectly hollow. Automation stops where cheap verification stops, and that frontier sits much closer for editorial content than for a code repository.

Why does NOMO IA cap its agents at three iterations?

Because beyond that, the agent is not what failed, the mandate was badly written. Across several months of production, none of the eleven agents has needed a fourth pass. The cap is not a cost constraint: an extra pass costs a few dozen cents. It is a signal. An agent that keeps looping points to a missing rule upstream, and it is the rule that needs fixing, not the number of passes.

Should you invest in the loop or in framing the agents?

It depends on the cost of verification. When it is free and the scope is huge, as in code, letting the loop run is rational: a failed pass costs less than careful framing. When verification is expensive and fallible, the calculation flips and the work moves upstream. Breaking the objective into narrow mandates, writing the rules, building rubrics that make it possible to say no about one precise thing. A loop is useful exactly to the extent that the agent was poorly briefed.

NOMO IA met ces principes en pratique dans un système éditorial avec 13 agents IA spécialisés. Du cadrage à la publication, chaque étape est contrôlée.

Découvrir →

Loop Engineering: The Loop Catches What the Framing Missed