The Agent Loop
By the end of this module
- Describe an agent as a loop around a model rather than a cleverer model
- Explain what decides whether the loop runs again
- Name the stopping conditions and which of them are failures
Definition
Everything so far has been one call: text in, text out. An agent is what you get when you put a loop around that call and give the model a way to ask for something before it answers.
The model itself does not change. It still returns a distribution over the next token, it still has no memory between calls, and it still knows only what is in its prompt. What changes is that the runtime reads the reply, notices the model asked for a tool, runs it, appends the result, and calls the model again with a longer prompt. Repeat until it stops asking.
The Loop
Below is an agent answering a question it cannot answer from the prompt alone. Step through it rather than running it to the end the first time, and watch the badge at the bottom of each turn.
Why have this merchant's payouts been failing, and what do they need to do about it?
Nothing has run yet.
Three model calls, not one. The reader sees a single answer at the end, and the single answer cost three round trips, two tool calls and a prompt that grew each time.
The badge is the mechanism. When a reply comes back marked tool_use, the runtime runs the tool and calls the model again. When it comes back end_turn, the loop exits. The model does not decide to stop and the runtime does not decide either: the reply carries a field, and the loop reads it. Nothing in the loop understands the task.
Stopping Conditions
A loop needs a way out, and not all of the ways out are success. These are the ones the harness in this knowledge base reports.
| Stop reason | What happened | Success |
|---|---|---|
end_turn | The model replied without asking for anything else. | Usually. It says the loop finished, not that the answer is right. |
tool_use | The model asked for a tool. The loop runs again. | Not an ending at all. It is the continue case. |
max_tokens | The reply hit the output ceiling and was cut off mid-sentence. | No. Often shows up as a truncated answer nobody notices. |
cancelled | Something stopped the run: a user, a timeout, a shutdown. | No, but not a fault either. Worth separating from errors. |
error | The call failed, or a filter or guardrail intervened. | No. Collapsing filtered and failed into one reason loses why. |
Treating all of these as one outcome is the most common reporting mistake in an agent system. A run that hit a token ceiling halfway through its work and a run that finished both end with the loop exiting and a reply on screen. Only one of them worked. A later module is entirely about giving these ends names and counting them.
What This Changes
| Property | One call | A loop |
|---|---|---|
| Cost | One call, one prompt. | One call per iteration, each on a longer prompt than the last. |
| Latency | One round trip. | Round trips plus tool time, in series, with nothing overlapping. |
| Failure surface | The answer is wrong. | Any tool can fail, the loop can run away, and the stop reason can hide which happened. |
| What you can observe | Input and output. | Every step, if it was recorded. If it was not, a failed run leaves nothing to look at. |
| What it can do | Answer from what is in the prompt. | Fetch what it needs, and act on the world through the same mechanism. |
An agent answers a question after calling three tools. What decided that it should stop after the third one?
Discussion
Pick a task someone would want an agent to do in your team's work. Count the tool calls it would take on a good day. Then ask what should happen on the day the third one returns an error, and whether anyone would find out.