Loop Engineering: The Discipline That Shapes an Agent's Trajectory

A modern agent is not a prompt. It is a loop that calls a model repeatedly, feeds the result back in, and decides whether to go again. Whether it finishes, stays on task, recovers from a failed tool call, or costs ten cents versus forty dollars are almost never properties of a single turn — they are properties of the loop. We have prompt engineering for the turn and context engineering for the inputs. Loop engineering is the missing third discipline: designing the control structure itself. It is a methodology, not a library — there is nothing to install.

As models get more capable, the bottleneck moves off the single call and onto the structure wrapping the calls. Most agent failures in production are loop failures — runaway cost, silent drift off-goal, livelock, lost work after a late error — and none of those are fixed by a better prompt. The lineage is real: ReAct gave us thought, action, observation; Reflexion added a memory of past attempts; Boyd's OODA loop and classical sense–plan–act robotics predate both; and cascaded control loops from control theory already solved how to nest a fast loop inside a slow one. Loop engineering is the synthesis, aimed at LLM agents.

Every loop has four organs: a Sensor that gathers state, a Policy that decides the next action, an Actuator that does the thing, and Memory that carries state across iterations. If you cannot point to each in your design, you do not have a loop — you have a script that happens to repeat. The single most useful structural idea is that a healthy loop runs at two speeds: a tight tactical inner loop (observe, decide, act, check) where work gets done, nested inside a slow strategic outer loop (plan, run inner, reflect, replan) that reasons over the trace. The rule borrowed from cascaded control is the part everyone gets wrong: the inner loop must settle before the outer loop intervenes. Reflecting after every action is an unstable controller — it thrashes.

The prescriptive heart of the methodology is eleven principles, each with an imperative and a "smell" that tells you when you are violating it.

Loops link along two axes — vertical (nesting by time-constant) and horizontal (handoff over time) — across five topologies: the single loop (always your default), the cascade (nested two-speed, how subagent delegation works), the pipeline (staged handoff with compression at every boundary), the tree (recursive decomposition and fan-out, the workhorse for big tasks), and feedback (cyclic generator/critic, the easiest to make non-terminating — never without a shared budget cap). The takeaway: trees are central, but a tree's health depends almost entirely on disciplined boundaries — clean termination and compressed, verified returns — not on how clever the loop is inside any single node.

Each anti-pattern is the violation of a principle, and naming them is half the discipline. The Runaway has no termination or budget. The Thrasher re-plans every step and never settles. The Blind Stepper skips per-step verification so errors compound silently. The Spinner iterates without progress. The Hoarder passes full child traces up to the parent until context explodes. The Sisyphus redoes verified work after a late failure. The Amnesiac drifts off-goal because it trusted the model to remember the objective. The Optimist has only a happy path. The Pyramid nests and fans out without bound. The Black Box leaves a trace you can only debug by re-running.

The shape in code: a minimal inner loop where stopping is structural, not hoped for. Termination pressure is checked first, the goal is re-injected every iteration (not model-remembered), every step is verified, progress is tracked to detect spin, and verified work is ratcheted so a later failure cannot unwind it.

async function innerLoop(goal: Goal, budget: Budget): Promise<Result> {
  let lastProgress = 0, stalled = 0;

  while (true) {
    // termination pressure, checked first
    if (budget.spent.iterations >= budget.maxIterations) return degrade("over-budget");
    if (budget.spent.tokens >= budget.maxTokens) return degrade("over-budget");

    const state  = await observe();             // sensor
    const action = await decide(goal, state);   // policy — re-inject the goal (#8)
    const result = await act(action);           // actuator
    budget.spent.iterations++;

    const check = verify(result);               // check every step (#4)
    if (check.outcome === "done")   return finish(result);
    if (check.outcome === "failed") return recover(result);   // failure path (#9)

    // progress signal / spin detection (#5)
    if (check.progress <= lastProgress) {
      if (++stalled >= 3) return escalate("stuck");           // hand up to the outer loop
    } else {
      stalled = 0;
      lastProgress = check.progress;
      ratchet(result);                          // lock in progress (#7)
    }
  }
}

The methodology ends with a scorecard: grade a loop 0–2 on each of the eleven principles. Under 14 and your loop is fragile — and the lowest scores tell you exactly what breaks first under load. Outcome eval tells you the loop works; trajectory metrics — steps-to-done, spin incidents, drift incidents, recovery rate — tell you it works well, and whether it will keep working as load grows. A loop at 99% success with a rising steps-to-done is failing in slow motion.