Deep read · July 4, 2026 · source published July 1, 2026

20 Loop Design Patterns Every AI Engineer Should Know

Source: “20 Loop Design Patterns Every AI Engineer Should Know” by @sairahul1 · July 1, 2026

The argument is that the current jump in AI quality is not coming from smarter models, it is coming from wrapping a model call in a loop: generate, evaluate, learn, improve, repeat. The piece sorts 20 named loop patterns into five families — quality, memory, planning, exploration, and loops that improve the loop — and shows that every one reduces to the same four beats: act, observe, evaluate, adjust. It matters because most builders are already running some of these patterns without a name for them, and a named catalogue is what lets you spot the two or three you have never built. The strongest section is the last family: loops where the system measures its own latency, cost and quality, then edits its own steps.

Worker vs wrapper

The piece opens on one distinction and never leaves it: an agent is a worker that does the job once, a loop is what makes that worker improve. Old shape: prompt goes in, response comes out, done. New shape: generate, critique, rewrite, score, retry, remember, improve.

The claim is that production AI systems are almost never a single model call. They are a call sitting inside a cycle that runs until the output clears a bar. That shift has a name — loop engineering: designing the observe-act-check-adjust cycle as the unit of work, rather than tuning one prompt and hoping.

Quality loops: the generator is a bad judge of its own work

The first family (patterns 1-5) rests on one insight: the model that writes something is the worst-placed to grade it. So you split the roles. Generate a draft, hand it to a separate critic — a second model call whose only job is to find what is wrong — rewrite, and repeat until a quality bar is met.

Pattern 3 stacks four critics (correctness, style, safety, domain) and only ships when all four pass. Pattern 4 is the adversarial critique loop, where the critic's job is to break the answer rather than polish it.

This is one idea wearing three costumes across three worlds. In finance it is four-eyes, or maker-checker. In software it is code review. In AI it is LLM-as-a-judge. The version most people skip is the adversarial one: pointing a critic at your own draft before it leaves, not just at other people's findings.

Memory loops: only fail once

Family two (patterns 6-10) is where the piece is strongest. Reflexion (pattern 6): when an attempt fails, the agent writes down why in plain words, stores that lesson, and pulls it into the next try — so it fails once rather than repeatedly. Pattern 8, the error library, searches past failures before starting a new task and applies the known fix up front.

Pattern 9 is the one nearly everyone misses. Most systems store only failures. Store the wins too: save what made a good output good, and retrieve it when a similar task arrives. Correction logs get built religiously; success capture almost never does.

Pattern 10, memory compression, is the housekeeping that keeps the rest usable: after N items pile up, fold many specific memories into fewer higher-level rules so the context window does not silt up.

Planning and exploration: don't commit to the first path

Families three and four (patterns 11-18) cover adapting when reality moves, and searching when one answer is not enough. Plan, execute, observe, replan — a spiral, not a waterfall. Goal decomposition breaks a big goal down until each unit fits inside a single call.

The two worth stealing are the exploration patterns. Branch-and-explore generates several approaches at once (conservative, aggressive, creative), scores them, keeps the best and bins the rest. The debate loop (pattern 18) runs two agents arguing opposite sides of a decision until the answer that survives the disagreement wins.

In finance that second one is an investment committee running bull versus bear. It is not the same thing as a panel of independent scorers averaging out noise — a genuine for-versus-against argument surfaces different failure modes than a panel does.

The loop that improves the loop

The last family (patterns 19-20) is the payoff. Pattern 19, prompt optimisation: run a prompt over a test set, score every output, find where it fails, rewrite the prompt, rerun. The prompt evolves without a human touching it.

Pattern 20 goes up a level. The system measures its own latency, cost and quality per step, then edits its own workflow: parallelise a slow step, swap an expensive model for a cheaper one where quality holds, add a critic where quality dips. That is a meta-loop — a loop whose job is to rewrite the loop underneath it.

The direction of travel here is not controversial; several independent lines of work point the same way. The tension is on trust. This piece assumes the evaluator is reliable and never mentions what happens when it is not.

Where it oversells (the adversarial read)

The strongest case against the piece is that it is a listicle selling a mindset, so it skips the hard parts. It never says when NOT to loop. Every added lap costs tokens, latency and money, and for a cheap, error-tolerant task a single call is the right call. Pattern 20 nods at cost once; the other nineteen ignore it.

The bigger hole is the judge. A loop only improves if the thing scoring it is trustworthy. A weak or biased critic does not merely fail to help — it locks in the wrong answer a little harder with each pass, and "keep running until all constraints pass" with a bad judge loops confidently toward garbage.

Read it as a naming system for patterns you will recognise, not as engineering guidance you can build straight from.

Vocabulary

loop engineering — designing the repeating cycle as the unit of work, not the prompt
reflexion loop — an agent writes down why it failed, then feeds that lesson into its next attempt
error library loop — store every past failure and check it before a new task, so mistakes don't repeat
memory compression loop — fold many specific memories into a few general rules so context stays usable
adversarial critique loop — a critic whose only job is to break the answer, not to improve it
constraint satisfaction loop — keep revising the output until every business rule passes at once
meta-loop — a loop that measures its own cost and quality, then rewrites its own steps

If you're building — what to watch for

Audit what you already run against the 20 — most builders find they have most of the quality and planning families and zero of one or two others, and the gap is only visible once the patterns have names.
If you log corrections but not wins, you are running half a memory loop. Capturing what made a good output good is cheaper than it sounds and almost nobody does it.
A judge panel and a debate are not the same instrument. Independent scorers average out noise; two agents arguing opposite sides surface failure modes an average never will.
Before adding a loop, price it: every lap costs tokens, latency and money. Cheap, error-tolerant tasks are correctly done in one call.
Any self-improving loop needs a guard on its own evaluator — an agreement check, a meta-eval, something. Without one, the loop optimises for the ruler instead of the thing.

Reading it critically

The "prompts are dead / this is worth six figures" framing is sales, not analysis — loops add latency and cost that 19 of the 20 patterns never mention.
A loop only improves if the evaluator is trustworthy. A weak critic locks in wrong answers with each pass — Goodhart at the ruler — and the piece never addresses judge quality.
Memory loops assume failures are diagnosable in words. Naming why you failed is often the whole difficulty, and stored "lessons" accumulate noise unless something decides what is signal.
"Keep running until all constraints pass" has no stopping discipline. Without a max-retries or circuit-breaker it can loop forever or burn the budget.

Read the original → ← Back to the Reading Desk