Loop Engineering: current trend or the next leap?
In mid-June, a post by Peter Steinberger, a developer known for building and then selling PSPDFKit, circled among insiders for weeks: AI agents are no longer prompted, the loops that run them are designed. A few lines, a tone of revelation, and within a few days the term "loop engineering" appeared everywhere, from Analytics Vidhya to corporate blogs specialized in agent infrastructure like Requesty. Even Boris Cherny, among the architects of Claude Code, upped the ante by talking about a leap comparable to that from compiled source code to autonomous agents, as BDTechTalks recounts while reconstructing the genesis of the debate.
It sounds familiar. In the last three years, the sector has already gone through the same ritual almost every six months: prompt engineering, then context engineering, then harness engineering, each time with the announcement of a paradigm shift. The honest question to ask is not whether loop engineering exists—it does, as demonstrated by the tools that concretely implement it—but whether it truly represents a conceptual leap or if it's the latest chapter in a longer story, told each time with a new name.
From prompt to system
To understand what changes, we need to reconstruct the sequence. Prompt engineering, between 2022 and 2023, concerned the formulation of the single instruction, the choice of words, the structure of the immediate context to obtain a better response from a still relatively short-sighted model. With lengthening context windows and the appearance of the first agents capable of using tools, attention shifted to context engineering, i.e., what to put inside that window, which documents to retrieve, how to organize memory, which tools to make available at a given moment.
The next step, which BDTechTalks describes in its piece on harness engineering from early June, concerns the scaffolding around the model, the so-called harness—the set of tools, permissions, sandboxes, and rules that transform a language model into an agent capable of operating in a real environment without constant supervision. This is where the comparison with anatomy becomes useful: if the model is the brain, the harness is the body that allows it to act in the world.
Loop engineering, in this progression, shifts the center of gravity further. It is no longer just about what the model knows or what it can interact with; it's about how the execution cycle repeats over time, when it stops, and who verifies the result before it is considered final. It's the difference between building a good tool and building the process that decides when that tool has finished its work. Requesty, in a practical guide for those building agents in production, distinguishes four operational variants: continuous heartbeat loops for monitoring, time-based scheduled loops for recurring tasks, loops triggered by external events like a push to a repository, and goal-oriented loops that stop only upon reaching an explicit success condition; see their overview of loop types.
The center of gravity really does shift, then, from the content of the prompt to the control system that surrounds it. It remains to be asked, however, whether this shift deserves its own label or if it is simply the natural, almost inevitable, evolution of the path already traced by harness engineering.
It wasn't born yesterday
It's worth slowing down here, because this is the point where the enthusiasm of the moment risks causing technical memory loss. The idea of a system that generates an attempt, observes it, corrects it, and tries again was not born with the LLM agents of 2026. The ReAct pattern, published by a research group from Princeton and Google in 2022, already formalized the interwoven cycle of reasoning and action that many today simply call "the loop." The following year, Reflexion added a level of verbal self-criticism—the agent re-reading its own error and transforming it into a lesson for the next attempt. And the separation between who generates a solution and who verifies it, the so-called maker-checker pattern, is a software engineering principle as old as code review itself, long before anyone thought of applying it to a language model.
Even the most recent literature confirms continuity rather than break. A 2024 work from Tsinghua University proposes an iterative experience refinement framework for software-developing agents, in which the agent accumulates and progressively filters its own past experiences along successive cycles—an architecture conceptually close to many today's loops, published when the term "loop engineering" had not yet been coined, as read in the original paper.
There is an image that conveys the idea well, borrowed from a field far from computer science. In the investigative video game The Forgotten City, the protagonist relives the same day dozens of times, not to suffer time repeating as a punishment but to use it; each cycle refines the understanding of a mystery that on the first round seemed unsolvable. It is no coincidence that Douglas Hofstadter, in Gödel, Escher, Bach, had already given a philosophical name to this idea: the "strange loop," a cycle that, returning to itself, produces a higher level of understanding than that from which it started. Loop engineering, fundamentally, tries to do the same thing with code, with the difference that closing the circle is no longer just human intuition but a second agent acting as a controller.
So what is truly new? Not the theory, which is rooted in years of research on agents and multi-agent systems. What is new is the practical systematization, the appearance of dedicated commands like /loop in Claude Code or recurring automations in Codex, which make an once-artisanal pattern finally composable and reusable at scale, as also confirmed by the technical analysis published by max-gherman.dev on the anatomy of modern loops. It is the difference, already emerged in a previous conversation on this same piece, between a theoretical revolution and an engineering maturation—less spectacular to announce, probably more useful to have.
Who wins, who risks
Where does this approach truly work? The most solid examples come from tasks with an objective and mechanically verifiable success criterion: the agent that corrects code until the test suite passes, the one that monitors production logs and opens a ticket when the error rate exceeds a threshold, the one that reviews pull requests older than a few days, signaling blocks to authors. In these cases, the loop has a clear arbiter—the test that passes or fails, the number that exceeds or does not exceed the threshold—and verification does not require real-time human judgment.
The problem begins when that arbiter is missing or weak. If the success criterion is vague—"the report is good enough," "the analysis is complete"—the loop risks what the technical analysis by max-gherman.dev calls hallucinated approval: a second agent declaring work finished that is only partially done because its judgment is not anchored to anything mechanically verifiable. Requesty, in its operational guide, lists the same risks under other names: the uncontrolled escape of iterations without a maximum ceiling, context degradation in very long loops, state amnesia when the agent loses track of what it has already processed between one cycle and another.
Who wins in this scenario? Probably the teams tackling repetitive and well-defined tasks with a budget to experiment with the necessary infrastructure: automatic code review, continuous monitoring, large-scale data extraction. Infrastructure providers also win—model routing gateways, orchestration platforms—which find in loop engineering a new vocabulary to sell an actually pre-existing problem: that of managing, with safety and predictable costs, a number of model calls that grows by orders of magnitude compared to a simple chat. Those who risk the most are the teams that import the enthusiasm without the underlying verification infrastructure, convinced that simply adding a repetition cycle to an already fragile prompt is enough to obtain reliability that wasn't there before. A loop around a bad success criterion does not produce a better result; it only produces an error repeated with more confidence.
The token count
The last question, perhaps the most concrete for those who must decide whether to invest time in this approach, concerns the relationship between quality gained and resources consumed. A loop is not free: each iteration is a new call to the model, often more than one if the cycle involves a separate generator and verifier or multiple specialized agents sharing the work. Requesty estimates that a daily review loop with multiple sub-agents can cost tens of dollars per day at full price on the most powerful models—a figure that drops significantly by routing only the steps that truly require advanced reasoning to the most expensive models and delegating classification and skimming to cheaper models, as described in their analysis of routing costs.
This raises a question that the general enthusiasm tends to leave in the background: how much is one more iteration really worth? If the second attempt of the loop corrects an error that would otherwise have ended up in production, the cost is probably well spent; if, instead, the cycle continues to run producing marginal variations of a result already acceptable on the first attempt, it is an expense that no cost dashboard justifies in hindsight. The serious measure of a loop's value, therefore, is not how many iterations it performs but how much it truly improves the outcome compared to the marginal cost of each additional cycle—a calculation that too many enthusiastic articles on the subject simply don't make.
A discipline of control, not a new intelligence
Returning to the opening question: does loop engineering deserve the attention it is receiving? The honest answer is yes, with a premise that resizes the scope of the announcement. We are not witnessing the discovery of a new principle; the generate-verify-correct cycle was already written in the agent papers of 2022 and even earlier in traditional software engineering practices. What is actually maturing is the ability to make that principle operational at scale, with native tools, persistent state outside of context, cost routing, and stop criteria more rigorous than a simple subjective judgment.
It's worth asking, then, whether in a year we will still be talking about loop engineering as a category in its own right, or if the term will simply be absorbed into the ordinary vocabulary of agent engineering—just as today no one talks about prompt engineering as a separate discipline anymore but takes it for granted within every technical conversation. Perhaps this is exactly the most likely fate for loop engineering: not a revolution to be remembered, but a piece that in a few months will stop needing its own name to be practiced.