Appearance
The agent runs — a hook mechanically verifies its output — and re-runs the agent until verification passes, so the loop, not the agent, carries the reliability.
Pattern
Closed Loop Execution
The shape
Execute — verify — correct. Until exit 0.
Execution
Agent Write file A
Write symbol X
Delete file B
→ task_update.py
--status completed
→
Verification
Stop hook filesExpected:
• file A exists? ✓
• grep X in A? ✓
• file B absent? ✗
exit 1 op: delete
path: src/B.py
file still on disk
→
Correction
Tier 1 — fix Agent reads error,
rm src/B.py,
retries
exit 0 All checks pass.
Validator spawns.
↻ on fail: agent re-enters loop with structured error — the agent does not advance; the loop does
The Stop hook is the judge. Self-reported completion does not exit the loop — only a passing mechanical check does.
Why the loop beats one-shot
Catch errors at the boundary, not three phases downstream.
One-shot execution10× cost later
t+0 Agent runs, writes output
t+0 Output is 80% correct — passes eyeball check
t+1 Pipeline advances to next phase
t+2 Next agent builds on top of it
t+3 Next-next agent builds on that
t+4 Test suite fails — cause is 3 phases up
The error was cheapest to fix at t+0. Now the fix requires unwinding t+1, t+2, t+3 — rewriting work that was built on broken foundations. correction cost ≈ 10× original
Closed loop execution1× cost, at source
t+0 Agent runs, writes output
t+0 Stop hook detects: file B still exists
t+0' Agent reads error, removes file B
t+0'' Stop hook re-checks → exit 0
t+1 Validator audits; pipeline advances
t+2 Next agent builds on correct foundation
The error never crossed a boundary. Downstream agents see only correct inputs. Probabilistic first attempts are fine — the loop exits only when the output is verified. correction cost ≈ 1× — absorbed inside the loop
An agent is probabilistic. The loop runs it until the output is deterministically correct — regardless of how many iterations it took.
The correction ladder
Three tries. Then escalate. No infinite loops.
After each failed Stop-hook check, the agent climbs the ladder — it cannot retry forever.
1Direct fix
Do exactly what the error says.
"file X still exists" → rm X → retry task_update.py
2Investigate
Direct fix failed — diagnose and try a corrected approach.
grep, read neighbors, re-read spec. One honest retry.
3Block
Two failures in a row — escalate to the orchestrator.
task_update.py --status blocked --reason "<specific diagnosis>"
A Tier 3 block is a signal — not a failure. It means the task description was insufficient, the spec was ambiguous, or a real architectural problem was hit. The blocking reason is the diagnosis.
The loop repeats at every scale
Task, plan, pipeline — same shape, different exit gate.
Task
Stop hook exits 0 — all filesExpected satisfiedinnermost loop
Builder retries via Tier 1 / 2 / 3 ladder
Plan
Validator reports STATUS: PASS mid-level loop
Orchestrator creates a correction task, adds to plan
Pipeline
All phases pass — tests green — PR review approvesoutermost loop
Phase-level remediation before the next phase starts
Fractal by design. The same execute → verify → correct skeleton holds whether the unit of work is one write, one task, or one release.
Don't confuse with
The principle claims. This pattern wires.
Layer
Principle — falsifiable claim
Pattern — structural implementation
Says
Open-loop execution is unreliable at agent scale.
Here is how the loop is wired at the task boundary.
Artifacts
None — it's a claim.
Stop Hook, Agent, Task, validator
Answers
Why build the loop.
How to build it.
The principle tells you the loop is non-optional. This pattern is the concrete shape the loop takes — filesExpected checks, Stop hook, Tier ladder, validator.
The discipline
The loop is the reliability mechanism — not the agent.
A probabilistic agent inside a deterministic verifier produces deterministic output. Trusting one-shot execution shifts the cost of every wrong guess three phases downstream — where a different agent pays it, at 10×, on foundations it can't see are broken.