Loop Engineering

Context engineering decides what the model can see. Loop engineering decides what the system does next.

Instead of a person repeatedly reading an answer and writing the next prompt, a loop turns that follow-up work into a designed system. It gives an AI a goal, lets it act, observes real feedback, evaluates the result, and either adapts or stops.

From a Good Prompt to a Good Loop

A prompt can produce a strong first attempt. A loop is useful when the number of steps cannot be known in advance, the environment can change, or the first attempt must be checked against evidence.

Ask → Generate → Return

The model produces an answer. A person decides whether it worked and writes the next prompt.

Frame → Act → Observe → Evaluate → Adapt
                 ↑______________________↓

The system gathers evidence, records state, and continues only while another pass is useful.

This idea builds on earlier agent patterns. The ReAct paper showed the value of interleaving actions with observations from an external environment. Anthropic's evaluator-optimizer pattern adds a distinct feedback step, while OpenAI's practical guide to agents describes agent runs as loops governed by exit conditions. The newer term loop engineering focuses attention on deliberately designing that whole cycle.

The Five Moves

The loop is not the arrows. The engineering lives in the contracts between the arrows: what counts as an action, which observations are trustworthy, who evaluates them, what state survives, and exactly when execution ends.

Write the Loop Contract First

Before choosing a model or framework, write a small contract. If these fields are vague, the loop will turn ambiguity into repeated cost.

goal: "What observable state should become true?"
inputs: "What starts the loop?"
state: "What facts and attempts persist between iterations?"
actions: "Which tools may the system use, and with what permissions?"
observations: "What external signals come back from those actions?"
evaluator: "Which rubric or deterministic checks judge the result?"
success: "What evidence proves the goal is complete?"
failure: "Which conditions require recovery or human help?"
budget: "Maximum turns, time, tokens, money, or side effects"

Observations Must Come From the World

The model saying “this looks correct” is not strong evidence. A useful observation is produced by something outside the answer being judged.

This is why tools matter: tests, browsers, databases, validators, and human review turn an internal guess into an observable result.

Separate the Maker From the Checker

For low-risk work, one model can draft and self-review. For important work, use a checker with a different job and limited authority.

The checker does not have to be another AI. Prefer the most deterministic evaluator available:

1. Exact checks — types, schemas, constraints, permissions, hashes
2. Executable checks — tests, linters, simulations, link validation
3. Rubric checks — an independent model or human using named criteria
4. Outcome checks — real user behavior or production metrics over time

State Is the Spine of the Loop

Context is what the model sees this turn. State is the compact record that lets the next turn continue without repeating or forgetting work.

Store concise decisions and evidence—not a model's private chain of thought. Good state is small, inspectable, and safe to resume.

Common Loop Shapes

The Repair Loop

reproduce → change one thing → run checks → diagnose → repeat or stop

Best for code, configuration, data cleanup, and any task with executable feedback.

The Evaluator-Optimizer Loop

generate → score with a rubric → return targeted feedback → revise

Best for writing, translation, design critique, and outputs whose quality improves through articulated feedback.

The Research Loop

search → inspect sources → identify gaps or conflicts → search again → synthesize

Best when completeness is not known in advance. The stop rule should measure evidence coverage, not the number of search results.

The Human-Gated Loop

prepare → verify automatically → pause before high-risk action → human approves or redirects

Best for payments, publishing, deletion, access changes, medical or legal decisions, and other consequential actions.

Failure Modes to Design Out

A Minimal Implementation

let state = initialize(goal, acceptanceCriteria, budget);

while (state.budget.remaining > 0) {
  const context = assembleRelevantContext(state);
  const proposedAction = await maker.chooseAction(context);
  const observation = await tools.executeWithinPolicy(proposedAction);
  const verdict = await evaluator.check({ goal, observation, state });

  state = recordIteration(state, { proposedAction, observation, verdict });

  if (verdict.status === "passed") return complete(state);
  if (verdict.status === "unsafe" || verdict.status === "blocked") {
    return escalateToHuman(state);
  }

  state = adaptPlan(state, verdict.feedback);
}

return stopWithBudgetReport(state);

The code is the easy part. The hard questions are domain questions: Which test proves the bug is gone? Which source is authoritative? Which action is reversible? Who can approve the final step? Those decisions are the actual work of loop engineering.

Practice: Design a Loop

Design a bounded AI work loop for this task:

TASK: ${task:triage new customer support issues each morning}

Define:
1. The observable goal
2. The trigger and required inputs
3. Allowed actions and tool permissions
4. Trusted observations from the external environment
5. The evaluator and its rubric
6. State that persists between iterations
7. Success, failure, and budget-exhausted exits
8. Human approval gates for risky actions
9. A trace format that makes every iteration auditable

Then identify the three most likely failure modes in your design and revise the loop to prevent them.

Further Reading

• Loop Engineering — Addy Osmani — the recent framing of replacing manual follow-up prompts with a designed system, plus practical cautions about verification and human responsibility
• Building Effective Agents — Anthropic — evaluator-optimizer workflows, environmental feedback, stopping conditions, and guidance on when agentic complexity is justified
• A Practical Guide to Building Agents — OpenAI — agent runs, exit conditions, tools, guardrails, and human intervention
• ReAct: Synergizing Reasoning and Acting in Language Models — foundational research on interleaving actions with observations from an external environment

Summary