(3/3) The Loop Was Never the Hard Part — The Guardrails Are

Getting a model to perceive, reason, plan, act, and observe in a cycle is the easy part now. Frameworks give you that loop in a few lines. The hard part — the part nobody's framework does for you — is everything that stops the loop from quietly running away with your money, your production data, or both.

I said in part one that AutoGPT's real failure, back in March 2023, wasn't a weak model — it was the missing stopping condition, and the field has mostly relearned that lesson piecemeal ever since, one runaway API bill at a time. Three years in, the mechanics of the loop are a solved, published, benchmarked problem. What separates a demo from something you'd let touch production isn't a smarter model inside the loop — it's the discipline wrapped around it. Call that discipline loop engineering: it's a short, specific list of guardrails, and most incidents trace back to one of them being skipped.

A cap on iterations that fires no matter what the model claims

The first guardrail is the most basic and the most often missing: a hard maximum on how many cycles a loop can run, enforced outside the model, that fires even if the model's own output insists it's one step from done. This sounds too obvious to write down until you remember AutoGPT shipped without it — the tool that made "agentic" a household word in engineering circles didn't have a hard ceiling on its own loop, and users regularly found it still running, and still billing, well past the point the task had any chance of succeeding. A model asked "are you done" will frequently say no when it should say yes, and yes when it should say no; a cap that doesn't ask its opinion is the fix.

A budget ceiling, because tokens are the unit that runs out

Part two covered why architecture is a cost curve — a multi-agent system can run at roughly 15x the tokens of a plain chat interaction, per Anthropic's own published numbers on their research system. A loop engineered without an explicit budget ceiling doesn't fail loudly when it hits that multiplier; it fails as a bill, days later, once someone reads the invoice. The fix is boring and non-negotiable: a token or dollar ceiling enforced at the infrastructure layer, independent of the loop's own accounting, because a loop that's already misbehaving is the last thing you want responsible for tracking its own spend.

Detection for the failure mode that looks like nothing happening

Iteration caps and budget ceilings catch a loop that's doing too much. A quieter failure mode is a loop that's doing nothing new — cycling through the same unproductive move, re-reading the same file, re-trying the same failing call, without making measurable progress toward the goal. This one needs its own check: compare state across iterations, and if nothing meaningfully changed for N cycles running, stop and flag it rather than let the cap eventually catch it after burning the full budget on a loop that was stuck three iterations in.

Context rot is a production failure mode with a name and a paper now

There's a second, subtler version of "stuck": a loop that's still producing new output each cycle, but the output is getting worse as the transcript grows, because the model's own accumulated context is degrading its reasoning. Chroma Research's July 2025 report, "Context Rot: How Increasing Input Tokens Impacts LLM Performance" (Hong, Troynikov, and Huber), evaluated eighteen frontier models and found accuracy degrading non-uniformly as input length grew — well before hitting a model's stated context limit — with a specific, counterintuitive finding: models performed worse on long documents that were logically coherent than on the same length of shuffled, incoherent text. A long-running loop keeps appending to its own transcript by construction, which means every extra cycle is quietly taxing the exact resource the paper shows degrading. A loop that never trims or resets its context is spending its own reasoning quality down, cycle by cycle, whether or not anyone's watching for it.

One deliberately crude answer to that problem is worth naming because it inverts the instinct to keep more context, not less: Geoffrey Huntley's "Ralph Wiggum" technique (ghuntley.com, May 2025) runs a coding agent in a bash loop against a persistent task file, but resets the model's context window on every iteration — nothing carries over in the transcript. State survives instead in the filesystem and the git history, external to the model entirely. It's a brute-force answer to context rot: if a long transcript is the thing quietly degrading reasoning, don't keep a long transcript — keep the durable state somewhere that doesn't decay, and let the model start each cycle fresh.

Orientation, not just observation, before the next action

The perceive-reason-plan-act-observe cycle from part one has an older cousin worth borrowing from: John Boyd's OODA loop — Observe, Orient, Decide, Act — which he developed through the 1970s and formalized in briefings like "Patterns of Conflict" in the 1980s, originally to explain why one fighter pilot could out-decide another in combat. The detail most software borrowings of OODA drop is the orient step, distinct from observation itself: it's the explicit act of checking a new observation against your existing model of the situation before deciding what it means. An agentic loop that jumps straight from "observe the tool's output" to "decide the next action" skips exactly this step, and it's usually where the loop I described in part one — the one that reasons forward from a stale or wrong picture of the world — goes wrong. Orientation is the guardrail that catches a bad observation before it becomes a worse decision, not after.

A checkpoint before anything irreversible, that a human has to clear

Every guardrail above is about keeping the loop's own behavior bounded. This last one is about what the loop is allowed to do to the world without asking first. Deleting data, sending an email, pushing to a shared branch, spending real money outside a sandboxed budget — actions like these need an explicit human checkpoint the loop cannot route around, not a config flag it can reason its way past if it decides the situation warrants it. The other guardrails bound how long and how much a loop runs; this one bounds what it's allowed to do while it's running, and it's the one that turns a runaway loop from an expensive mistake into an unrecoverable one if it's missing.

Yes, every one of these guardrails costs you speed

The honest objection to all six of the above is that they slow the loop down — an iteration cap means it stops before it might have finished on its own, a human checkpoint means a real pause instead of unattended execution, an orient step means an extra pass before every decision instead of straight to the next action. That's true, and it's not a bug to be optimized away once you trust the system more. The entire value of an unattended loop is that nobody's watching it turn tokens into actions in real time; the entire risk is exactly the same thing. Every guardrail here trades a slice of that unattended speed for the ability to walk away without checking every cycle — which is the actual point of building a loop in the first place, not a tax on it.

What I'd put in place before turning any loop loose

1. A hard iteration cap, enforced outside the model, that fires regardless of what the model's own output claims.
2. A budget ceiling — tokens or dollars — enforced at the infrastructure layer, not inside the loop's own accounting.
3. No-progress detection that compares state across cycles and flags a stall before the cap eventually catches it.
4. A context strategy — trim, summarize, or reset like Ralph does — so reasoning quality doesn't quietly decay as the transcript grows.
5. An explicit orient step that checks each new observation against the loop's existing model of the situation before it decides the next action.
6. A human checkpoint on anything irreversible, that the loop cannot reason its way around.

The loop is the easy 20%; this is the other 80%

None of these six guardrails require a smarter model. They require the same discipline that's kept production systems alive since long before "agentic" was a word anyone used: know when to stop, know what something costs, notice when it's stuck, and never let it do something you can't undo without asking first. That's the throughline across this series — a trigger and a verifiable goal from part one, an architecture chosen for the actual shape of the task from part two, and the guardrails here that make the whole thing safe to leave running. Get all three right, and a loop pulls its weight without you watching it. Skip any one, and you have AutoGPT's problem with a better model attached to it.

If you're building one of these and want a second opinion on where the guardrails should sit, get in touch.