Loop Engineering: Patterns for Reliable AI Coding Agents

"Loop engineering" is a nascent, community-coined idea — not an industry standard — that describes a shift in how people run AI coding agents: instead of prompting the agent turn-by-turn, you design the loop it runs. The loop discovers work, hands tasks to agents or sub-agents, verifies the result, persists state, and decides the next action — on a schedule or until a goal is met. The discipline every project in this space converges on is the same: a sharp goal, a real verification check, a review gate before anything ships, and explicit stopping and hand-off criteria so the agent cannot run forever. This guide explains the idea, attributes who is defining it, and lays out the concrete patterns — with an original loop-pattern table and a diagram of a review-gated loop.

What loop engineering is

It is designing the loop an AI coding agent runs — plan, act, verify, decide the next step — instead of prompting it turn-by-turn. And it is an emerging idea, not an established standard. The term was named and popularized around June 2026 by Cobus Greyling in the cobusgreyling/loop-engineering repo, which defines it as the shift from being the person who prompts a coding agent turn-by-turn to designing a system — a "loop" — that discovers work, hands tasks to agents or sub-agents, verifies results, persists state, and decides the next action on a schedule or until a goal is met. The repo's tagline captures the pitch in six words: "Stop prompting. Design the loop. Get a score."

Read that as a change of role. In turn-by-turn prompting you are the runtime scheduler: you read each output and decide the next instruction. In a loop, that decision logic moves into the system. As the separate Forward-Future/loopy project frames it: "Most prompts ask an agent to do something once. A loop gives the agent a way to learn from the result and take the next useful step."

Who is defining it (and who is not)

One person named it; the idea is attributed to several others; three open-source projects give it substance. Greyling is careful not to claim invention — his framing credits the idea to others, and the loop-engineering README states it is "inspired by Addy Osmani and Boris Cherny." The attribution chain, per his writeup:

• Addy Osmani — "Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."
• Peter Steinberger (OpenClaw) — "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
• Boris Cherny (Anthropic, Claude Code) — "I don't prompt Claude anymore. I have loops running that prompt Claude… My job is to write loops."

Three primary projects currently define the space, and they are distinct — do not read them as one spec:

Attribution quotes above come from a secondary writeup (Greyling's Loop Engineering post) and carry medium confidence; the project facts come from the live repos.

Why it matters for reliability

A loop is only as reliable as its check and its stopping rule — everything else is a way to run an unverified agent faster. The reliability case is not "more autonomy." It is the opposite: constraint. The loopy project is blunt about it — "Loops are not permission for an agent to run forever. The best ones are deliberately bounded. They include a real check, a clear stopping point, and a moment to hand control back to a person when judgment or approval is needed."

That gives you the four things a naive "keep going until it works" script lacks. Per loopy, a bounded loop has:

• Goal clarity — an unambiguous definition of done, not a vibe.
• A verification method — a real, repeatable check (tests, a linter, a scored judge), run under recorded conditions.
• Action on feedback — the loop reads the check's result and changes what it does next.
• Stopping criteria — explicit terminal states so it halts, escalates, or hands off instead of grinding.

The moment you require a verification method, agent output stops being "whatever the model said" and starts being "a change that passed a check." That is the reliability lever. It pairs naturally with the practices we cover for the agents themselves — a good model choice for agentic work and disciplined reasoning like sequential thinking in Claude Code — but the loop is what makes those reliable at scale rather than per-turn.

The anatomy of a bounded loop

The loopy project distills a loop into six steps and a set of explicit exits. Its loop-library SKILL.md defines the anatomy as: Observe (read fresh state, collect agreed evidence) → Choose (the highest-value in-scope action by explicit criteria) → Act (one bounded, reversible change or one candidate) → Verify (run the same acceptance check under recorded conditions) → Record (save action, evidence, outcome, remaining work) → Repeat-or-stop.

Crucially, "stop" is not one state. Loopy names explicit terminal states — success, clean no-op, blocked, approval-required, exhausted, and stagnated — so the loop always ends in a defined condition rather than looping forever. A minimal shape, expressed as a state file the loop reads and writes each iteration (an approach used across these projects — Greyling's repo pairs a STATE.md with a LOOP.md and even ships drift detection between them):

# STATE.md — the durable spine the loop reads/writes each pass
goal:     ship green CI on main for the payments module
check:    "pytest -q tests/payments && ruff check ."
iteration: 3 / 8          # hard cap → escalate on exhaustion
last_outcome: 2 tests failing (test_refund_partial, test_idempotency)
terminal: null            # success | blocked | approval-required | exhausted | stagnated
budget:   "1.20 / 5.00 USD today"

The iteration cap and the budget line are not decoration — they are the difference between a loop and a runaway. We will see why in the failure-mode section.

Loop patterns: three shapes

Most real loops are one of three shapes — plan-act-verify, review-gated, or self-correct — layered together. These names are our synthesis across the three projects; the concrete registry entries and gate types are cited to their source repos. Use this to decide how much structure a given task needs:

Two of these have named registries you can lift patterns from. Greyling's repo publishes a pattern registry, each entry tagged with cadence and risk level — PR Babysitter (5–15m, Medium), Daily Triage (1d–2h, Low), Issue Triage (2h–1d, Low), CI Sweeper (5–15m, Medium), Post-Merge Cleanup (1d–6h, Low), Dependency Sweeper (6h–1d, Medium), and Changelog Drafter (1d, Low). Each documents the problem it solves, recommended scheduling, the skills and state shape it needs, its verification approach, a human hand-off strategy, and tool-specific notes.

Forward Future's browsable Loop Library catalogs ~70 named loops spanning engineering, operations, content, design, and evaluation — for example "The docs sweep," "The production error sweep," "The 100% test coverage loop," "The ticket-to-PR-ready loop," "The accessibility repair loop," and "The research-to-artifact loop." (Loop names read from the live catalog, July 2026.)

The review-gated loop, drawn

The review-gated pattern is the one worth drawing, because the gate is where reliability lives. As defined by the ksimback/looper project, a gate is classified as one of three kinds — programmatic (command-based, e.g. tests and linters), judge (model-scored), or human (manual approval) — and looper recommends adding a Review Council of a different model family for oversight. Its typical flow is Goal → Plan → Review Gate → Delivery → Judge Gate → Stop, and its one-line summary is "a sharp goal, checkable verification, and a second model in the review seat."

The reason for a different model family in the review seat is independence: a model is a weak checker of its own output. Running the reviewer on a separate provider is exactly the kind of cross-model wiring an LLM gateway makes routine — host model on one key, judge on another, one OpenAI-compatible endpoint for both.

Named failure modes to design against

The most useful thing the loop-engineering repo ships is a vocabulary for how loops break. A named failure mode is a design checklist item. Greyling's failure-modes doc catalogs these, with mitigations:

The repo also names Notification Fatigue, Over-Reach (wrong scope), and Comprehension Debt Spiral. To support the mitigations, its building blocks include Automations/Scheduling, Worktrees (parallel isolation), Skills (persistent knowledge), Plugins & Connectors (MCP integration), Sub-agents (maker/checker splits), and Memory/State as a durable external spine — and it claims the same loop "shape" works across Grok, Claude Code, Codex, OpenClaw, Opencode, and GitHub Actions. Token Burn in particular is worth pre-empting; the general levers are in our guide to cutting token costs for coding agents.

How to build your first loop

Start with a checkable goal and the smallest bounded loop that can prove it — then add a gate. A pragmatic order of operations, drawn from the three projects' tooling:

1. Pick a checkable goal. If you cannot write a command or a rubric that decides "done," you are not ready to loop yet — you are still prompting.
2. Scaffold from a pattern. Greyling's repo ships a loop-init CLI that scaffolds a loop for a chosen pattern and tool — e.g. npx @cobusgreyling/loop-init . --pattern daily-triage --tool grok. (Command per the loop-engineering repo, July 2026.)
3. Set the control safeguards. Per looper: iteration caps, no-progress detection, budget limits, and termination conditions. These are non-negotiable — they are what makes the loop bounded.
4. Add a review gate. Classify it as programmatic, judge, or human. For anything that ships, add a judge from a different model family as a Review Council.
5. Score your readiness. Greyling's repo ships a Loop Readiness Score CLI (loop-audit) plus loop-cost/loop-budget for token budgeting — a way to check the loop before you let it run unattended.
6. Keep it portable. Looper emits portable artifacts — loop.yaml (a portable spec), loop.resolved.json (a compiled schema), RUN_IN_SESSION.md, and run-loop.py (a Python runner) — so the loop is not welded to one session.

Note that looper positions itself as a design layer first: it coaches you to design a review-gated loop before execution, and it explicitly contrasts itself with Claude's built-in /goal (persistent objectives) and /loop (scheduling), which it says lack loop-design coaching, cross-model review gates, and portable specs. If you are running loops inside Claude Code, our guide on how to use Claude Code and the comparison of Claude Code vs Cline cover the host side; loop engineering is the layer you put on top.

FAQ