A loop instead of an answer: what an agent adds on top of a model call

A single call ends with text, an agent ends with a changed world

A plain model call is simple. You send messages, you get one answer, the process is over. The only thing that can go wrong is the text that comes out. An agent works differently. Between the user request and the final answer there is a loop, and inside that loop the model observes the current state, chooses the next action, and real code performs that action. Every turn of the loop can hit someone else's service, write a row into a database, or send an email. The difference is not the intelligence of the model. The difference is that the process now has the right to cause side effects, and it now carries state that outlives a single call.

Three parts a single call does not have

• State. The history of steps, intermediate results, counters. This is what you feed the model on every turn, and it grows from step to step.
• An executor of actions. Code that takes a tool name and arguments from the model, validates them, and calls the real function. The model executes nothing itself. It only names an intent.
• A stop condition. The rule that ends the loop: the model returned an answer with no tool call, the step limit was reached, the budget ran out, a timeout fired.

request
  v
[state] --> model --> intent (tool + arguments)
   ^                          |
   |                          v
observation <--- executor (validate, call, result)
   |
   +--> stop check --> answer | limit exceeded | error

Why this changes the design questions

For a single call the main question is what the model will answer. For an agent the main question is different: where will it stop, and what can it break before it stops? Nine tenths of agent design is boundaries, not prompting. Which actions are allowed, how many times, up to what amount, what happens when a tool fails, who approves the irreversible. The prompt does not disappear. The output contract, the validation and the test suite from the prompting course all still run inside every step of the loop. The only change is that when they fail, they no longer spoil a piece of text: they launch a wrong action.

Error probability multiplies

Here is the arithmetic that explains most failures. Suppose one step is correct with probability 0.95, which is a very good number for picking a tool and filling in its arguments. Then a chain of three steps succeeds with probability around 0.86, a chain of ten with around 0.60, and a chain of twenty with around 0.36. Switching models does not save you from the product: it moves 0.95 towards 0.97, but it does not change the law. Hence the rule this course keeps returning to. A short deterministic pipeline is almost always more reliable than a free-running agent, and you introduce freedom exactly where the path is not known in advance.

Cheat sheet

• Agent = state + an executor of actions + a stop condition.
• The model names an intent; your code always does the executing.
• Success probability multiplies across steps, so a long chain is unreliable by construction.
• The main design question is where the loop stops, not how to make it smarter.