Press ESC to close

Why the Simplest AI Agent Loop Beats a Sophisticated One

An AI agent is only as trustworthy as the check on its work. The loop that runs it barely matters.

If you follow AI engineering at all, you have probably seen Ralph go past this year. It has been written up in The Register, listed in the 2026 coding-trend roundups and turned into a small genre of blog posts, most of them some version of “everything is a ralph loop.” The technique itself is one line of shell: 

while :; do cat PROMPT.md | claude-code; done.

A prompt file, piped into a coding agent, on repeat, forever. No planner, no executor, no reviewer agent grading a worker agent’s output. No graph of coordinated roles. Geoffrey Huntley, who named it, has used it to build real software on greenfield projects, and says it delivered work worth tens of thousands for a few hundred dollars in tokens. The dumbest loop you could build produces working code.

Most of the coverage treats Ralph as a curiosity or a way to ship features while you sleep. The more useful question is why something this crude works at all. Ralph should not sit comfortably next to the rest of the industry. The tooling sold to make agents reliable is mostly orchestration: frameworks that coordinate multiple agents, assign roles, route tasks and review outputs. The premise underneath all of it is that autonomy is a coordination problem and that reliability comes from coordinating better. Ralph has none of that machinery and works anyway. Either that machinery is wasted, or the reliability it promises was never coming from there.

Strip the loop and see what holds it up

Take a system down to nothing and whatever is left standing was the load-bearing part. Ralph takes the loop down to a single line, so look at what it refuses to drop. Two things. A specification: files written up front that say what the software is for and what “done” means. And a verifier: the tests and the build that run on each pass and come back pass or fail. Every trick Huntley adds to make Ralph work sharpens one of those two. One task per loop. Fresh context every iteration, on purpose, so the agent is not dragging stale state forward. After a change, it runs the tests for the unit it just changed, and it leaves notes for the next pass, which will remember nothing. The loop stays dumb. The specification and the check do the work.

The same technique that builds a greenfield project falls apart on an existing one, and the reason is the verifier. Huntley is blunt about the limit: “there’s no way in heck would I use Ralph in an existing code base.” The loop is identical in both cases. What changes is the check. On a clean project you can state what done looks like and write tests that prove it. Drop the same loop into a large existing system and you cannot cheaply say what correct means, let alone test it automatically, so the loop runs with nothing reliable telling it when it is wrong. The loop was doing the same thing in both places. What failed was the check, and the check was carrying the whole thing.

You have done this before, without the AI

Anyone who has run a delivery team already has words for this. The specification Ralph runs against is a user story with real acceptance criteria: the specific conditions the work has to meet before it counts as finished. The verifier is the definition of done, turned into a test that runs on every pass. A good team has always insisted that done means something you can point at and test, and not a developer’s private sense that the ticket is complete.

What Ralph does is clear everyone out of the room except that discipline. There is no engineer whose judgement quietly fills the gaps in a vague story. There is no reviewer who reads the pull request and senses that something is off. All that is left is the story and the acceptance criteria, running on repeat. If your definition of done was real, the loop delivers against it. If it was a line everyone nodded at in planning and no one could check, the loop runs straight past the point where the work stopped being correct, and nothing pulls it back.

The teams that will get the most out of agents are the ones that were already strict about this. A clear user story. Testable acceptance criteria. A build that goes red the moment the work breaks. That was good practice long before the agent arrived, and it was easy to be lax about, because a person was quietly compensating when the definition of done was thin. Take the person out and the thin definition is all you have.

A verifier is a measurement instrument

None of this is special to coding agents. A verifier tells you, while the system is running, whether what it just produced is acceptable. That is the job operational telemetry does in a governed system: the runtime signal that a decision landed inside the acceptable range or outside it. A verifier that can stop the loop is a hard constraint. The system cannot talk its way past it the way it can ignore a line in a prompt. When a loop runs until its tests pass, something real decides when it stops. A loop that runs until it judges itself finished has nothing real deciding for it at all.

The question to ask about any agent

Stop asking how sophisticated an agent’s orchestration is. Ask what the verifier is, and whether you can state it.

Ask it when you evaluate a product. A vendor walking you through how their agents plan, coordinate and review each other is showing you the loop. Ask what checks the output, and how you would know it had failed. If the answer is that the model reviews its own work or that the system is capable, there is no verifier. You get output that looks right, made by something confident, and nothing is testing whether it is right. That is not control. You are trusting the output because it looks convincing, and hoping it holds up.

Ask it about your own build. If you are reaching for an orchestration framework to make your agents trustworthy, you are spending on the layer Ralph showed was optional. The reliability you want comes from a check you can name and enforce, and that is usually cheaper to build than the coordination you were about to license: a test suite, a schema that rejects malformed output, a rule that halts the run when a number leaves its expected band.

Then the honest limit. Not all work has a verifier you can state, which is why Ralph is a greenfield tool and not a general one. Some tasks have a clean definition of done and a cheap automatic check, and those you can hand to a dumb loop and walk away. Others have neither, and handing those to autonomy of any kind, crude or elaborate, means trusting output you have no way to test. Knowing which of your work is which is the decision that matters, and it is an architecture question that sits with you, not with the framework.

The loop was never the thing to fix

Ralph is worth understanding for what it shows you. Take the orchestration away and you can see what was holding the system up the whole time. Every agent you run has a check somewhere in it, whether you named one or not. If you cannot say what that check is, the loop was never the thing you needed to fix.

I have been building a small tool that turns that check into a real part of the loop: something with a name, written down on every pass and able to stop the run instead of just noting a complaint. That is the next piece, with the code.

Sources

Related reading (Synaptic Pixels):

Leave a Reply

Your email address will not be published. Required fields are marked *