Loop engineering forgot the loop needs a memory

The control flow was never the hard part. What the loop carries between iterations is.

July 9, 2026 8 min read

In the span of about a month, a lot of good engineers stopped calling themselves prompt engineers and started calling themselves loop engineers. The pitch, which spread from a Peter Steinberger post that racked up millions of views within days and Claude Code's Boris Cherny saying he no longer hand-prompts Claude, is that hand-prompting an agent is amateur hour. The professional move is to design a loop: give the agent a goal and a stopping condition, then let it run act, observe, decide, repeat, on its own. Andrew Ng gave it the establishment blessing in his June 26 letter.

And then, days later, Mark Zuckerberg told his staff that AI agent development "had not accelerated in the way" executives had expected. Both things are true at once: the whole field is racing to hand agents the wheel, and the results from handing agents the wheel keep underwhelming. The gap between those two facts is the whole story, and it is not the one the loop-engineering pitch is telling.

The skeptics are right, which is why they miss it too

The backlash wrote itself. A loop is act, observe, decide, repeat, which is a while-loop, and we have had while-loops since before most of us were born. Dressing a while in a lab coat does not make it a new discipline. This is correct. The control flow of an agent loop is trivial, and anyone selling the control flow as the hard-won skill is selling you the easy half.

But the skeptics stop one step short. Yes, the loop is trivial. That is exactly the point, and exactly why "loop engineering" as a control-flow skill is a red herring. The reason your autonomous loop disappoints has nothing to do with the loop. It has to do with the one thing a bare while does not give you for free: what the loop carries between one iteration and the next.

You were the loop's memory, and you just fired yourself

Think about what actually happened when you ran the agent by hand, one prompt at a time. On each turn you were doing more than clicking go. You were re-supplying context. You corrected the thing it got wrong last time. You reminded it of the constraint it forgot. You said no, we decided against that approach, do the other one. Every manual iteration was a chance for you to inject what the model did not know.

That is precisely the human contribution Ng points at. He reframes the human's role not as taste but as information: "I prefer to think of it as humans having a context advantage." And he is explicit about why it cannot be automated away: "So long as the human knows something the AI does not, human-in-the-loop is needed to inject that knowledge into the system."

Now read the loop-engineering pitch again with that in mind. The entire selling point of the loop is that it runs without you in it. You are no longer in each iteration to inject the context advantage. So the obvious question, the one the pitch skips: if you are not supplying the missing knowledge on every turn anymore, who is? If the answer is nobody, then your loop is not carrying your decisions from one iteration to the next. It is re-deriving them from scratch each cycle, or never having them at all, and doing it at machine speed with no one watching. That is not automating your judgment. It is automating your amnesia and putting it in a while(true).

Why more autonomy makes this worse, not better

The intuition is that a more capable, more autonomous loop needs less babysitting. On this specific axis the intuition is backwards, and it is worth being precise about why, because it is not the usual "bigger models won't save you" point.

Autonomy is defined by removing the human from the iterations. But the human was not just overhead in those iterations; the human was the memory. Take the person out and you have not made the loop smarter, you have deleted the component that carried context from turn to turn. So the more iterations you let it run unattended, the more times it re-derives your decisions from whatever it can see, and the more consistently it converges on the wrong one, because the wrong one is usually the conventional default and your real decision was the deliberate exception it cannot see. A supervised agent that gets one thing wrong gets corrected on the next prompt. An autonomous loop that gets the same thing wrong gets it wrong on iteration two, and three, and forty, faithfully, until the stopping condition trips. Autonomy does not reduce the need for a durable decision memory. Autonomy is the thing that removes the only memory the loop had.

The amnesiac loop is also the expensive one

There is a bill attached to this, and it lands exactly where no one is looking. We have written before about the rediscovery tax agents pay, re-crawling the same docs every session just to relearn where things live. A loop pays that tax not once per session but once per iteration, and an autonomous loop runs many iterations with nobody watching the meter. Every cycle that re-derives a decision it could have simply been handed is a cycle spent generating an output that will be thrown away, then generating it again. The token spend that keeps surprising finance is not mostly the price of thinking. It is the price of re-thinking the same settled questions, on repeat, unattended. The loop did not just automate the amnesia; it automated the cost of the amnesia.

What the loop actually needs

If the loop is trivial and the state is the hard part, then the engineering worth doing is on the state. The loop needs a memory it can read on every iteration: the decisions it must honor, still current, retrievable at the moment it acts. Not in your head, because the entire premise is that you are no longer in the loop. Not re-crawled from raw sources each turn, because that is the tax. And not a static file you hand-maintain like an AGENTS.md, because a loop running unattended needs the decisions as they stand now, not as someone last remembered to write them down. A persistent, shared, authoritative record of what your team has decided, kept current, that the loop consults each cycle the way you used to remind it by hand.

What that record has to be, and how the loop pulls only the few decisions that bind the task in front of it rather than the whole history, are the subjects of earlier posts here, so I will not re-derive them. We build Brief to be that memory, the thing the loop reads each turn in your absence. But you do not have to take our word for the conclusion, because it is not really about us. It is the one part of the loop the loop-engineering pitch left out, and it was the only part that was ever hard.

Design the loop in an afternoon; it is a while-loop, the skeptics are right. Then spend the real effort on what it remembers between turns, because a loop with no memory of your decisions does not run your judgment on autopilot. It runs your blind spots on autopilot, and bills you per lap.

Frequently asked questions

What is loop engineering? It is the mid-2026 idea, popularized by Peter Steinberger and Boris Cherny and formalized by Addy Osmani and Andrew Ng, that the skill has shifted from writing prompts to designing the loop that runs an agent autonomously: you set a goal and a stopping condition, and the loop iterates act-observe-decide-repeat on its own instead of you prompting each step.

Is loop engineering just a fancy while-loop? The control flow is, yes, and the skeptics are right to say so. But that is why it is not where the difficulty lives. The hard part of an autonomous loop is not the iteration mechanism, it is the state the loop carries between iterations, specifically the decisions and context it must honor each cycle without a human present to supply them.

Why does my autonomous agent keep making the same mistake across iterations? Because nothing is carrying the correction forward. When you prompted by hand, you re-injected the fix each turn. An autonomous loop has no memory of your decisions unless one is provided, so it re-derives them every iteration and lands on the same wrong default until it stops.

Will a smarter or more autonomous model fix this? No, and more autonomy makes it worse on this axis, because autonomy is defined by removing the human who used to supply the missing context on each turn. A better model reasons better over what it can see; it cannot see a decision that lives in no input it reads, no matter how capable it is.

Why is my autonomous loop burning so many tokens? Largely because it re-derives settled context every iteration instead of being handed it. Rediscovery is a per-cycle cost, and an unattended loop runs many cycles, so the waste compounds precisely where no one is watching the meter.