The Loop Is Simpler Than It Sounds
A dumb little trick that keeps its progress on your hard drive, not the model's head, and the three questions that decide whether it pays off or burns you while you sleep.
A few weeks ago I argued that the harness is the moat: the system you build around the model is the part nobody can copy, and the model itself is a commodity you order off a price sheet. Today I want to go one layer in, to the thing that runs inside the harness. The people building fastest will tell you it is the whole ballgame.
They call it the loop, and it is suddenly everywhere. Anthropic shipped it as a product feature this summer. A conference talk naming it went around the engineering world. The slogan it produced gets repeated like scripture: the winners will not have the smartest model, they will have the best loop.
The clearest signal is the person who built Claude Code. Boris Cherny says he has not written a line of code by hand in eight months, and that is not the part he finds remarkable. Going from writing code to prompting a model was the small shift. The big one is going from prompting to loops: he no longer types instructions, he writes loops that prompt the model for him, and his whole job is building and steering them. Some mornings he is managing a few hundred agents, some days thousands.
And it works. Anthropic now ships a real share of its own code this way, at scale, and says so on the record. A team points a loop at a written spec and lets it grind through a feature overnight, then reviews a pull request in the morning instead of writing one. The wins are not hypothetical, and that is why the idea caught fire. If you want the full case, the sources, the skeptics, and the cost numbers nobody pitches, I ran a 30-day sweep across every platform where people argue about AI and wrote it up as the companion to this piece. What follows is the argument it grounds.
Here is what the slogan tends to leave out. The loop is the easy part. It is a small, almost silly mechanism that you could understand in the next five minutes and copy in an afternoon. Everything that decides whether it helps you or quietly sets fire to your budget lives around it. So let me do two things: show you what the loop actually is, in plain terms, and then hand you the three questions that separate a loop worth running from one that runs you.
The loop is the easy part. The hard part is everything bolted around it.
What a loop actually is
Start with the thing itself, because it is simpler than the vocabulary around it.
A coding agent runs inside a plain repeating cycle. You hand it a written spec, a page describing what you want built. It does one small task, saves the result to a file, records that step, and then you throw away everything it was thinking and start a fresh copy from scratch. The fresh copy reads the same spec, reads the files the last one left behind, sees what is already done, and picks up the next task. Around and around until a check you wrote says the work is finished.
That is the whole trick. The engineer who named it, Geoffrey Huntley, called it Ralph, after Ralph Wiggum, precisely because it looks too dumb to work. No memory. No accumulation. A cheerfully oblivious worker waking up new every pass, with no idea it has been at this for hours.
And it works because it is dumb. A fresh worker never drowns in its own earlier confusion. The reason your long chats with an AI start to drift and contradict themselves is that the context fills with everything said so far, and the model loses the thread. The loop sidesteps that by refusing to carry a thread at all. It keeps the progress somewhere safer than the model's memory: in your files and your saved history, which do not get wiped.
That is the one idea to carry out of here. The model's memory is scratch paper. The real state of the work lives on disk. Once you see that, the loop stops being magic. It is a short block of code with a model call inside, about six lines, and every serious version lands on the same tiny shape. There is no proprietary one to buy. This is the hand-rolled hack Anthropic just turned into a button: Claude Code's /loop runs a command on a cadence, and /goal sets the condition that tells it to stop. The bash trick became a supported feature, which is usually the sign something has gone from clever to standard.
You would want one because it changes what a person does all day. You stop producing the work and start describing it and checking it. That shift, from writing the thing to knowing what to ask for and telling whether you got it, is the one Anthropic found predicts who succeeds across 400,000 sessions. You write down what "done" looks like, point the loop at it, and come back to review instead of to type. That is useful, and it is also where every problem starts. A thing that works unattended for hours is a thing making decisions you are not watching. Which brings us to the part the slogan skips.
If the loop is settled and small, the interesting question is not how to build a better loop. It is three questions about the system around it.
The first question: how do you know it worked?
The single most important piece of a reliable loop is the part that can tell it no.
An Anthropic engineer described the pattern: before the agent writes a single line, two agents negotiate what "done" means, and a third exists only to check the work against that definition. The loop does not run until there is a test it can fail. The failing test carries the weight, not the loop itself. You build the thing that says no first. The loop comes after.
The reason to build it first is a piece of arithmetic that belongs on a slide in every project like this. Melanie Warrick, who works on this at Temporal, ran the numbers: even if every step in a job succeeds 85% of the time, a ten-step job finishes correctly only about 20% of the time. The failures multiply. Miss one step in five, ten times running, and a clean pass becomes rare. The gap, she found, is not intelligence. The agents "diagnose a failure in perfect detail and still do nothing to recover from it." They describe the wall in detail and walk into it anyway.
It gets worse inside a single run. A model's attention decays as the loop goes on, and there is now a benchmark built to predict where it breaks. One study found a rule honored 73% of the time early had fallen to 33% by sixteen steps later. The agent did not rebel. It forgot, the way a tired person forgets, and kept going with the rule half-erased. The fix is unglamorous: re-state the hard constraints on every pass, and never assume a rule set once stays set.
None of that is loop engineering. It is checking-the-work engineering, and it is most of the actual job. A loop with no part that catches a bad result is not a loop. It is a fast way to be wrong at scale.
Even at 85% success per step, a ten-step job comes out clean only about one time in five.
The second question: what did it cost?
The economics of a loop break the way most people budget for software, and the people who learned this learned it expensively.
A chat costs you a sentence at a time. A loop runs for hours, calls the model hundreds of times, and has no natural stopping point unless you give it one. So the unit changed underneath you. It is no longer cost per question asked. It is cost per finished piece of work, and that number is wild.
One study measured the same task, same model, same prompt, same everything, and found it could cost eight dollars or two hundred forty. Thirty times apart, with nothing changed on the input, the spread tracing to how the loop was set up rather than which model ran it. The cost of letting a loop run is not a price you can quote in advance. It is a range, and the high end is far away.
This is not theoretical. Uber, by one widely-shared account, burned its entire annual AI coding budget in four months running agent loops, then capped its engineers at fifteen hundred dollars a person. The production version of the loop is not the demo that builds an app while you sleep. It has a spend cap, a meter, and someone who gets a phone alert when the meter spins.
Then the part that should give anyone budgeting for this pause. Checking the work can cost more than doing it. One team spent around forty thousand dollars just on the runs to verify their results, and noted that checking rigorously enough to fully trust them would push into the hundreds of thousands. If the whole promise of the loop rests on a reliable way to confirm it is done, and confirming "done" at scale is the most expensive line on the page, that is a cost nobody put in the pitch.
The answer the field is settling on is sensible. Run most of the loop on a cheap, fast model, and save the expensive top-tier model for the few hard steps that actually need it. Most steps do not need the smartest model in the building. You pay top-tier prices only where top-tier reasoning earns them.
That rule hides a deeper one, and it is the subject of my next essay, Nobody Saves Money on the Model: a cheap model is not a discount, it is a bet that you removed the ambiguity before the loop ever ran. The saving was never in the price per call.
The third question: what is it allowed to do?
The last piece is the one the "no human needed" crowd skips, and it is the one that ends careers.
A loop that runs for hours without supervision is, by definition, taking actions you are not watching. Late last year an autonomous coding agent, asked to clear out some temporary files, wiped a user's drive instead. It did what an unbounded loop does: it took an action it could not undo, in perfect confidence, with no gate in front of it. The failure was not that the agent was dumb. It was fast, capable, and unsupervised all at once, which is a different and worse problem.
The fix is structural, and it looks the same every time: checkpoints, hard limits on how long it can run and how much it can spend, and a human sign-off on anything the agent cannot take back. The companies actually running these in production are not running pure AI. They run a mix: the model reasons, ordinary tested code does the irreversible parts, and a person approves the steps that matter. One builder put it plainly. Most agentic loops are not autonomous. They are automated failure.
There is a newer worry above even that. An agent with standing permission to act is a kind of insider you have never had on the payroll. It holds credentials, runs unattended, and can do in a loop at three in the morning what a confused employee could only do at a desk by day. The risk was never which model you use. It is what permissions the loop carries, and whether you can pull them back in a hurry.
This is why the adoption numbers tell a sober story. By one survey, 79% of companies have adopted these agents and only 11% run them in production. Gartner projects 40% of agentic AI projects will be canceled by 2027, and the reasons are not "the loop didn't work." They are cost, unclear payoff, and the governance gap above. The loop is the easy part. Everything I just walked through is the distance between a demo and a deployment.
An agent with standing permission is an insider that never sleeps. The only question that matters is whether you can take the keys back.
Where this leaves you
Here is the whole thing in one breath. The loop is a dumb little cycle that keeps its progress on your hard drive instead of in the model's head. You could run one. You might well want to, because it turns making the work into describing and checking the work. And whether it pays off has almost nothing to do with the loop and almost everything to do with three answers most teams cannot give.
Do you know when it worked? Do you know what it cost? Do you know what it is allowed to touch?
That is not a coding question, which is the good news for anyone reading this who does not write code. Knowing what good looks like, catching a confident machine being wrong, deciding what it may and may not do without a human in the room: that is the judgment AI didn't make cheap. A loop does not supply it. A loop spends it.
A year from now your competitor will run the same six-line loop you do, against a model that costs about what yours does. Both will be things you order off a shelf. So the question is not which loop to build. It is whether, when your loops are running overnight, you can answer those three. Most teams cannot, and that, not the loop, is the work of this year.
The receipts behind this argument, the sources, the skeptics, the cost numbers, and the one stat I refused to print, are in the 30-day sweep linked up top. Run Data Run is free. If this was useful, the easiest way to support it is to subscribe and forward it to one person on your team who'd want it. If it wasn't, tell me why. I'll make it better.