A Conversation with Enrico Papalini on 'Non-Deterministic Loop Engineering'
When we spoke with Enrico Papalini a year ago about his first book, the central theme was a broken silent pact: the one between developers and deterministic machines, shattered the moment code stopped doing exactly and always what it was written to do. Papalini, Head of Software Development for Issuances, Custody, Data & UX/UI Solutions at Euronext Securities, with a past at London Stock Exchange Group and Borsa Italiana, recounted that transition with the voice of someone who manages systems where an error is not a contractual option, but an incident.
Since then, the conversation has moved on. It is no longer enough to ask what happens when a model generates a wrong answer, because the real question is what happens when that model continues to work on its own, for hours, making decisions, using tools, modifying files, without anyone watching every single step. This is where his new book, Non-Deterministic Loop Engineering, was born, dedicated no longer to the single output but to the loop that produces it, verifies it, and decides whether to restart it.
We picked up the thread with him again, this time focusing on a single object: the loop, its architecture, its risks, and the questions it leaves open.
From the Pact to the Loop
The two opening questions serve to understand why Papalini decided to isolate the loop as a discipline in its own right, and whether it is really something new or just a rebranding of ideas already well known in software.
I ask him what led him, after recounting the transition from determinism to non-determinism, to dedicate an entire book specifically to the loop, and how he would explain it in a single sentence to someone who is not familiar with the subject.
"Prompt Engineering teaches you how to talk to a model. Loop Engineering designs what happens when the model keeps working even after we stop talking to it," answers Papalini. "This is the transition that prompted me to write the book. As long as we use AI as an assistant, the cycle is simple: we ask a question, we receive an answer, and we evaluate it. The human being retains control at every step. But when we introduce an agent, we entrust it with a broader goal. The system reads the status of the work, chooses an action, uses tools, modifies files or data, checks the result, and decides whether to continue. At that point, the model is no longer the system. It is only a component of the system. The real engineering object becomes the loop that surrounds it: where we keep the goal, how we represent the status, what tools it can use, who verifies the result, how many times it can retry, how much it can spend, and when it must hand control back to a person. I isolated the loop because many companies are moving from copilots to agents, treating this change as a simple increase in model power. It is not. It is a change in the architecture of control."
The second question is the most uncomfortable, and I ask him without mincing words: in the book, you distinguish four levels—prompt, context, harness, and loop engineering—and yet ReAct already formalized cycles of reasoning and action, while the maker-checker concept has existed long before AI. Aren't you simply re-labeling well-established patterns?
"It is a legitimate question, and the honest answer is that almost no element of Loop Engineering, taken individually, is completely new," he admits. "The observation-action loop has existed for decades. The maker-checker is at the core of code reviews, separation of duties, and many control systems. Retry, timeout, circuit breaker, work queues, and human supervision are not inventions of generative AI. The novelty is not in the single brick, but in the fact that these bricks must be reassembled around a non-deterministic executor. It is a bit like what happened with DevOps. DevOps did not invent deployment, monitoring, versioning, or automation. It recognized that, to produce reliable software with continuity, those mechanisms had to be designed as a single operational and organizational system. Loop Engineering tries to do something similar for agents. ReAct describes a pattern with which the model alternates reasoning and action. It does not necessarily establish where the durable intent should live, who has the authority to declare the work completed, how the acceptance criteria should be protected, or how much the cycle can cost. A pattern explains how a part of the behavior can work. A discipline must also explain how to limit, observe, verify, and interrupt it."
Maker, Checker, Ralph
Here we enter the technical core of the method, with two operational patterns at the heart of the book: the separation between Maker and Checker, and the so-called Ralph Loop.
I ask him about the most obvious risk: the Checker can also be a probabilistic model, so how do we manage the danger of a "hallucinated approval"—a checker approving a wrong piece of work—especially when Maker and Checker share the same blind spots?
"Separating Maker and Checker is necessary, but not sufficient," Papalini explains. "If I ask a model to produce a result and then ask the same model, perhaps in the same conversation, if the result is correct, I have not built a truly independent check. I have simply asked the system to approve its own work. The risk increases when Maker and Checker share the same model, the same context, the same examples, and the same implicit interpretation of the goal. They can be two distinct agents and still share the same blind spot. This is why in the book I talk about protected verification. Whenever possible, the Checker should not just express a linguistic opinion. It should rely on external signals: tests, compilation, static analysis, schema constraints, policies, reference data, simulations, or deterministic checks. In software, for example, it is much better to ask the Checker to run a test suite than to ask if the code 'looks correct.' When a deterministic verification is not possible, we can reduce the risk by separating contexts, using explicit rubrics, different models, or human reviewers on high-impact cases. But we must be honest: a second model does not magically turn a probabilistic outcome into a truth. The Checker does not eliminate uncertainty. It makes it more visible and manageable."
Let's move on to the Ralph Loop, one of the operational patterns from which the book starts. I ask him how it works in practice and, above all, where it tends to fail, and if he has observed cases where the loop kept working without making real progress.
"The Ralph Loop was born from an almost provocatively simple idea: you provide an agent with a persistent goal and relaunch it multiple times with a fresh context, letting it read the state of the repository at each iteration and choose the next step," he says. "Its strength is precisely its simplicity. It reduces reliance on a very long conversation, makes the work persistent, and allows the agent to resume from what actually exists on disk, rather than relying solely on chat memory. But this simplicity also highlights the limitations. A loop can repeatedly modify the same files, fix a test while breaking another, declare a part completed that it hasn't actually verified, or consume iterations without reducing the distance from the goal. It can be very active without being truly productive. In my experiments, one of the most common behaviors was not a spectacular failure, but stagnation: the system keeps producing small variations around the same problem. It's like someone looking for their keys always in the same drawer because they are convinced they must be there. This is why the Ralph Loop is a good starting point, not a complete architecture. You need to add external success criteria, non-progress detection, budgets, edit limits, checkpoints, and escalation. As for specific corporate examples, I cannot speak about internal, non-public behavior. The book deliberately distinguishes between experiments, models analytical, and systems actually validated in production. It would be contrary to the very thesis of the book to present a limited experience as universal proof."
The Hidden Cost
Here the book addresses two independent criticisms, the economic and the architectural ones, and I put both to him.
Papalini introduces the concept of cost per accepted result. I point out to him that automation makes it easier to multiply calls to models, so doesn't Loop Engineering risk increasing total consumption while attempting to optimize it?
"Yes, the risk exists. Indeed, it would be naive to deny it," he responds. "When the perceived marginal cost of an action decreases, we tend to use it more. This is the mechanism behind Jevons' paradox: a more efficient technology can increase overall consumption because it makes doing much more things convenient. With AI, this is already happening. If an agent can generate ten implementations while we sleep, the risk is that in the morning we find ourselves with ten implementations to understand, verify, and perhaps throw away. This is why the number of tokens, on its own, is a terrible indicator. But so is its opposite: rewarding those who use fewer tokens does not automatically mean rewarding those who produce more value. The metric I propose is the cost per accepted result. The calculation doesn't just include tokens. It includes failed attempts, verification time, infrastructure, human labor, rework, and operational risk. A loop that costs 20 euros and produces a verified result can be cheaper than a single 2-euro call that generates an error discovered three weeks later. Conversely, an agent that keeps working for hours on a marginal task is simply an efficient machine at consuming budget. The point is not to minimize every call. It is to justify every iteration with a measurable reduction in uncertainty or distance from the goal."
The other criticism concerns vendor lock-in and what he calls conceptual debt in the book. I ask him what is really left of a system built today, if in a year the model used will already be obsolete.
"This is one of the reasons why I believe it is useful to shift the focus from the model to the loop," he says. "If a company builds everything around the proprietary features of a single provider, lock-in is inevitable. It doesn't just concern APIs. It concerns the format of the tools, memory, caching, system prompts, policies, evaluation systems, and even people's habits. The best way to reduce lock-in is not to pretend that all models are interchangeable. Today they are not. They have different capabilities, costs, latencies, and operational modes. However, we must separate what changes rapidly from what should last. The model should be a replaceable executor within reasonable limits. The intent, the state of the work, the acceptance criteria, the authorizations, the evidence, and the history of decisions should live outside the model and, as far as possible, outside the vendor's product. A year from now we might change Claude, GPT, Gemini, or a local model. But the plan, the tests, the rules, the data, and the ability to reconstruct why the system made a decision should remain. Then there is the understanding debt. If we generate code or documents in batches faster than we can read them, we are not eliminating work: we are pushing it into the future, with interest. The most dangerous lock-in is not always technological. It is becoming dependent on results that no one in the organization can explain anymore."
The Lost Apprenticeship
Let's move on to the operational weak points, those concerning people more than architecture.
I ask him the question I consider most delicate: if younger professionals spend their time supervising agents instead of writing, analyzing, and debugging firsthand, how will they build the experience necessary to become seniors? Don't we risk creating loop architects who don't know what is happening inside them?
"It is probably the most serious social risk of the entire transformation," he admits without hesitation. "You don't become an expert just by studying correct solutions. You become an expert by encountering errors, making wrong assumptions, reading difficult code, following a bug through different levels of the system, and learning to recognize weak signals. If we delegate this very part of the journey to AI, we can get juniors who are apparently very productive but lack the mental models necessary to understand when the system is going wrong. The paradox is obvious: we ask young people to supervise tools that produce work at a near-senior level, but we don't give them the time to build the experience to evaluate it. The solution is not to ban AI. That would be unrealistic and probably counterproductive. We need to design its use as part of the training path. In the book, I revisit the idea of trio working: a junior, a senior, and the AI work on the same problem. The AI accelerates execution. The junior must understand, modify, and explain the result. The senior does not just approve: they ask questions. Why was this structure chosen? What hypothesis supports the code? What happens when the external service doesn't respond? Which test actually demonstrates that the feature is correct? The rule should be simple: do not entrust an agent with an activity that the professional is not yet able to understand at least at a level sufficient to verify it. If we completely eliminate the grunt work, in a few years we might find that we no longer have people capable of designing the loops we pretend to supervise."
The other weak point is technical, and concerns what he calls Loop Drift, the system's tendency to slowly drift from the original intent after many iterations. I ask him how he manages it.
"The first rule is not to entrust the identity of the work to the model's conversational memory," he explains. "A long conversation is convenient, but it is not a reliable registry. Information is summarized, compacted, reinterpreted, and sometimes forgotten. After many iterations, the system can continue to be consistent with its own recent history and no longer with the original goal. For this reason, the intent must live in an external and durable state: a specification, a versioned plan, acceptance criteria, constraints, and decisions already made. At each iteration, the agent should reread these elements, not reconstruct them freely from its own memory. The second rule is to distinguish between facts, decisions, and summaries. A verified fact should not be rewritten at each step. A decision should have a rationale and, when possible, a reference to the evidence that supported it. Summaries produced by the model can be useful, but they must not replace the sources. The third is to check progress against external signals. If the goal is to pass 120 tests, the loop should not decide it has 'nearly finished' because the code looks better. It must show which tests pass, which fail, and how this situation changes over time. Finally, we need checkpoints and resets. Sometimes, adding more context makes the problem worse. It is healthier to restart with a fresh session, with the essential state and real evidence, than to drag along an already distorted conversation. Useful memory is not remembering everything. It is preserving what is needed without letting the narrative replace reality."
From Code to Customer
Let's close with the concrete case that the book presents outside the software domain, and with Papalini's vision on the fate of the term itself.
The book dedicates a case study to customer service, far from code. I ask him how it evolved during the writing process, what it wants to demonstrate, and what its real level of validation is.
"I included that case because I didn't want Loop Engineering to appear as a synonym for coding agent," he explains. "Software is the most visible laboratory because it has tests, repositories, compilers, and tools that make it easier to observe the agent's behavior. But the principles of the loop also apply when the result is a response to a customer, a report, a document check, or a commercial proposal. In the case study, the system receives a request, retrieves relevant information, prepares a response, compares it with policies, and decides whether to send it, revise it, or escalate it to a human operator. While writing, I realized that the most interesting part was not generating the response. That is relatively easy. The real problem was defining who had the right to send it. A response can be linguistically excellent and still be wrong: it could promise an unauthorized refund, use outdated information, or handle an ambiguous case with excessive confidence. The case study therefore serves to show that autonomy must be proportional to the risk. Simple, well-documented requests can go through the loop automatically. Ambiguous, financially significant, or emotionally sensitive requests must be escalated. It is important to be precise: the case presented in the book is a complete design model, built to show the method and its tools. It is not presented as an industrial system already validated on a large scale in production. Transforming it into empirical evidence would require a real pilot, measured data, comparison with a baseline, and error analysis. The book proposes the architecture. It does not pretend that an architecture on paper automatically equates to production evidence."
We close by looking ahead: a year from now, will we still be talking about Loop Engineering, or will the term become superfluous as is happening with Prompt Engineering? Can it become an autonomous discipline, similar to DevOps, or will it be absorbed by systems engineering?
"I hope that part of the term becomes superfluous," Papalini replies. "When a practice is truly absorbed by engineering, we stop considering it special. Nobody today is surprised by the fact that an application must have logs, monitoring, automated tests, and rollback procedures. They have become normal elements of the system. The same could happen with loops. In a few years, it might seem obvious that an agent must have an external state, a budget, success criteria, limited authorizations, and an escalation mechanism. But I don't think the problem will disappear. DevOps didn't disappear when pipelines became common. It changed. It became a set of practices, responsibilities, and skills that cross development and operations. Loop Engineering could follow a similar path, but I am not convinced that we immediately need new job titles or certifications. The tech industry already has a remarkable capacity to create roles before clarifying the work. Rather, I think these skills will enter existing roles. Developers will have to design checks and persistent states. Architects will have to think about authority and boundaries. Product owners will have to express verifiable goals. Risk managers will have to understand systems that do not always execute the same path. The name may change. But the problem will remain the same: how to transform a probabilistic executor into a reliable, verifiable, and governable system."
The book Non-Deterministic Loop Engineering by Enrico Papalini delves into, besides the topics discussed here, the practical implementation aspects of the Ralph Loop and governance models for progressive agent autonomy.