Loop Engineering for AI Agents: Complete Guide

Q: What is loop engineering?

Loop engineering is the discipline of designing and building the autonomous cycle an AI agent runs inside — everything around the model that makes a goal-seeking loop reliable: the stopping conditions that end it for the right reasons, the context management that keeps it sharp over many turns, the tool contracts that make its actions safe and its errors actionable, and the verification that proves the job is done rather than trusting the agent's claim. The term crystallized when Boris Cherny, creator of Claude Code, described his own workflow: "I don't prompt Claude anymore. I have loops that are running. My job is to write loops." The insight underneath is that the core agent loop — model reads context, calls a tool, result feeds back, repeat — is about six lines of code and effectively solved; every serious framework implements the same shape, and nobody competes on the while statement. The engineering value moved into the harness around that loop, which is why the same model dropped into a better-engineered loop can jump from the middle of a benchmark into the top five. Loop engineering names that work: less "what do I tell the agent" and more "what system would accomplish this without me steering every move."

Q: How is loop engineering different from prompt engineering and context engineering?

They are nested layers, each wrapping the one before, and the progression tracks where agent quality is actually decided. Prompt engineering controls the words you send — the instruction's phrasing, examples, and structure — and answers "how do I ask well?" Context engineering controls everything the model sees on a given call, not just your instruction: retrieved documents, tool outputs, conversation history, and what gets compacted or dropped — answering "what is in view when the model decides?" Harness engineering is the code around the model: which tools exist, how their results and errors are handled, how state is tracked between calls. Loop engineering sits outermost: the autonomous cycle that drives model, context, and harness toward a goal across many turns — how it iterates, when it stops, how it recovers, and what verifies completion. You never stop caring about the inner layers; you realize the prompt is one small piece of a larger control system. The practical shift in emphasis: when repeated instruction-tweaking fails to change agent behaviour — Karpathy's experience with style rules that agents ignored no matter how clearly they were written — the fix is almost always a layer up: a verifier that rejects bad output, a brake that stops a spinning loop, a tool contract that prevents the failure structurally.

Q: Why do AI agents say they are done when the task is not finished?

Because from the loop's perspective, "done" is ambiguous in a way humans do not expect: when an agent stops requesting tool calls and emits a final message, it has ended its turn — a mechanical event — and nothing in the bare loop distinguishes that from having completed the task. The model produces an end-of-turn when its next-token judgment says a response is complete, which correlates with "the work looks plausibly finished," not with "the acceptance criteria objectively pass." A coding agent writes changes, observes that progress was made, and announces completion while the test suite still fails — it declared victory because declaring victory is a valid next token, not because anything verified the claim. This is the single most common way agent loops fail in practice, and the correction is structural: define completion as an automated check the loop runs before accepting the agent's exit — the tests pass, the output validates against a schema, the build succeeds — and if the check fails, feed the failure back into context as the next instruction and continue the loop. In the mature pattern the agent cannot end the job at all; only the verifier can. "Done" becomes a property the system proves rather than a status the agent reports, which is the difference between an agent that feels productive and one you can leave running overnight.

Q: What stopping conditions should every agent loop have?

Four independent brakes, layered so that any one failing still leaves three. First, a maximum-iteration cap: a hard ceiling on loop turns — 25 to 50 is a sane starting band for most tasks — so a stuck agent cannot run forever regardless of what else goes wrong. Second, budget and time ceilings: explicit limits on tokens, dollars, and wall-clock seconds, enforced by the harness, so a misbehaving loop is bounded in cost — a research loop with a $5 cap and a 30-minute timeout can fail, but cannot fail expensively. Third, no-progress detection: if the agent issues the same tool call with the same arguments it already made, it is spinning, and the loop should intervene — inject a nudge describing the repetition, or escalate — rather than letting it orbit until the step cap fires. Fourth, and carrying the most weight, a real completion check: an automated condition that proves the task is done (tests green, schema valid, diff applies) — the only brake that ends the loop with success rather than merely ending it. The design rule: add the first three the day you write the loop, before autonomy, not after the first runaway; define the fourth before starting the task, because retrofitting "what does done mean" onto a running loop is how agents ship unfinished work with confidence.

Q: What is context rot and the doom loop in AI agents?

Context rot is the degradation of an agent's decision quality as its context window fills with accumulated junk over a long run: stale tool outputs, abandoned dead-end reasoning, duplicated file contents, and noise from earlier turns that no longer bears on the current step. Model performance measurably drops as relevant signal gets buried in irrelevant volume — the model attends worse, forgets constraints stated early, and re-derives things it already knew. In a loop this compounds into what practitioners call the doom loop: a rotted context produces a slightly worse decision, whose output adds more noise to the context, which produces a worse decision still — the agent gets observably dumber the longer it runs, which users experience as long sessions going off the rails. The counter-discipline treats context as a budget rather than a bucket. Compaction summarizes the conversation once it grows long and continues from the summary, preserving decisions and discarding deliberation. Offloading pushes bulky outputs — a 40,000-token file listing, a large API response — to external storage (typically a file the agent can re-read on demand) keeping only the relevant slice in view. Sub-agents isolate messy sub-tasks in a fresh context, returning only the clean result so the intermediate churn never pollutes the main loop. The instinct is to keep everything just in case; the skill is knowing what to throw away.

Q: How should tools be designed for agent loops?

Three rules cover most of it. First, few and focused beats many and overlapping: an agent choosing among a hundred tools loses track of which fits, and selection errors compound across a loop's many turns — Anthropic's heuristic is the sharp test: if a human engineer cannot say for certain which tool fits a given task, the agent has no chance. Merge overlapping tools, delete rarely-used ones, and name what remains so the right choice is obvious. Second, make writes idempotent, because loops retry by design — after timeouts, after verification failures, after no-progress nudges — and a retried create_customer call that creates a second customer means duplicate records and double billing discovered at 3 a.m. Anything that changes state must be keyed (an idempotency key, a natural unique constraint) so calling it twice equals calling it once. Third, write error messages for the agent, not the human: in a loop, an error is not a dead end but the next instruction — "invalid input" strands the agent, while "date must be YYYY-MM-DD, got 3rd June" tells it exactly what to change on the next turn. The pre-ship test for every tool: would an LLM reading this error know its next move? These are the same contracts that make MCP servers production-grade — the tool's description and errors are the only documentation the model ever reads.

Q: What is the maker/checker pattern for AI agents?

It is the structural separation of the system that produces work from the system that judges it, and it exists because autonomous loops have a quiet failure mode: an agent left alone tends to agree with itself. Self-assessment converges on self-approval — the same model that wrote the code, reading its own output, finds it plausible for the same reasons it wrote it — so a loop with no independent critic is just an agent nodding along to its own work. The pattern: one agent (the maker) does the work; a different check (the checker) grades it — ideally a hard, non-negotiable verifier like a test suite, type checker, schema validator, or build, and where judgment is unavoidable, a separate model instance with an adversarial brief and none of the maker's conversational momentum. The checker's verdict, not the maker's satisfaction, gates completion; failures flow back into the maker's context as actionable feedback and the loop continues; N consecutive failures escalate to a human with the full trajectory attached. The 2026 refinement moves the checker earlier: rather than verifying in CI after a commit lands — by which point you are building on top of unverified work — verification runs where the work is produced, inside the agent's own session, so problems are caught and fixed at write-time. The principle in one line: the worker does not grade its own homework, and "done" is the checker's word, never the maker's.

Q: How do I start with loop engineering without building an autonomous overnight agent?

Climb the ladder in the order the failure modes bite. Step one: take the basic loop and add brakes the same day — a max-iteration cap, a timeout, and a cost ceiling — before any autonomy; these three lines of configuration convert every future failure from unbounded to bounded. Step two: define "done" as an automated check before the task starts — the command that must exit zero, the schema the output must satisfy — because a completion criterion chosen afterward is a rationalization, not a spec. Step three: protect the context — compaction when runs grow long, offloading for bulky outputs, a sub-agent for the first genuinely messy sub-task — the moment you notice quality sagging on long sessions, which you will. Step four: audit the tools against the three contracts — few and focused, idempotent writes, agent-actionable errors — and fix the writes first, since those are the ones that page you. Step five: install the critic — start with hard verifiers (tests, types, builds) gating completion, add a second-model reviewer where judgment is needed, and wire escalation to a human after consecutive failures. Only after the critic has been saying no correctly for a while do you earn step six: hands-off operation — success criteria as the spec, durable checkpoints under long runs, and you nowhere in the loop. Trust the thing that says no before you leave it alone with the thing that says done.