Loop Engineering: Stop Conditions, /goal, Maturity Scale

Key takeaways

1. One-sentence definition. loop engineering builds systems that prompt agents on a schedule and toward a goal, instead of typing individual prompts. The leverage shifts from the quality of a prompt to the design of the system.
2. Two loop levels. the inner loop (perceive-reason-act-observe on every turn, already native to agents) vs. the outer loop one designs (planning, helpers, self-feeding work, persistence across many turns).
3. Three-layer lineage. (each encompasses the previous one): Prompt Engineering (1 instruction) → Context Engineering (window content) → Loop Engineering (system deciding what to prompt, when, and whether the result is acceptable). The prompt and the context remain essential — a bad prompt just produces bad work faster.
4. Origin of the term. popularized by Addy Osmani (Google) in June 2026, building on observations by Peter Steinberger ("you should be designing loops that prompt your agents") and Boris Cherny (Claude Code lead at Anthropic: his focus shifted to writing loops rather than prompting directly).
5. Ralph technique. (Geoffrey Huntley, early 2026, named after Ralph Wiggum): running the agent in a simple while loop, the same prompt on every iteration, against a written spec, with fresh context on every turn. The non-obvious innovation is the context reset (avoids degradation from long sessions). The intelligence comes from clear specs + verifiable results + external memory (PLAN.md, STATUS.md), not heroic runs.
6. Loop engineering productizes Ralph. the while becomes a scheduled automation, the resets become worktrees/sub-agents, the "ALL TASKS DONE" check becomes a /goal condition verified by a separate model.
7. 5 building blocks + memory. (1) Automations (scheduled discovery/triage triggers); (2) Worktrees (parallel agents without collisions); (3) Skills (documented project knowledge); (4) Plugins/connectors (MCP, access to real tools); (5) Sub-agents (separating generation from verification); (6) Memory (markdown, Linear/GitHub boards — outside the context window). "Agents forget. Repositories remember."
8. Claude Code and Codex embed the 5 building blocks + memory. under different names but identical structures → design loops that survive a tool change.
9. Automations. Codex (Automations tab, runs into a Triage inbox, empty runs self-archive); Claude Code (/loop + hooks + GitHub Actions integration). Key in-session primitive = /goal: sustains work until the specified condition is verifiably true, a separate, smaller model grades completion on every turn (the agent does not self-assess).
10. State as of mid-2026. /goal shipped in Claude Code v2.1.139 (May 11, 2026), the 2.1.x branch with Opus 4.8 as default plus dynamic workflows orchestrating large sub-agent fleets; Codex added /goal in CLI 0.128.0. Practitioners report agents working unsupervised for dozens of hours → stop conditions become the most critical element.
11. Write stop conditions as contracts. end state + proof + constraints + turn/budget cap. E.g. "src/billing coverage ≥ 90%; npm test exits 0; no public API changed; stop after 25 turns or $5."
12. Three practices for reliable loops. (Claude Code teams): preserving errors (so the loop learns instead of repeating), building in verification from the start, treating red tests / red CI as honesty signals. A loop with no proof of failure always believes it succeeded.
13. Worktrees. = real git isolation (separate directories on distinct branches, shared history). But "You remain the ceiling": human review capacity, not the number of worktrees, determines how many agents one actually runs in parallel.
14. Maker-checker sub-agents. = the most powerful structural change: an adversarial verifier agent (strong model, high reasoning, instructed to reject anything unproven) gating work before human review. Models that grade their own work are too generous.
15. Maturity scale (Levels 0→4). 0 Manual → 1 Triage (findings in markdown, no code) → 2 Draft (fixes on isolated branches) → 3 Verified PR (verifier sub-agent as gate) → 4 Auto-merge (low-risk categories on green CI). Move up a level only if the current one produces work one would have done oneself.
16. 3 risks that worsen (not lessen). verification remains your responsibility ("done" is a claim, not proof); understanding debt accelerates (code ships faster than it is understood); cognitive surrender (accepting outputs without judgment) — two people building the same loop get opposite outcomes depending on whether they use it to advance work they understand or to avoid understanding it.
17. Watch the tokens. scheduled loops + post-turn verifier models burn tokens fast. Start with slow cadences and tight conditions, monitor costs for several days, scale only after proof of useful merged work.
18. Security. autonomous loops with connectors touch production → guardrails, permissions, audit logging required.