The Agent Loop, Verified
"Let AI agents run while you sleep," promises a widely-shared Loop Engineering 101 poster. Its core distinction — open loops that wander versus closed loops that terminate — is the single most useful idea in amateur agent operation, and it's correct. Around that core: sound building blocks, one genuinely good pattern, and the usual unsourced numbers. The ledger sorts them.
01 — The core distinctionOpen loops wander; closed loops finish
The poster's centerpiece survives contact with practice. An open loop — "keep improving until it's good" — has no termination condition, drifts from its objective, and burns budget in proportion to your patience. A closed loop has a defined goal, validation checkpoints, budget limits, and predictable outcomes. Every serious harness pushes you the same way: goal-conditioned running (state a testable finish line), scheduled runs with fixed scope, and verification before exit. This is the same lesson as I-09's "state the finish line, not the steps" — arrived at from the failure side.
The maturity ladder (prompter → operator → loop designer → system architect) is a reasonable self-diagnostic, folklore though the level boundaries are: the real threshold is the step from running agents to designing the loops agents run in.
02 — The building blocks, checkedSix named parts, five real
- Automations on a schedule — real (scheduled tasks/recurring runs). Skills — real ("project knowledge written once, read every loop" is a fair one-line definition). Subagents — real, and the poster's rule is the documented wisdom: maker and checker are never the same agent. Plugins and connectors — real (MCP and friends). Memory — real; "lives outside the conversation, never forgets" oversells persistence but names the right mechanism.
- "Work trees — parallel agents, zero file collisions" — the one technical surprise: this is a real mechanism (isolated working copies per agent, as in git worktrees), accurately described. Niche, but not folklore.
The self-learning loop — run, catch mistake at the quality gate, write the lesson to a rules file on disk, future runs read it — is the poster's best content. It's the compounding trick: failures become reusable rules. The file name varies by system (the poster says RULES.md); the practice is portable and worth stealing.
03 — The ledgerNine claims, checked 2026-08-06
| Claim | Verdict | The record |
|---|---|---|
| Open vs closed loops as the core distinction | VERIFIED | Matches goal-conditioned running and budget-capped scheduling in real harnesses. |
| Goal → plan → execute → verify → iterate cycle | VERIFIED | The documented agent loop, correctly drawn. |
| Quality gate before shipping (tests, linters, checks) | VERIFIED | Sound: no gate, no unattended loop. |
| Maker and checker never the same agent | VERIFIED | Standard verification practice; same rule this library operates by. |
| Work trees for collision-free parallel agents | VERIFIED | Real mechanism, accurately described. |
| Self-learning loop via a rules file on disk | VERIFIED | Portable practice; file naming is per-system convention. |
| Single agent vs fleet framing (simplicity vs scale) | NUANCE | Fair heuristic; the real trigger for a fleet is verification needs, not size alone. |
| "Open-loop agents can burn 2M tokens in a single run" | NO SOURCE | Direction true, number invented. Unbounded loops burn what you let them. |
| "Let AI agents run while you sleep" | NUANCE | True exactly when the loop is closed, gated, and budgeted — the poster's own conditions, which the headline forgets. |