The agent loop
A Socratic walk-through of the agent loop — reasoned out one step at a time, not lectured.
The question we started with
THE QUESTION #Why can a system that only writes text end up changing things in the world?
A language model emits tokens. That is the entire extent of what it does — no file was written, no message sent, no row deleted. Whatever it produces is a string, and a string is inert.
Yet an agent built on that model books things, edits repositories, sends email. Nothing was added to the model to give it hands. So where, precisely, did the capacity to act enter the system? It is worth locating exactly, because the answer determines what can be controlled and what cannot.
Reasoning it through
REASONING #Start with the smallest possible arrangement. A program calls a model, gets text back, and prints it. Nothing happens in the world. Now change one line: instead of printing the text, the program checks whether it looks like a request to run a search, and if so runs the search.
Ask yourself what changed. The model behaves identically — same weights, same generation, still only text. What changed is that a piece of ordinary code now treats certain text as an instruction. The capacity to act was not added to the model. It was added to the program around the model, and it consists entirely of the decision to interpret output as a command.
Now add the second half, which is where it becomes a loop. The search returns a result. Rather than stopping, the program appends that result to the conversation and calls the model again. And now the model's next output is conditioned on something it did not write — a fact from the world, arriving in the middle of its own reasoning.
Sit with that, because it is the crux. Without the return path you have a system that emits a request once. With it, you have a system whose next output depends on the effect of its previous one. That is a feedback loop, and feedback is what separates a system that describes from a system that steers.
What decides when it stops? Here is the part people find genuinely strange. The loop ends when the model produces text that the harness recognises as a final answer rather than a request. So the model chooses the number of iterations — it decides, by what it writes, whether there is another step. Compare that with an ordinary program, where the number of times a loop runs is determined by code someone reviewed. Here, control flow is being generated at run time by a statistical process. Every genuine surprise about agents descends from this one property.
Two consequences follow immediately, and they are opposite in sign. The good one: the system can handle tasks whose shape is not known in advance, because it discovers the next step from what it just learned rather than from a plan written before anything was known. The bad one: nothing guarantees termination, nothing guarantees progress, and an error early in the loop is not corrected by the loop — it is carried, because the wrong result is appended to the context and becomes part of what the next step reasons from.
This structure has a name and a lineage worth knowing: the interleaving of reasoning and acting was set out by Yao and colleagues in 2022 as ReAct, and the pattern in nearly every agent framework since is recognisably the same three beats. And an honest caveat: how reliably a model recovers from its own mistake mid-loop is not a settled property — it varies by model and task, and it is the main reason agents are dependable on some workflows and erratic on others.
The analogy
THE ANALOGY #Think of a dispatcher on a radio. The dispatcher never drives anywhere; they say sentences. But because a driver is listening and treats those sentences as instructions, and because the driver radios back what they found at the address, the dispatcher ends up moving vehicles around a city all day. Take the driver away and the dispatcher is a person talking into a handset.
the driver has judgement and will refuse an obviously bad instruction, whereas the code executing a model's output will execute anything that matches the expected form — so every check the dispatcher's driver would have applied has to be written explicitly, or it does not exist.
Clarifying the model
THE MODEL #Three refinements.
First, the location of agency. It is common to say a model "took an action". It did not; it emitted a description of an action, and a program acted. This is not pedantry — it is the difference between a system you can constrain and one you cannot, because everything the program will refuse to execute is genuinely impossible for the model to do, no matter what it writes.
Second, the loop is where capability comes from, and it is also where the cost comes from. Each iteration is a full model call with a context that has grown by one observation. Long agent runs get slower and more expensive per step, and eventually run into the context limit — which is why practical agents summarise, prune, or externalise their history rather than letting it accumulate.
Third, the misconception worth correcting: that an agent is a model with more autonomy. Autonomy is not a model property at all. It is a property of the harness — how many iterations it permits, which actions it will execute without asking, and whether it requires confirmation before anything irreversible. The same model is fully autonomous or fully supervised depending on code that has nothing to do with it.
A picture of it
THE PICTURE #How to readFollow the four states clockwise from the top — read, decide, execute, observe — and note that the arrow back into Reading is what makes this an agent rather than a single request. Two exits matter. The transition to the end state is chosen by the model itself, by writing an answer instead of a request, which is why nothing outside the model determines how many times the loop runs. The branch to the stalled state is the honest hazard: the loop has no built-in notion of progress, so escaping it requires a cap or a person, not the loop's own machinery.
What became clearer
WHAT CLEARED #The ability to act was never in the model. It was created by two pieces of ordinary code — one that treats model output as a command, and one that feeds the result back in — and everything that makes agents powerful and everything that makes them unnerving comes from that second piece. A system whose loop count is decided by its own generated text can solve problems nobody enumerated in advance, and can equally run in a circle spending money, and both follow from the same line.
Where to go next
ONWARD #- What a harness should refuse outright, and how that differs from asking a model to be careful.
- How agents manage a context that grows with every observation, and what gets lost when it is pruned.
- Why multi-agent arrangements are a variation on this loop rather than a different mechanism.
Key terms
TERMS #| Term | What it means |
|---|---|
| Agent loop | the cycle of model output, tool execution, observation, and renewed model call. |
| Harness | the surrounding program that parses model output, executes tools, and enforces limits. |
| Dynamic control flow | the pattern where what runs next is decided at run time by generated output rather than by fixed code. |
| ReAct | the 2022 formulation of interleaving reasoning steps with actions in a single loop. |
| Iteration cap | a hard limit on loop turns, the usual defence against a run that never terminates. |
Every term the collection defines is gathered in the glossary.