Loop Engineering
Loop engineering is the practice of designing the control system that prompts, verifies, retries, and stops an AI agent - instead of you prompting the agent yourself, turn by turn. The term was coined in June 2026 by Peter Steinberger and popularised in an essay by Addy Osmani, building on practice already running inside Anthropic's Claude Code team under Boris Cherny. It is the operational sibling of harness engineering: the harness is the system you build; the loop is the cycle that runs through it.
A Task Plus a Check
"A loop is a task plus a check. A task without a check is just hope." The intelligence lives in the model - the reliability lives in the loop.
This is a deliberate shift in who is doing the driving. In manual prompting, you read the model's output, decide if it's good enough, and type the next instruction. In loop engineering, you build that decision into code: something triggers the agent, the agent acts, a verifier checks the result, and the loop repeats until a goal is met or a stop rule fires. You stop being the person who types the next instruction, and become the person who designs the system that decides it.
Anatomy of a Loop
A failed verification feeds back into another Agent Acts step with the failure as new context, not a fresh unrelated attempt
Loop Engineering vs Harness Engineering
Harness engineering
The static structure: which tools exist, what the guardrails are, what gets logged. Answers "what is this agent allowed to do, and what catches it when it's wrong?"
Loop engineering
The dynamic cycle: how many times to retry, what changes between attempts, and when to give up. Answers "how does this agent keep working toward the goal on its own?"
In practice they are built together: a harness with no loop just runs once and stops; a loop with no harness retries blindly with nothing to actually check against.
Where This Already Shows Up
- Coding agents that run tests until they pass - the loop is write code, run tests, read failures, fix, repeat.
- Claude Code's own agentic loop - read, plan, act, verify - the pattern this section's term-coiners built the idea from. See What is Claude Code.
- CI/CD-style agent pipelines - an agent proposes a change, automated checks gate it, a failed check triggers another attempt rather than a human ticket.
- Evaluation-driven development - see Regression Testing for the verification side of the loop.
Risks of a Bad Loop
Failure modes to design against
- No stop condition - the loop retries forever, burning tokens and money on a task it will never solve this way.
- A verifier weaker than the task - the check passes things that are actually wrong, so the loop confidently reports success on a bad result.
- Identical retries - retrying without feeding the failure back as context just repeats the same mistake with different random variation.
- No human escape hatch - a loop with no way to pause and hand control back for a genuinely ambiguous case will either stall or guess.
Checklist: Do You Understand This?
- Can you state the definition of a loop in one sentence - a task plus a check?
- Can you explain the difference between loop engineering and harness engineering, and why they're built together?
- Do you know the three failure modes that make a loop unsafe: no stop condition, a weak verifier, and no escape hatch?
- Can you name a tool or workflow you already use that is, underneath, a loop?