Loop Guardrail

Loop Guardrails: Five rules that let AI run on its own without running past the safety limits

Harness Engineering governs the boundaries; Loop Engineering governs the improvement. Once AI starts working automatically, lap after lap, what you need is the thing that ties the two together: guardrails.

Published 2026-07-06 | Last updated 2026-07-06

What is this article talking about?

AI is increasingly able to work continuously and on its own: it finishes one step and moves to the next, spins off its own sub-tasks, and checks its own work. The thrill is the speed, and so is the danger: a single unchallenged bad judgment gets amplified by every lap that follows. This article lays out the five loop guardrails I actually use. They join the boundary thinking of Harness Engineering with the improvement thinking of Loop Engineering.

Who this is for

· People who already let AI run tasks automatically, lap after lap, and are starting to worry that "it's going too smoothly, which is suspicious"
· People who often hand work off to a second AI or a sub-agent and find that things drift off the rails after the handoff
· Managers running teams on AI: these five rules also work as acceptance language for human teams

What you can take away

· Five guardrails you can copy straight into your own rule base
· Each comes with a usable phrasing or example you can paste and use right away
· A judgment habit: when you meet a hot new AI framework, how to absorb the concept without moving your whole house into it

Where these five guardrails came fromIn July 2026 I reviewed an open-source Agent framework that had gone viral overseas. After a two-model review, the conclusion was: don't install the original project, because its execution mechanism leans toward code development and would change my global settings; but its core concepts are excellent, so I extracted the parts that work across tools and turned them into these five guardrails. Just take the sharpest concept from a new tool. Moving your whole house in is a game you can never finish.

List of five guardrails

Guardrail 1Undefended assumptions

A major conclusion that hasn't been challenged from a second angle can only be marked as an assumption, not written as fact.

Guardrail 2Three-angle challenge

Logic, failure, and over-engineering: three angles take turns attacking your own conclusion.

Guardrail 3Add two fields to the handoff

Non-goals spell out what not to do; allowed paths mark out where it may touch.

Guardrail 4Change-course braking

If the same method fails twice, change course. No third blind attempt.

Guardrail 5Grading acceptance evidence

"Looks fine" is not evidence. Before wrapping up, ask: what grade is this evidence?

When to use itOnly for the big stuff

Small things like checking a time or reformatting: just do them. Save the guardrails for major conclusions, handoffs, and high-risk operations.

Guardrail 1: Undefended assumptions — mark them before anything else

A major conclusion from an AI (the root cause of a bug, an architecture proposal, a business recommendation, a safety judgment) must be labeled "undefended assumption" until it has been challenged from a second angle. It may be entirely correct, but "not yet challenged" is itself important information. Write it down as a confirmed fact, and every step that follows builds a house on a faulty foundation.

Phrasings you can use: "Undefended assumption: right now the root cause looks like…" "Single-model first take: not yet reviewed by a second model." Phrasings to avoid: Writing "the root cause is definitely…" without verifying it. Writing a guess straight into your work log or rules file and leaving it there as fact.

This guardrail costs the least and delivers the most: it lets whoever takes over next (person or AI) see at a glance which statements they can stand on and which they need to verify first.

Guardrail 2: Three-angle challenge — attack your own conclusion in turn

The challenge looks at the same conclusion from three angles in turn, each with its own checklist:

  • Logic angle (skeptic): Does this conclusion rest on a single piece of evidence? Has correlation been mistaken for causation? Has contrary evidence been ignored? Do the acceptance conditions actually prove the conclusion?
  • Failure angle (red team): What's the worst case? Could it touch anything irreversible — permissions, keys, data loss, public release, money? If it fails, how do you roll back? Are there shortcuts that look workable but magnify the risk?
  • Over-engineering angle (simplifier): Is there a smaller first step? Have you turned a one-off task into a permanent system? Could it be done first with existing tools and manual checking?

One important honesty marker: having the same AI play all three angles and attack itself is "self-challenge only" — better than nothing, but the challenge that really counts is handing it to a model from a different family. Sub-agents of the same model reviewing each other still share the same blind spots.

Guardrail 3: Add two fields to the handoff to stop scope creep

When you hand work to a second AI, a sub-agent, or the next round of an automated task, the handoff instructions usually say what to do but not what not to do. An executor "helpfully doing a bit extra" sounds diligent, but in an automatic loop it's the main source of accidents. So every handoff gets two fixed fields:

Non-goals (what NOT to do this round, at least one): Don't install external tools, don't change global settings, don't rewrite the existing architecture. Allowed paths (whitelist; anything not listed is off-limits for writing): Readable: the entire project folder Writable: the three specified files under articles/ Executable: read-only inspection commands

I use these two fields in every assignment I hand out. From my own experience the effect is direct: the executor's creativity gets channeled into "doing the specified job well," it stops and asks when something falls outside scope, and things going off the rails drops noticeably.

Guardrail 4: Change-course braking — switch after two failures

AI has a very human bad habit: the same method fails, so it tries again, fails again, tries again. In an automatic loop no one interrupts it, and it can flail blindly all night. So put a number on the brake:

  • Same method fails twice: change course, upgrade the tool, or stop and report back. No third blind attempt down the same road.
  • A sub-agent hands back a substantive error once: the controller takes the judgment back and doesn't let the same sub-agent blindly run a second round.
  • "Should work," "looks fine," or "maybe" shows up but no evidence is offered: treat it as unverified — it doesn't count as done.

Pinning the number down matters. Writing "change methods if you get stuck" is as good as writing nothing, because AI (and people) always decide they're "stuck" later than they actually are.

Guardrail 5: Grade the acceptance evidence — ask one question before wrapping up

The last step of a loop is acceptance, and the most common (unintentional) fakery in acceptance is "I checked it." So the acceptance report has to state which grade of evidence it rests on, from strongest to weakest:

  • Grade 1, machine acceptance: tests pass, script output, file exists, a count, deployment status.
  • Grade 2, data re-check: reading through the file section by section, cross-checking against the source, comparing counts.
  • Grade 3, cross-family review: the verdict of an independent review by a model from a different family.
  • Grade 4, manual eyeballing or inference: only usable as weak evidence, and can't on its own support a high-risk "done."
The banned-evidence list"Looks fine," "should be OK," "I already checked it" — with no account of how it was checked — none of these count as evidence. One more thing that's easy to miss: a sub-agent's report is itself only a clue, and the controller has to verify it independently. An AI saying it's done and it actually being done are two different things. When you have no evidence, an honest "modified, not verified" is worth far more than a pretty "done."

How to start: put guardrails on your next important task

You don't need all five at once. Pick your next important task (one you'll hand off, one that touches live data, one whose conclusion will be reused for a long time) and install them in this order:

  1. Before you start: add the Non-goals and Allowed-paths fields to the handoff instructions.
  2. Along the way: agree with the AI on change-course braking — if the same method fails twice, it has to stop and report back.
  3. When a conclusion appears: require it to be marked "undefended assumption," then run it through the three angles once, and go cross-family if you can.
  4. Before wrapping up: ask "what grade is your evidence?" If it's Grade 4, add one more grade.

Once it runs smoothly, write these five into your rule base or skill package so every loop carries its guardrails automatically. For how to recover when a loop goes wrong, there's a companion piece, Loop Safety and Recovery, you can read next.

Loop GuardrailsLoop EngineeringHarness EngineeringCross-family reviewAI AcceptanceAgent SafetyAI Workflow