AI loops : the real shift, and the dependency they sell you with it
For a few weeks now, the same word has been surfacing across every feed run by the accounts that make their living on AI: the loop. The message is always identical. You shouldn’t be prompting your agents anymore, you should be designing the loops that drive them. It’s delivered with the confidence of the self-evident, propped up by two or three quotes from respected engineers, and it almost always ends with a link to some miracle product.
The annoying part is that, on the merits, they’re right. The concept is real, it’s even central. What they never tell you is what that loop actually costs, and above all who it ends up belonging to. This article is about both.
Let’s start by defining the thing properly, because you can’t criticize what you haven’t defined.
What a loop actually is
A prompt is a single instruction. You ask, the model answers, and it stops. Until you prompt it again, nothing moves. You are the engine; the AI is only the tool in your hand, and a tool does nothing on its own. This is how almost everyone uses AI today: one request at a time, every step routed through you.
A loop is something else. It’s a goal the AI pursues on its own until it gets there. You define the objective once, and the system iterates until it’s met. Think of it as a recursive goal. The full cycle comes in five beats:
DISCOVER → work out what needs doing
PLAN → decide how to do it
EXECUTE → do the work
VERIFY → measure the result against the goal
ITERATE → not there yet? feed the result back in and repeat
Code language: Shell Session (shell)Of these five steps, three do all the work, and they’re exactly the ones people get wrong.
Verification is the heart of the loop. Without a real check on the output, you don’t have a loop, you have an agent agreeing with itself on repeat. The check is what turns repetition into progress: a test that passes or fails, a measurable condition, a scoring rubric. With no objective exit gate, the model grades its own paper, and whoever did the work always makes far too generous a grader.
State is what lets the loop learn. On every pass, the agent has to remember what it already tried, or it repeats the same mistake forever. A real loop keeps a small ledger on the side: what’s done, what failed, what comes next. The next pass resumes instead of starting from scratch.
The stop condition is what keeps it sane. A loop with no exit runs until it succeeds, breaks, or drains your account. Every serious loop has two ways to stop: success, and a hard limit (after eight tries, stop and report). Skip this and you’ve built a machine that can run all night for nothing.
In one sentence: a prompt hands the AI an instruction; a loop hands it a job, a way to know when that job is done, and a rule for when to give up.
So much for the framing. Now for the part the promotional threads skip over.
The four-box test: when the loop is a trap
You’re sold the loop before anyone tells you when it’s a mistake. Yet the test serious people actually apply is simple. A loop is only worth building when all four of the following are true at once.
The task recurs, at least once a week. Below that, the setup cost never pays for itself. A one-off job is still better served by a single good prompt.
Something can automatically reject bad output. A test, a type check, a build, a linter, a hard rule. If nothing can fail the work for you, the loop just spins.
The agent can genuinely do the work end to end, without handing half of it back to you.
“Done” is objective, not a matter of judgment. If quality is a question of taste, a human still wins.
Miss one box, and keep the prompt manual. The honest version of this whole topic is right there: loop engineering is real, and most people don’t need the heavy version yet. That isn’t a shortcoming, it’s clarity. What everyone can use is the light version, which we’ll get to. But you should know where the line falls.
The only number that matters
Loops run on tokens, and tokens are money. The problem isn’t that each step costs something, it’s the way the cost compounds.
On every pass, the agent rereads its context: the goal, the code, the last result, what failed. That whole bundle goes back through the model on each iteration, and it grows with every pass. A loop that runs ten times doesn’t cost ten prompts, it costs ten prompts each of which keeps swelling. The split between the maker and the checker, the very thing that raises quality, also doubles the bill, since two models now read the work instead of one.
ROUGH COST OF ONE LOOP
single agent, medium task: ~50,000 to 200,000 tokens
context re-sent every iteration: grows with each pass
a fleet of agents in parallel: multiply everything above
Code language: Shell Session (shell)The metric that actually matters, and that almost no one tracks, is cost per accepted change. Not tokens spent or loops run. If the loop hands you ten results and you throw six away, you’re redoing the review work it was meant to spare you. Below a 50% acceptance rate, it costs more than it returns.
Loops also fail quietly. The engineer Geoffrey Huntley calls it the “Ralph Wiggum loop”: the agent declares itself done too early, exits on a half-finished job, and the loop keeps running and spending while producing nothing. Without a hard gate that can fail the work, loops don’t crash, they bill you in silence.
That’s why the heavy version belongs to teams with the budget and the guardrails to run it: iteration caps, token budgets, cheap models on the boring steps, monitoring. If that isn’t you, you’re not missing out: the core idea works at a fraction of the cost and with none of the setup.
So far I’ve only brought some sobriety to a conversation that never has any. But the heaviest cost is still missing, the one none of these threads ever bills you for.
The cost no one bills you for: sovereignty
Look at where all these threads land. Invariably on the same move: a proprietary product. A bot inside Telegram, a third-party connector that plugs into “500-plus apps,” a long-term memory hosted somewhere else, a model picked for you depending on the task. The sales pitch is always the same reassuring trio: no code, no hosting, no keys.
Let’s sit with that promise for a second, because it’s the exact opposite of what anyone who thinks twice should want. “No keys” means you hand over yours. For one of these loops to prepare your morning brief from your inbox and your calendar, you have to give it access to your inbox and your calendar. For it to “remember you between conversations,” it has to store what it learns about you, on servers you don’t control, in a jurisdiction you never chose, under terms of service that will change without asking you.
You’re sold convenience, and the convenience is real. But it comes at the price of dependency, and dependency never appears on the quoted bill. You don’t only pay in tokens. You pay in data, in attack surface, in a single point of failure that sits off your premises, in your ability to walk away the day the service shuts down, raises its prices, or decides your usage no longer suits it. An agent that “acts instead of answering”, that sends the email instead of drafting it, that files the ticket instead of suggesting it, is precisely an agent you’ve granted the power to act in your name inside your own systems. The question is no longer “is this convenient,” it’s “who did I hand that key to.”
This is exactly the blind spot in all the content flooding the feeds right now. It treats the loop as a feature, never as a delegation. Yet a loop is first of all a delegation: you step out of the circuit, and something carries on the work in your place. The whole question is whether that something belongs to you.
The sovereign version of the loop
The good news is you don’t need anyone. The entire mechanism can be rebuilt at home, and it comes in two tiers.
The light tier first, because it asks for nothing. You can run a loop by hand inside any LLM, with a single prompt. The trick is to give the model all three parts at once: a goal, strict success criteria, and a protocol that forces it to check itself before it’s allowed to stop.
SELF-CHECKING LOOP (paste into Claude)
You will work in a loop until the task meets the bar.
TASK:
(describe exactly what you want produced)
SUCCESS CRITERIA (strict, no soft passes):
- (criterion 1)
- (criterion 2)
- (criterion 3)
LOOP PROTOCOL, repeat every turn:
1. PLAN - state the single next step.
2. DO - produce or improve the work.
3. VERIFY - score the result 1 to 10 on each criterion.
Be brutally honest. List what is still weak.
4. DECIDE - if every criterion is 8 or higher, print "FINAL" and stop.
Otherwise print "ITERATING" and go again, fixing
the weakest point first.
RULES:
- Never call it done while any criterion is below 8.
- Each pass must fix the lowest score from the previous VERIFY.
- Do not ask me questions. Make a reasonable assumption, note it,
and keep going.
Begin. Run the loop until FINAL.
Code language: Shell Session (shell)The model drafts, scores its own work against your criteria, finds the weak spot, and goes again, until it clears the bar instead of handing you the first thing that looked close. That’s a loop, and you just built one with a paragraph. It comes from nowhere, stores nothing, plugs into nothing. It lives only as long as you’re watching it, and vanishes the moment you close the tab. For 99% of everyday needs, that’s enough, and it’s free.
The heavy tier next, for those who genuinely need it, but on your own ground. Everything the proprietary products assemble for you, you can assemble yourself, on your own infrastructure. An agent like Claude Code already ships the building blocks: a trigger, reusable instructions, the maker/checker split, real actions through connectors, and the verification gate. The trigger isn’t a third-party service, it’s a cron job or a systemd timer on your server. The planning is your hooks. The actions are MCP servers you write yourself, against your own systems. And the gate, the one element that decides whether the loop helps you or ruins you, is your own tests, in your own repository, under your control.
In this model, state and verification never leave your infrastructure. The loop’s memory is a database you host. The keys stay your keys. It’s more work up front, no one will pretend otherwise. But that’s exactly what autonomy means: it carries an entry cost, not a rental fee. You pay once to own your stack, instead of paying every month to depend.
My take
Loops aren’t a fad. They mark a real shift in who does the work: the AI stops waiting to be pushed through every step and starts running the whole job on its own. The concept is solid, it’s even important, and there’s no point playing the reflexive skeptic.
That said, it isn’t something to chase or to force where it has no business being. Most of the time, you’ll burn money for nothing. Start with what’s already there and free, the light loop inside an LLM, and only think about the heavy version once you’ve genuinely felt that it isn’t enough.
And when you do, ask the only question that counts. Not “which product saves me the most time,” but “who owns this loop.” Because the real luxury here isn’t the agent that does everything for you. It’s the agent you own. The tool is real, the shift is real. What’s left is not to mistake the autonomy it promises for the dependency sold alongside it.