What Is Loop Engineering?
Loop Engineering is the practice of designing a controlled outer cycle around model-driven work. The cycle gives an AI agent a clear goal, bounded context, independent evidence, a budget, durable memory, and explicit decisions to stop, retry, or escalate, so repeated work remains verifiable, reviewable, and under human control.
Reviewed against the linked source, the site's safety rules, and the current behavior of its browser-only generators. Sources are evidence, not endorsements.
Does a loop specification add control that an ordinary prompt does not make visible?
What we tested
We generated a CI-repair goal with the site's real Codex output function and inspected the artifact for a trigger, measurable outcome, validation evidence, forbidden shortcuts, bounded retries, fallback, persistence, and a human approval point.
Observed result
The artifact made each outer-loop decision inspectable while leaving the inner implementation path open. The added value was not a longer prompt: it was the explicit evidence and terminal states that decide whether work may continue, stop, or return to a person.
What this does not prove
This demonstrates the structure produced by this site, not a universal definition or proof that every runtime enforces the fields. Addy Osmani's current writing uses investigation, implementation, verification, and repeat; other teams may name the stages differently.
Why it matters
A strong prompt can get one useful answer. A strong loop can keep returning to the same kind of work without losing safety, budget, or human judgment. That difference matters once an agent is expected to watch CI, follow review comments, refresh content, clean data, or handle any repeated task.
Origin and source context
Addy Osmani's article provides a useful recent articulation of Loop Engineering for AI agents and helped popularize the term. The broader pattern—feedback, verification, bounded retries, and human control—draws on established engineering practice, so this guide does not claim one person invented every part of it.
Read Addy Osmani's Loop Engineering articleThe control sequence
- 01Goal
- 02Attempt
- 03Evidence
- 04Decision
- 05Stop, retry, or escalate
The sequence is deliberately explicit. Evidence is evaluated before another attempt begins, and every exit path is decided in advance rather than left to the agent's confidence.
Deterministic outside, model-driven inside
Outer control loop
The outer loop should be as deterministic as the task allows: fixed inputs, validation commands, iteration and budget limits, approval points, and named exit paths.
Inner agent work
The inner work is model-driven: the agent interprets context, proposes a change, and explains its reasoning. That flexibility is useful, but it does not get to redefine success or authorize irreversible actions.
The four layers
| Layer | What it handles | What breaks when it is missing |
|---|---|---|
| Prompt Engineering | One instruction for one response | The agent has no durable structure |
| Context Engineering | The information inside the current run | The agent works from weak or stale inputs |
| Harness Engineering | Tools, permissions, checks, and guardrails for one run | A single run can act unsafely |
| Loop Engineering | Discovery, handoff, verification, persistence, and scheduling | Repeated work drifts, overspends, or never stops |
Compare adjacent concepts
Context shapes one run; the loop controls what happens across runs.
A harness constrains execution; a loop decides when and why execution repeats.
Use iteration for uncertain work without abandoning gates needed for high-risk changes.
The more objective the evidence, the more safely a loop can close itself.
The five operating questions
- 01What does the loop read first?Discovery
- 02Who or what receives the work?Handoff
- 03Who checks the result?Verification
- 04What gets saved for next time?Persistence
- 05When does it run again or stop?Scheduling
Practical checklist
- Name the discovery source: CI, issues, commits, inbox, queue, or saved report
- Define the handoff: which agent works, where it works, and who owns the final decision
- Use a validation step plus an independent checker
- Persist the run note so the next pass has memory
- Set the schedule, stop rule, budget cap, and human approval point
A safe example with explicit exits
A CI repair loop reads one failing run, gives a coding agent the smallest reproducible failure, lets it make a scoped change in an isolated worktree, and asks a separate checker to inspect the commands, evidence, and diff.
Stop rule
Stop when lint, tests, and build pass and the checker finds no unrelated change. Also stop after three failed attempts, any repeated identical failure, or the pre-set budget limit—whichever happens first.
Fallback
Keep the failure logs and run note, discard or revert the unapproved worktree change, and report the smallest unresolved blocker plus the next safe diagnostic step.
Human approval
A person must review the evidence and approve before merge, deploy, deletion, purchase, or any external communication.
Common failure modes
Related templates
FAQ
No. Automation can trigger a task. Loop Engineering also defines the handoff, checker, memory, stop rule, budget, and approval point around that task.