What an Agent Is

An agent is not a model, and it is not a prompt. It is a program that calls a model in a loop, hands it a set of tools it may ask for, executes what it asks for, feeds the result back, and decides when to stop. Four steps of control flow, written by you, wrapped around something that cannot remember or act on its own.

The word gets attached to at least four different products, and only one of them lets the model choose what happens next. That one costs more, fails differently, and is much harder to test than the other three. It is also the only one that handles work nobody could enumerate in advance. That is what makes it worth the trouble, and what makes it the subject of this book.

Four Things Called an Agent

The first is a chat assistant: one model call, no tools, a person reading the answer. The second is a retrieval application — fetch some documents, put them in the prompt, make one call. The third is a workflow with a model step, where your code owns the sequence and the model fills a slot in it: classify this ticket, draft this reply, extract these fields. All three are useful, cheap and predictable, and calling them agents mostly sells consulting.

The fourth is a loop where the model chooses the next action from a set you have given it, sees the result, and chooses again. That choice is the whole difference. In the first three the sequence of steps is fixed before the request arrives; in the fourth it is decided during the request, by a component that is not deterministic and cannot be stepped through in a debugger.

The Definition Used in This Book

An agent is a program that repeatedly sends a growing context to a model and receives either a final answer or a request to run a tool, executes the request, appends the result to the context, and repeats until a stopping condition. That is the definition every later chapter builds on, and it is all there is at the centre.

messages = [system_prompt, user_message]

# decide -> act -> observe -> repeat
while True:
    reply = model(messages, tools=TOOLS)
    messages.append(reply)
    if reply.stop_reason != "tool_use":
        return reply.text
    for call in reply.tool_calls:
        messages.append(run(call))

Read that in words: build a list of messages, call the model, and look at why it stopped. If it stopped because it wants a tool, run the tool, append what came back as another message, and go around again. If it stopped for any other reason, the loop is over. Everything this book adds — memory, retrieval, planning, limits, evaluation, permissions — is scaffolding bolted onto those few lines, and none of it changes their shape.

Who Holds Control

In a workflow, your code decides what happens next and the model contributes a value. In an agent, the model decides what happens next and your code decides what it is allowed to do. Control flow moves into a probabilistic component, and the guardrails move into the surrounding program.

That inversion is the reason the rest of the book exists. Once the model chooses the sequence, you can no longer enumerate the paths through your own system, so correctness has to be established by measurement over a set of cases rather than by reading the code. Ceilings, permissions and approval gates stop being polish and become the mechanism that bounds what a wrong choice can do.

What Each Half Contributes

The model brings judgement over unstructured language. It reads a rambling ticket that mentions three separate problems, notices that one of them is a billing error nobody classified for, and picks between two tools whose purposes overlap. Written as rules, that behaviour takes years and never quite works; the model does it out of the box, imperfectly, on the first afternoon.

Your code brings everything the model cannot do. It executes. It remembers between turns. It counts, enforces a limit, refuses an action, and writes an audit record. When people say an agent "decided" to refund a customer, what happened is that the model emitted a request and a dispatcher in ordinary code ran it — which is exactly why authorization belongs in that dispatcher and never in the prompt.

Autonomy Is a Dial

The same machinery runs at several settings. At the lowest, the agent drafts and a human sends. In the middle, it acts but pauses for approval before anything consequential. At the top, it acts alone within limits your code enforces. Sundry's support agent ends this book at the third setting for refunds under its $150 ceiling and the second above it, and that split is a product decision revisited properly in Chapter 12.

Nothing about the technology fixes the position on that dial. It is chosen by asking what happens the times the agent is wrong, how quickly a person would notice, and what it costs to undo — three questions worth answering in writing before the first tool that changes anything gets built.

Why the Distinction Is Operational

The moment the model owns sequencing, four things change at once. Cost becomes variable, because an easy ticket takes three model calls and a hard one takes eleven. Latency becomes multi-turn, so the customer waits for a chain rather than a single response. Testing stops being deterministic, because the same input legitimately produces different runs. And the blast radius becomes whatever the tools can reach, rather than whatever the code path allows.

Each of those four is a chapter later in this book: cost in Chapter 13, latency in Chapter 13, evaluation in Chapter 9, and the blast radius in Chapter 12. If a task does not need the model to choose — and most tasks do not — you can have none of those problems by writing a workflow instead, which is the argument Topic 04 makes with numbers.