Everyone’s talking loops, and looping is the new new thing, but the reality is loops are not suitable to every task, every type of content, or every situation. Anatolik Kopadze recently posted on Twitter/X one of many sets of instructions on how to use loops, but some critical information is missing. Here’s a primer on loops, how and when to use them and when not to.

What is a Loop?

A loop is an AI task that runs itself. You hand the model a goal instead of an instruction, and it cycles through the work on its own: plan the next step, execute it, check the result against the goal, then feed what it learned back in and go again until the goal is met or a stop condition ends the run. The model carries its own state between passes, a running record of what it tried, what failed, and what comes next, so each iteration builds on the last instead of starting over. That is the whole idea, and it is genuinely powerful. It is also where every problem in this piece begins, because the thing doing the looping is a transformer, and transformers pay for every pass.

Loops Run on Borrowed Coherence

The loop is the current object of desire in AI. The pitch travels in a familiar shape: the best engineers have stopped prompting their agents and started designing loops that prompt agents for them, and everyone still typing one request at a time is behind. Kopadze’s widely shared explainer this summer walks readers from a five-stage loop, (discover, plan, execute, verify, iterate) through the automation stack in Claude Code, and lands where these things tend to land, on a product pitch for a Telegram assistant that will run your life on autopilot.

The mechanics in these explainers are broadly accurate. The physics are missing. A loop is a session, and sessions degrade. Everything else follows from that.

The 72-hour wall

Anthropic’s own long-horizon agent work has yet to move past roughly 72 hours of sustained coherent operation, and there is a reason for that. You can set all the goals in the world. Coherence limits are coherence limits, and once a loop reaches them it breaks down, quickly in some configurations, slowly in others, depending on how the loop is structured, how much scaffolding surrounds it, and how complex the instructions and content are.

The mechanism is visible in the explainers themselves, described as a cost problem rather than a coherence problem. Every iteration feeds the accumulated context back through the model: the goal, the state file, the last result, the record of what failed. That pile grows with each pass. The explainers note that this makes loops expensive. It also makes them mortal. Coherence erodes as context accumulates, and the erosion compounds exactly the way the token bill does. The longer a model reasons, the greater the likelihood a response will be incorrect, until incorrect outputs become more likely than correct ones. A loop is extended reasoning stretched across iterations. It sits on that curve from the first pass.

State is the cure and the poison

The loop literature treats state as the ingredient that makes loops learn: keep a small record of what was tried, what failed, and what comes next, and tomorrow’s run resumes instead of restarting from zero. True, and incomplete. That record is context, context is load, and load is what degrades the session. The mechanism that gives a loop memory is the same mechanism that kills it. Scaffolding, iteration caps, maker-checker splits, hard gates: all of it slows the decay curve. The curve remains.

Content sets the slope

Content ages at different rates inside a loop. Dense material, thick with proper nouns, cross-references, and multi-stage dependencies, burns coherence faster than boilerplate. Proper noun binding is among the first things to fail as context accumulates; under load, models begin leaking and swapping entity bindings well before they lose the thread of a task.

Which is why code loops mislead. Code is the friendliest content a loop will ever touch. Verification is binary: the test passes or it fails. State lives outside the model, in files, test suites, and version control. Resets are cheap. A loop that survives a week refactoring a codebase says little about a loop managing a calendar, a research corpus, or an editorial pipeline, where done is a judgment call, state lives inside the context window, and a wrong output looks exactly like a right one. The central error of the loops discourse is generalizing from the single domain where loops work best to every domain where they work worst.

The explainer, to its credit, includes a four-box test for whether a loop is worth building: the task repeats, something can automatically reject bad output, the agent can do the work end to end, and done is objective. Then it sells consumer life loops, journaling companions, streak coaches, content pipelines, that fail at least two of its own four boxes. Done in a journal is a judgment call by definition.

The verifier degrades too

Asking an agent to verify its own output puts the system that produced the error in charge of grading the error. Practitioners know this, which is why the standard fix is a second agent with different instructions, sometimes a stronger model on higher effort, checking the first. The fix works, temporarily. The checker is also a transformer running in a session, accumulating its own context load and degrading on the same curve, offset in time. Two agents grading each other buys an interval, and the interval ends. The only durable verifier lives outside the model entirely: a test suite, a type checker, a build, a human. Everything else is delegated decay.

Silent failure follows from the same physics. Engineers call it the Ralph Wiggum loop: the agent decides it is done too early, exits on half a job, and the loop keeps running and billing while producing nothing. The explainers frame this as a bug. It is a symptom. Degradation is gradual, so loops fade rather than crash, and a fading loop reports success in increasingly confident tones.

The economics turn on the same point. The metric that matters is cost per accepted change, and even the enthusiasts concede that below a 50 percent accept rate a loop costs more than it returns. Degradation makes the accept rate a declining function of loop age. A loop that clears the bar in week one can be underwater by week three while every dashboard shows green. Running fleets of agents in parallel multiplies exposure to the same limit. Every agent in the fleet sits on its own decay curve, and correlated failures arrive in bulk.

The Vigilance Protocol

• Test the loop before trusting it and measure what it consumes (both token volume and type).
• Time the breakdown to understand the variance in performance.
• Route checking through a different system, keeping in mind its own shelf life.
• Verify the output every single time it matters.
• Restart the session at the known degradation limit rather than after it.
• Build an external harness that performs verification outside any model.

Loops are usable. They are usable the way industrial machinery is usable, with maintenance schedules and inspection regimes, and the discipline looks like this. Test the loop before trusting it, and measure what it consumes: token volume and token type, because dense, complex content degrades faster than simple content. Time the breakdown. Some loops survive one run, some survive a week, and variance in performance persists regardless of content or duration. Route checking through a different system, knowing that system carries a shelf life of its own. Verify the output every single time it matters. Restart the session at the known degradation limit rather than after it. Build an external harness that performs verification outside any model. And decline to generalize from code.

Set it, watch it, know when it dies

The one-request-at-a-time habit the loop evangelists disdain has a property they undervalue: a human checks every output, so degradation gets caught at the speed it occurs. Loops remove that check and replace it with hope and a stop condition. There is no set it and forget it where transformers are involved. There is only set it, watch it, and know when it dies.

Jen Evans is Principal of Pattern Pulse AI and co-founder of Tech Reset Canada.