Agent Loop

An agent is an LLM (large language model) in a loop. One LLM call is one shot: text in, text out. In the loop, you give the model a goal and a set of tools; it calls one, reads the result, and picks the next step, and the model itself decides when the loop stops. The runtime around the loop (which tool ran, what came back, whether to continue) is plain code, written by you or owned by the host that runs your definition.

The unit being looped is one augmented call, and the anatomy under every agent product is the same three parts: instructions, a model, tools. Reliability lives mostly in the code that bounds the loop: the tools it can call, the checks between turns, and the cap that stops it. “Agent” itself names a role, acting autonomously on someone’s behalf, and plain-code services hold that role too: a trading bot executing under a brokerage mandate, or a commerce service that offers, agrees, and settles under signed artifacts. The LLM-in-a-loop build is the common implementation, and whether a model decides the steps is an implementation detail.

Two loops share the name. The agent loop runs at runtime inside the product; what persists between turns is the conversation, and it ends with the run. A loop that builds software runs across many sessions; what persists between passes is a written record of what must be true. Working that record to done is its own loop, run across sessions. A longer agent run produces a longer conversation, so it can substitute for neither the record nor the loop over it.

Reliability is counted in nines: 90 percent of runs succeeding, then 99, then 99.9. Four kinds of work buy them. Bounding buys the first: validated outputs, checks between turns, a hard turn cap, and tools that are safe to retry. Measuring buys the next: a fixed eval set turns “it seems to work” into a pass rate, and traces show which step fails, so you fix failure classes instead of anecdotes. Shrinking the model’s share buys the cheapest: every step plain code can do moves out of the loop, because shorter chains fail less. Failing safely buys the last: error paths built like features, escalation to a person wherever a step can do something no eval ever checked, like issuing a refund larger than any amount tested, and state that survives a crash.

No system runs at a hundred, hardened deterministic code included. A model in the loop starts lower and fails less predictably: the same input that passed yesterday can fail today. The reachable target is a loop that fails rarely and safely.