Disclosure up front: I build agentproto, which runs
checks inside an agent's loop rather than only at the end. Everything about
why that matters you can verify without me — the sources are named and dated,
and I'll concede where the plain loop is exactly right. Corrections welcome,
file an issue.
You gave your agent a loop, closed the laptop, and went to bed.
The whole pitch of the overnight loop is that it keeps going. while true; do — it wakes back up every time it stalls,
cat prompt.md | claude -p; done
re-reads the plan, and grinds on until a checklist is green. You come back to a
finished feature and a clean exit code. Sometimes that's a miracle. Sometimes
it's a very tidy way to have built the wrong thing four hundred times.
The one idea, if you remember nothing else:
A loop gives your agent persistence, not correctness. And a wrong turn, held
with conviction and looped, is just a faster way to be wrong.
Persistence is not correctness
A loop is a liveness guarantee. It promises the process will keep running; it
promises nothing about whether the process is pointed the right way. Those are
two different properties, and the whole overnight-autonomy genre quietly conflates
them. "It's still going" feels like "it's still on track" at 2am. It isn't.
Geoffrey Huntley named the mechanism precisely when he described the Ralph
technique as a deterministic loop wrapped around a non-deterministic model —
the bet being that repeated attempts converge on a working solution. That bet is
real, and often it pays. But convergence has a direction, and the loop doesn't
supply it. The loop supplies fuel.
Why the direction can be wrong. Each Ralph iteration starts with a fresh
context window but inherits all prior work from the filesystem — code, commits,
notes — which it treats as ground truth and builds on (Sid Bharath, "the
dumbest smart way to run coding agents," 2026). That's the strength on a good
run. On a bad one, iteration two builds on iteration one's mistake, iteration
three trusts both, and the error stops looking like a bug and starts looking
like the codebase.
So an unsupervised loop doesn't self-correct. It self-reinforces. It pays
compound interest on your first wrong turn — confidently, on a timer, with every
pass making the mistake more load-bearing and more expensive to unwind. The
scariest output of a runaway loop isn't a crash. It's a green checkmark on top of
a bad foundation.
The check at the finish line is the check that arrives too late
"Fine," you say, "I gated it — the loop only exits when the tests pass and it
prints COMPLETE." Good instinct, wrong position. A terminal gate fires after
the loop has already burned the budget and stacked the tower. By the time your
end-of-run check has an opinion, the wrong thing is built, tall, and load-bearing.
And the completion signal you're trusting is more fragile than it looks.
The exit condition is a suggestion, not a safety mechanism. A completion
promise is typically a static exact-match string with no OR conditions — so it
can silently never fire if the wording drifts. The thing that actually bounds a
runaway loop is the iteration cap; long loops can plausibly cost $30–150 in
API spend, so you never run one without one (The AI Agent Factory, 2026).
Read that again: the mechanism keeping your loop from running forever is a
counter, not a judgment. It stops the spend. It doesn't check the work.
The deeper problem is that the failures that matter most are invisible to any
single moment — including the last one. Apollo Research, whose Watcher tool
monitors coding agents, splits agent failures into two shapes, and the split is
the whole game.
Two failure shapes, two different checks. Some failures live in a single
action — deleting files, leaking a secret, a force-push — and must be blocked
synchronously, before execution. Others only emerge over many turns — scope
creep, a confidently wrong diagnosis, premature "done" claims — and no single
action reveals them; they have to be judged over the trajectory
(Apollo Research,
2026). A terminal gate sees exactly one moment. The drift that sinks you lives
in the shape it can't see.
Self-diagnosis: when does your loop check its work?
Here's the one question that sorts every autonomous setup. When does your loop
check its work — only at the very end, or partway through? If the only
checkpoint is the completion gate, you are blind to the exact class of failure
that compounds: the one that builds up quietly across turns and looks fine right
up until it's enormous.
Run the honest audit on your own harness. Between kickoff and the final green
check, how many times does something other than the agent look at where it's
going? For most overnight loops the answer is zero — the agent grades its own
progress every iteration, and a generator grading itself is the plateau the whole
supervision ladder is built to escape.
Receipt from the trajectory list. Apollo's rubric of multi-turn failure
modes reads like a confession of every bad overnight run: premature completion
claims without verification, ignoring user corrections, confidently wrong
diagnoses, scope overreach, fabricated APIs, and — my favorite — repeating a
failing command 3+ times without changing strategy. A loop is a machine for
doing that last one at scale.
If your check lives only at the finish line, the loop's superpower — never giving
up — becomes its failure mode. It will never give up on the wrong path, either.
The wrong fix: a watchdog that restarts you into the same groove
The reflex, when a loop misbehaves, is to make it more persistent: auto-restart
on stall, replay the last message in a fresh session, keep it alive through
context overflow and API errors. That's a watchdog, and it's genuinely necessary
plumbing for unattended runs — but it is the exact wrong tool for this problem.
A watchdog keeps the process breathing and says nothing about whether the process
is right. It will cheerfully restart a wrong loop into producing the same wrong
answer until sunrise — the supervision ladder
calls this L1, and the reason it's the lowest automated rung is that "alive" and
"correct" are different axes. Restarting a confidently-wrong agent doesn't
interrupt the self-reinforcement. It refuels it.
Alive ≠ on-track. Health-monitoring harnesses track context usage, idle
time, and error counts, then act: clear context below a threshold, restart
agents that stall, disable them after N consecutive errors (Claude Code Agent
Farm, 2026). Every one of those signals is about liveness. None of them asks
the only question that matters mid-flight: is this still the right thing to be
building?
So the fix can't be "keep it going better." It has to be something that can make
it stop going the wrong way — partway through, before the tower is tall.
The fix: an external skeptic that runs during the loop
The check has to move two places at once: outside the agent (a different
context, ideally a different model — a generator can't be its own skeptic) and
inside the timeline (running alongside the loop, not waiting at the exit).
That's the ladder's L3/L4 external-judge idea, but
applied continuously instead of only at turn-end.
This is precisely what a trailing monitor does, and Apollo measured the payoff
and its limit in the same breath.
Catch the drift early or don't bother. When a trailing monitor scores a
session over threshold on scope-overreach or premature-completion, injecting a
shortsystem-reminder-style nudge — "you were asked to fix the login bug but
are now refactoring the session module" — generally steers the agent back.
But effectiveness drops the further the agent has already committed to the
wrong path, so the monitor must run frequently enough to catch drift early
(Apollo Research,
2026). That sentence is the entire argument for killing the terminal-only gate:
the redirect that works cheaply at turn three is nearly useless at turn thirty.
The redirect gets weaker exactly as fast as the loop's confidence gets stronger.
Compound interest, running the other way. A check that only fires at the end
isn't a safety net; it's an autopsy.
And because the monitor is a separate context, it can be a separate provider —
which is a feature, not an accident.
Don't let the agent pick its own referee. Models share blind spots with
themselves: a monitor from the same family tends to trust the agent's reasoning
patterns — Apollo observed Claude models being too trusting of their own
reasoning, GPT models over-suspicious as graders. Mixing providers across the
monitoring pipeline yields oversight that doesn't inherit the supervised
agent's biases. The skeptic works best when it isn't the defendant's cousin.
Building it: interrupt the loop, don't just watch it end
Concretely, the difference is one structural move. Here's the naive loop
everyone starts with — one check, at the very end:
# The terminal-gate loop: blind between iterations
while true; do
cat prompt.md | claude -p --dangerously-skip-permissions
grep -q "COMPLETE" progress.md && break # the ONLY check, and it's last
[ $((i++)) -ge 50 ] && break # the counter, not a judgment
done
Everything between kickoff and COMPLETE is unsupervised. Now put a skeptic
inside the timeline — an external monitor that reads the trajectory at every
turn boundary and can halt-and-redirect partway through, even mid-way through a
sub-agent's run:
// A mid-flight monitor: runs alongside, can interrupt — not a watchdog
{
"sessionId": "sess_…",
"cadence": "every-turn", // not "on-exit"
"monitor": { "judge": {
"adapter": "gemini", // a DIFFERENT provider than the executor
"prompt": "Score scope-overreach, wrong-diagnosis, premature-completion 0–1. Quote the turn."
}},
"onDrift": { // trajectory failure → steer, early
"above": 0.6,
"action": "nudge",
"text": "You were asked to fix the retry test, not rewrite the queue. Return to the task."
},
"onIrreversible": { "action": "block" } // single dangerous action → stop, synchronously
}
That's the reversibility split in config: single dangerous actions get blocked
before they run; multi-turn drift gets caught early, while the redirect still
works. The monitor lives in a daemon, so it keeps checking after your screen
locks — and because it's an external adapter, it runs on any executor: Claude
Code, Codex, or a cheap GLM/DeepSeek model via Hermes. The loop keeps its
persistence; you just stop letting it persist unsupervised.
This matters most where the money is. A mixed fleet — frontier model plans, cheap
model executes in a loop, the routing math its own post —
is where self-reinforcement is cheapest to trigger and most expensive to catch
late. The $0.10 executor will loop confidently into a wall; something external has
to notice before iteration thirty.
Kill the loop, not the iteration
To be fair to the loop, because fairness is the point: for a low-stakes,
disposable, sandboxed project, the plain overnight loop is the right tool.
Someone shipped a full prompt-history feature to a React Native app from an
11-task list for about $1, exiting early at iteration 8 on the completion
sentinel — it compiled and worked (demo talk, 2026).
Well-scoped, throwaway, checked by real tests: loop away. The trouble starts the
moment it's code you're accountable for — "the loop wrote it" has never once
been a defense.
So "kill the loop" doesn't mean kill iteration — iteration is how these agents
converge at all. It means kill the unsupervised loop: the one whose only check
sits at the finish line, refueled by a watchdog, grading its own homework every
pass. Keep the while true. Just put a skeptic inside it, running alongside,
allowed to interrupt.
Because a loop, on its own, is confidence with an exit code. Persistence isn't the
same as being right, and this whole series turns on one question first asked in
the hub piece: when your agent says
"done," what — other than the agent — decided that was true? A loop answers
"nothing, but enthusiastically." The only real answer is to have something that
isn't the agent look at where it's going before it gets there.
If your loop already checks itself mid-flight, or I've mis-drawn where the
terminal gate fails you, tell me where — I'll fix the piece.
The series — Orchestration, Honestly
Ten pieces, one argument. Start anywhere; each one cross-links the rest.
| Piece | The one idea | |
|---|---|---|
| 1 | You can't parallelize the trust | Amdahl's Law: why your fifth agent slows you down |
| 2 | Harness engineering | you rent the model; the harness is the part you own |
| 3 | The supervision ladder | five rungs of trusting an agent you don't watch |
| 4 | The approval plane | auto-approve reads, gate writes — wire the line between |
| 5 | Kill the loop (you're here) | why "keep going until done" compounds a wrong turn |
| 6 | Route by cost | plan expensive, execute cheap, verify independently |
| 7 | Files with contracts | the interop layer every agent system reinvents |
| 8 | Knowledge is power | give your agent your knowledge, not the internet's average |
| 9 | Paseo, hands-on | a full real-session review of the daemon |
| 10 | 9 orchestrators, compared | the tool-by-tool teardown + a decision table |
Written by the maintainer of agentproto (Apache-2.0, source). Same contract as our /compare page — dated facts, named strengths, corrections by issue. Got something wrong? File an issue.
Building agentproto in the open — follow @theagentproto and @agentik_ai on X.
Top comments (0)