Agent Loop Anatomy: The Twenty Lines That Run Everything

Coding agents are presented as complex systems. The core is not. Strip away the interface and almost every agent is the same loop, and it is short enough to hold in your head.

The loop

Send the conversation to the model. If the response contains tool calls, execute them and append the results to the conversation. Repeat. If it contains no tool calls, the agent believes it is finished.

That is the whole mechanism. Everything else — planning, memory, subagents, verification — is either a tool, a message injected into the conversation, or a rule about when to stop.

Understanding this matters because it tells you where the leverage is. The model is one component. The tools, the conversation management and the stopping rules are the rest, and they are the parts you control.

The conversation is the state

There is no hidden memory. The model is stateless between calls; everything it knows on turn twenty is in the message list it was sent.

Two consequences follow immediately.

Cost grows with turns even if each turn is short, because the entire history is resent every time. A thirty-turn session resends the accumulated transcript thirty times. This is why prompt caching matters so much for agents, and why an unmanaged transcript gets expensive fast.

And anything not in the message list does not exist. If a constraint was stated on turn two and the transcript has since been trimmed, the model no longer knows it. Constraints that must hold throughout belong in the system prompt, which is never trimmed, not in a conversational message.

Where loops fail

Four failure modes account for most of what goes wrong, and each has a different fix.

Context exhaustion. Tool output accumulates until the transcript exceeds the window or degrades badly. A single file read can be thousands of tokens, and twenty of them dominate everything else. The fix is compaction, not a larger window.

Repetition. The model makes the same failing call repeatedly. Something about the state makes that action look correct, and nothing in the loop tells it otherwise. The fix is detection — track a normalised signature of each call and intervene on repeats.

Premature completion. The model stops without doing the work, having convinced itself the task is done. The fix is a verification gate: do not accept completion without a check that passes.

Drift. Instructions given early are followed less reliably as the transcript grows and they recede into the weakly attended middle. The fix is re-injecting critical constraints near the end, where attention is strongest.

Tool results are prompt content

This is the most underrated lever in agent engineering.

Whatever a tool returns becomes part of the model's input, competing for attention with everything else. A tool returning 40,000 tokens of raw output has just consumed a large share of the working context, most of it irrelevant.

Good tools return the smallest useful thing. A file reader that takes a line range rather than always returning whole files. A search that returns matches with paths and line numbers rather than full contents. A test runner that returns failures rather than the entire log.

Improving tool output quality frequently produces bigger gains than upgrading the model, and it helps whichever model you run. Tool result formatting covers the specifics.

Stopping is a design decision

The naive rule — stop when the model emits no tool calls — trusts the model's own judgement about completion, which is exactly the judgement it is worst at.

Better loops add explicit conditions. A turn ceiling, so runaway sessions terminate. A verification step that must pass before completion is accepted. A cost ceiling. A no-progress detector that halts when several turns produce no state change.

Each converts an open-ended process into a bounded one, which is what makes unattended running safe. Agent timeout strategies covers choosing the limits.

Build the simple version first

The loop above is genuinely enough to do useful work with three tools: read a file, write a file, run a command. Most sophistication added on top of that produces less improvement than better tools and better stopping rules.

Start there, instrument it, and add complexity only where you have measured a specific failure. Teams that begin with multi-agent orchestration usually end up debugging their orchestration rather than their task. Building your first agent covers the minimal version.