Pattern taxonomy

Loops do not differ meaningfully by which model or tool runs them. They differ along four axes that actually change behavior, cost, and trustworthiness. Classify any loop by picking one value per axis; the named patterns further down are recurring combinations of these axis values.

A loop is a task plus a check. The cycle runs clockwise: you delegate a task, an agent acts on it, a check decides whether the work is good enough to stop, wrong enough to retry, or stuck enough to escalate, and the loop adjusts and runs again. The check is the emphasized part, because a task without a check is just hope.

---

Axis A — Termination (when does it stop?)

Value	Stop condition	Example	Risk it introduces
Time-recurring	Fires on a schedule; never “finishes”	morning triage run, scheduled automations	Does work nobody asked for; cost drift
Goal-met	Runs until a verifiable predicate is true	evaluator-optimizer, “tests pass and lint clean”	Non-convergence if the predicate is unreachable
Fixed-pipeline	A predetermined sequence of steps, then done	prompt chaining, spec → plan → tasks → implement	Rigid; cannot adapt to unforeseen subtasks
Budget-exhausted	Caps rounds, tokens, or wall-clock, then yields	--rounds N, --max-fix-rounds	Ships partial work or stalls; needs a fail-safe

Mature loops use goal-met with a budget fail-safe: run until the goal is met, but never past N rounds. Pure time-recurring loops are the newest and most cost-dangerous class, because they run on infrastructure time, not your attention, which is the whole point and the whole hazard.

Axis B — Verification diversity (how good is the check?)

This is the axis that actually separates a trustworthy loop from a plausible-looking one. Ordered weakest to strongest:

1. Self-check — the same model, same context, grades its own output. Cheapest, weakest. Prone to sycophantic self-review: the model that wrote the work is too nice grading its own homework.
2. Fresh-context, same model — a new instance of the same model, with no memory of the generation, re-judges from scratch. Removes conversational sycophancy; still shares the model’s blind spots.
3. Cross-model adversarial — a different model family reviews. Catches failures correlated within one model’s training. This is the core reason AIOS keeps model diversity in the loop.
4. Deterministic evals / tests / types — non-LLM ground truth: unit tests, typecheck, linters, secret scanners. Cannot be sweet-talked. The “back pressure” that makes coding the killer domain for agents.
5. Layered — several of the above stacked with a human gate. Strongest, most expensive. Where aios ship lives.

Rule of thumb

The more autonomy and the longer the loop runs unattended, the further down this list your verifier must sit.

Axis C — Control flow (who decides the next step?)

Value	Who drives	Anthropic’s term	When it wins
Scripted orchestration	Fixed code paths call the model	Workflow	Task decomposes cleanly; you want predictability, auditability, lower cost
Model-driven	The model chooses its own next action in a loop	Agent	Open-ended tasks where you cannot predict the steps or the number of iterations

Anthropic’s central prescriptive point: start with workflows; reach for agent autonomy only when the task genuinely cannot be hardcoded. Most production value is simpler than people build. Real systems mix the two: a scripted outer loop (gates, sequencing) around model-driven inner work.

Axis D — State across iterations (what persists between turns?)

Value	Where memory lives	Consequence
Fresh context each turn	Nothing carries in-context; each turn starts cold	Cheap, avoids context rot, forces externalized state. The agent forgets; the repo does not.
Accumulated conversation	Full history threaded through each call	Rich context; degrades as the window fills, costs more, eventually compacts
Externalized state	Files, git history, a plan or TODO file, a board, a log	Durable across crashes and sessions; the spine of every long-running loop

The strongest long-running loops keep per-turn context small and push durable state to disk so a fresh-context turn can still make correct forward progress. Externalized state is what makes a loop resumable and schedulable.

---

The eight named patterns

Each is a recurring point in the four-axis space. For each: what it is, when to use it, and how it fails.

1. Evaluator-optimizer (generator-critic)

One call generates, a second call evaluates against criteria and feeds back, in a loop. Goal-met termination, a separate-model verifier, a scripted two-role loop.

Use when

You have clear evaluation criteria and iterative refinement measurably helps (writing, translation, code against tests).

Fails by

Reward-hacking the evaluator (the optimizer learns to satisfy the critic’s letter, not its intent); non-convergence when the critic keeps moving the goalposts; sycophancy if evaluator and optimizer are the same model and context.

2. Reflection loop (Reflexion / self-refine family)

The agent reflects on a failure signal, writes the reflection to memory, and retries with that reflection in context. Budget or goal termination, model-driven, an accumulated reflection buffer.

Use when

There is a cheap outcome signal (a test pass/fail, a task reward) to reflect on.

Fails by

Self-correction without a real external signal degrading rather than improving results; reflections that rationalize rather than diagnose.

3. Ralph loop (while-loop agent / fresh-context autonomy)

The same prompt, fresh context every turn, one item per loop, progress accumulating in files and git rather than in the context window. Deterministic back-pressure (tests, types, compiler) is the verifier.

Use when

Greenfield work, high tolerance for eventual consistency, strong type or test back-pressure, and a human watching for drift.

Fails by

Non-convergence (“waking up to a broken codebase”); duplicate work when the model wrongly concludes something is not implemented; reward-hacking the compiler (placeholder implementations that compile); cost blowup. Explicitly not recommended for existing codebases.

4. Rubric-gated self-correction

Generate, grade against an explicit written rubric, revise, bounded by a budget; the rubric, not vibes, is the pass bar.

Use when

You need trustworthy iterative output without a full test suite (specs, briefs, digests).

Fails by

A weak rubric that is easy to satisfy superficially; the grader and author collapsing into one sycophantic voice (mitigate with a fresh or different model as grader).

5. Judge panel / voting / debate

Run the task or the judgment several times and aggregate: majority vote, multiple review prompts, or multi-agent debate. Parallel diversity is the verifier.

Use when

Higher confidence justifies the cost, or a single judgment is too noisy to trust.

Fails by

Correlated errors (jurors share a model and a blind spot, so the vote is confidently wrong); cost scaling linearly with jurors; LLM-judge biases toward position, verbosity, and self-preference.

6. Loop-until-dry (queue / worklist drain)

A loop pulls the next item from an externalized worklist, actions it, marks it done, and repeats until the list is empty.

Use when

Work arrives as a stream: a backlog, CI failures, a triage inbox, a roadmap.

Fails by

The queue never draining (the loop generates more items than it closes); no dedup, so items get re-processed; priority inversion.

7. Shadow-then-promote (gated egress)

The loop does everything in a shadow copy, and a separate, explicit gate promotes output to a shared or production surface only on approval.

Use when

The loop’s output crosses a trust boundary: a shared brain, a client surface, production.

Fails by

The gate becoming a rubber stamp; default-allow instead of default-deny.

8. Plan-build-review pipeline (spec-driven loop)

A fixed outer sequence — spec → plan (reviewed) → build (reviewed) → merge (gated) — each stage a sub-loop with its own verifier.

Use when

The change is non-trivial and must be right the first time.

Fails by

Over-specification (big spec files as ceremony when you could just talk to it); stages that do not actually gate; plan drift from the built code.

---

Cross-cutting failure modes to design against

These recur in every pattern above:

• Reward-hacking the evaluator — the optimizer satisfies the measurable proxy, not the goal (placeholder code that compiles, text that pleases the critic). Mitigation: make the check deterministic and hard to game, and diversify the verifier.
• Sycophantic / self-review collapse — author and grader share a model and context and agree too easily. Mitigation: fresh context, then a different model, then a non-LLM check.
• Non-convergence — the loop never reaches its stop condition. Mitigation: always pair goal-met with a budget fail-safe; on budget exhaustion, stop and hand to a human rather than force-ship.
• Cost blowup — unattended and time-recurring loops and juror panels burn tokens fast. Mitigation: budgets, cheap-model stop-checkers, one item per loop.
• Comprehension / intent debt — the faster the loop ships work you did not write, the wider the gap between what exists and what you understand. Mitigation: read the output; keep the human as reviewer, not just the person who presses go.

---

Decision guide Which of these patterns fits which task shape, plus the three decisions that dominate the rest.

Reading list The verified sources each pattern traces back to.