Anatomy of an Agent Loop

One loop to rule them all

It is easy to be intimidated by the growing zoo of agent frameworks, each with its own vocabulary of planners, executors, controllers, and graphs. But if you strip the abstractions away, almost every agent ever built runs the same small cycle: observe the situation, think about what to do, act on the world, and repeat, until a stopping condition is reached. That is the whole engine. The frameworks differ mostly in how they dress it up.

Understanding this matters because it tells you where the real engineering lives. It is not in the loop, which is a dozen lines of code. It is in the quality of the decisions inside each pass of the loop, and in the conditions that end it.

The four moves, in detail

Observe. Before the model can decide anything, you assemble the context it will reason over. This is more of an art than it sounds. You include the goal, a record of the steps taken so far, the result of the most recent action, and any memory relevant to the current moment. Include too little and the model loses the thread; include too much and you drown the signal in noise (and pay for every token). Curating this context well is one of the highest-leverage things you can do.

Think. The model decides the next action. In a well-built agent this is usually expressed as a structured tool call, the model names a tool and supplies arguments, rather than free-form prose you then have to parse. Some agents also ask the model to produce a short plan up front and follow it; this can help on complex tasks but becomes a liability if the plan is treated as sacred and never revised in light of what actually happens.

Act. You execute the chosen action against the real world: call the API, run the query, send the message. The non-negotiable rule here is that you capture the result, including, and especially, failures. A tool that times out or returns an error is information the agent needs on the next pass. Swallowing errors is how agents get stuck pretending everything is fine.

Decide. With the new result in hand, the loop asks: is the goal met? If yes, it stops and produces a final answer. If no, it goes around again, now better informed. This decision is where autonomy actually lives, and it is the step most teams under-design.

Where loops go wrong

Two failure modes dominate in practice.

The first is the runaway loop. The agent never quite decides it is finished, so it keeps going, calling tools, burning tokens, and running up cost and latency, sometimes in a tight repetitive cycle where it tries the same failing action over and over. The fix is unglamorous but essential: cap the number of iterations and the total spend per run, and make "give up and ask a human" a first-class, valid way to end. An agent that knows how to quit is more reliable than one that always thinks it is one more step from success.

The second is context rot. Each pass appends more text, another tool result, another chunk of reasoning, until the context window is bloated with stale output that no longer matters. The model's attention gets diluted, quality drops, and cost climbs. The remedy is to manage context actively: summarise older turns into compact notes, drop raw tool dumps once you have extracted what matters, and carry forward only what the next decision genuinely needs.

Stopping conditions deserve real design

Most teams pour their attention into the thinking step and treat stopping as an afterthought. That is backwards. A well-designed agent knows exactly three ways a run can end: it succeeded and has a result; it is genuinely stuck and should escalate; or it has hit a budget, of steps, time, or money, and must stop. Each of these should produce a clean, honest outcome. The worst behaviour, and a common one, is an agent that "ends" in an ambiguous state: a half-completed action, or a confident final answer that papers over the fact that it never actually finished the task.

Write these terminal states explicitly. Decide what the agent returns in each case, and make sure a budget-hit or stuck state is reported as such, not disguised as success.

Make the loop inspectable

Because the loop chooses its own path, you fundamentally cannot debug it by reading the source code. The code is the same every run; the behaviour is not. The only way to understand a specific bad outcome is to see what that specific run observed, decided, and did, in order.

So instrument the loop from the start. Emit a structured trace for every pass: the context that went in, the action the model chose, the arguments, the result that came back, and the timing and token cost. Tie it all to a single trace ID you can search. When a user reports that the agent did something strange, that trace is the difference between a five-minute fix and an afternoon of guessing. Teams that add observability after the first production incident always wish they had added it before.