Loop Engineering: The Complete Guide

What Is Loop Engineering?

Loop engineering is the practice of designing the system that runs an AI coding agent on repeat — instead of typing each prompt yourself, you build the machine that finds the work, prompts the agent, checks the result, and decides whether to stop or go again.

Prompt engineering optimizes a single instruction, one turn at a time. Loop engineering optimizes the loop around that instruction: what state the agent reads before it starts, what command verifies its work, and what condition tells it to stop. The skill shifts from "what do I type" to "what system keeps typing for me."

Why This Term, Why Now

By mid-2026, coding agents got reliable enough at long-horizon work that the bottleneck moved. It's no longer how well you phrase a single request — it's whether you've built a harness that can hand an agent a well-scoped task, verify the result objectively, and retry without a human watching every step.

The term was popularized by Addy Osmani, building on ideas from Peter Steinberger and Anthropic's Boris Cherny (the creator of Claude Code). Claude Code itself ships four built-in loop primitives — see The 4 Types of Loops in Claude Code for how they map onto this framework.

The Related-Terms Glossary

These terms get used interchangeably online, but they describe different layers of the same stack:

• Prompt engineering — optimizing a single hand-typed instruction to a model, one turn at a time.
• Context engineering — deciding what information (files, memory, retrieved docs) an agent sees before it responds, across a session.
• Harness engineering — designing the full system an agent runs inside: its tools, guardrails, observability, and permissions. Agent = model + harness.
• Loop engineering — harness engineering applied specifically to the retry-and-verify cycle: the goal, the check command, the exit condition, and what happens between iterations. This page is about this layer.
• Ralph loop / Ralph Wiggum technique — a specific loop-engineering pattern that restarts the agent from a clean context every iteration, reading progress from a state file on disk. Full explainer →
• Reflexion — an agent pattern (originally from academic research) where the agent writes a short self-critique after a failed attempt and reads it back before retrying.

The Anatomy of a Loop

Every well-formed loop answers the same four questions, and it's worth writing them down explicitly before you hand anything to an agent:

• Goal — the one sentence that defines "done." Vague goals produce loops that either stop too early or never stop.
• Check command — the objective, machine-runnable command that tells you whether the current state passes. npm test, gh pr checks, a lint command — anything a human doesn't have to eyeball.
• Exit condition — what the check command's output has to say for the loop to stop. "All tests pass," "PR checks are green," "coverage ≥ 80%."
• Max iterations — a hard ceiling so a loop that never converges doesn't run forever on your CI bill.

Every workflow in MCP.so's Loops directory is structured around exactly these four fields, plus a kickoff prompt you can paste directly into an agent — because that's the actual shape of a working loop, not an abstraction layered on top of one.

Named Loop Patterns

A few named patterns show up again and again once you start looking for them:

• Ralph-style loops — restart the agent from a clean context every iteration, reading progress from a state file on disk instead of relying on conversation memory. Read the full breakdown in The Ralph Loop, Explained, or see it in action in Ralph Story Executor.
• Reflexion loops — the agent writes a short reflection after every failed attempt and reads it back before retrying, so it doesn't repeat the same wrong fix. See Reflexion Debug Loop.
• Guardrails loops — when the same failure happens twice, the loop writes a standing rule to a guardrails file so future iterations respect it automatically. See Guardrails Learning Loop.

None of these need custom orchestration software — they're just prompts plus a state file plus a shell loop, which is a big part of why the pattern spread so fast.

Getting Started

The fastest way to try loop engineering is to copy a working loop rather than design one from scratch. A few good first ones:

• Ship PR Until Green — implement, push, open a PR, and keep fixing CI until it's mergeable.
• Test Until Green — run the suite, fix the smallest root cause, repeat until everything passes.
• Fix CI Until Green — pull the latest failed CI run, reproduce it locally, fix it, verify.

Browse the full, growing set at MCP.so Loops, filterable by category and sorted by popularity — each one ships with a ready-to-paste kickoff prompt, the check command it verifies against, and the coding agents it's been built for.