The Loop  ·  Issue 016

The Loop

A field journal of the AI frontier — for engineers who ship.

§ Guides

By AI Blog Editor
Apr 18, 2026 · 1 min read

Agent loops that don't self-destruct

A loop without a budget, a success signal, and a log is a cost leak with extra steps. Design patterns for agents that stop when they should.

Every interesting agent is a loop: the model does something, the world responds, the model does something else. Loops are how an agent composes small capabilities into a useful outcome. They are also how an agent quietly runs up a four-figure bill when you left it unattended over the weekend.

Loops that don't self-destruct have three things: a stopping condition, a budget, and an observable trace. If any of those is missing, the loop either never stops, stops surprisingly, or stops for reasons nobody can reconstruct later.

Stopping conditions: not only success

Every loop needs at least three exit paths. Success — the thing we're looking for is present. Failure — the thing we're looking for is impossible. Budget — we've tried enough and should bail. All three are first-class; don't build a loop that only knows how to exit when it wins.

Success is usually easiest: a specific output shape, a status field, a tool result. Failure is harder — recognising "this can't work" takes judgment. Budget is the forcing function: when neither success nor failure is certain, the budget ends the loop and hands control back.

Budgets, three flavours

Step budget. A hard cap on tool-use rounds. The cleanest budget — no matter what, the loop exits after N steps. Good for bounded tasks.

Token budget. A cap on total model tokens across the loop. Good for open-ended work where steps vary wildly in cost.

Wall-clock budget. A deadline in real time. Good for latency-critical paths — a fifteen-second deadline matters to the end user regardless of how many steps you took.

 Loop scenario

Trace

  1. 01made progress
  2. 02made progress
  3. 03reached end conditionend

Result

Completed

3 steps · est. cost unit 3

The loop hit its success signal before the budget. Log it; move on.

Interactive · pick a scenario, tune the budget, read the trace

Making loops observable

A loop you can't read is a loop you can't debug. Every round should emit a structured trace: what the model saw, what it decided, which tool it called, what came back. Plain-text logs are fine for spotting obvious failures; structured traces are what let you answer "why did this turn go sideways?" six weeks later.

The emission can be as simple as a JSONL file. The habit of writing it is what matters. Without it, every production failure turns into a guessing game against a cold session.

Common failure modes

Thrashing. The model keeps calling the same tool with slightly different arguments, getting the same answer each time, and trying again. Detection: track the last N tool calls and bail if two are suspiciously similar.

Going backwards. The model undoes its own progress — deletes a file it just wrote, reverses a decision it already committed to. Detection: diff the world state across rounds; flag if the model keeps re-opening closed questions.

Context exhaustion. The loop runs long enough that useful context gets pushed out of the window. Claude's compaction helps, but for long-running agents, summarise periodically and throw away the raw history.

Silent success. The loop completed but your stopping condition wasn't the one you actually cared about. It found "a deploy," not "a deploy of the right commit." Be specific about what "done" means.

Escalation paths

When the budget hits, the right move is often not "give up" but "hand off." Escalate to a bigger model. Escalate to a human. Escalate to a notification channel. The best agents know the shape of their own uncertainty and surface it to the right reviewer — cheaply, clearly, with a summary of what was tried.

One sentence

A loop without a budget, a success signal, and a log is a cost leak with extra steps.

* * *

Thanks for reading. If a line here was useful — or plainly wrong — the comments are below and the newsletter has your back.

Elsewhere in this issue

3 more
  1. 01

    Guides

    Putting Claude on a schedule: routines, loops, and background work

    Apr 20, 2026

  2. 02

    Guides

    Writing a CLAUDE.md that actually helps

    Apr 20, 2026

  3. 03

    Guides

    A field guide to Claude Code: CLAUDE.md, hooks, skills, plugins

    Apr 20, 2026

Letters

Arguments, corrections, questions. Anonymous comments allowed; be kind, be specific.