9.1 What an agent is — and when you don't need one

What this is and why it exists

The first decision in agent work is whether you need an agent. If the steps are known in advance, a fixed sequence with a model at one step is cheaper, faster, more predictable and easier to debug than an autonomous loop — and it is what most problems brought to agents actually are. This topic is how to tell the two apart, and the arithmetic that keeps the choice honest.

The vocabulary

• Function call — one operation, done once.
• Chain — a fixed sequence of steps, decided by you at design time.
• Agent — a system that decides its own next step at run time.
• Autonomy — how much the system is allowed to decide.
• Blast radius — how much damage a wrong decision can do.
• Agentic loop — repeating think-act-observe until some condition is met.
• Determinism — the same input producing the same sequence of steps.

The mental model

Three shapes, and the difference is who decides the order.

A function call does one thing: classify this message, extract these fields, summarise this document. You decided everything; the model fills in one blank. It is one request, predictable in cost and latency, and trivially testable.

A chain is a fixed sequence you wrote: retrieve, then summarise, then format, then validate. You decided the order, at design time, and it is the same order every time. Cost is a known multiple of the steps. When it breaks, the failing step is obvious because there is a step.

An agent decides its own next step, at run time, based on what it has seen so far. That is the whole distinction, and everything else follows from it — the flexibility, the cost, and the difficulty of saying what it will do before it does it.

So the question is: do you know the steps in advance? If yes, write them down and you have a chain. If the steps genuinely depend on what is found along the way — the answer determines whether a second search is needed, the error determines which repair applies, the document type determines the extraction — then an agent earns its place. Most problems people bring to agents are chains that were never written down, and writing them down is the whole fix.

Autonomy and blast radius are two separate dials, and setting them independently is what makes autonomy safe to grant. Autonomy is how much the system decides for itself; blast radius is how much a wrong decision costs. A system with high autonomy over read-only operations in a sandbox is safe to let run, because a bad decision produces a wasted minute. A system with low autonomy over payments still needs a confirmation gate, because one wrong decision is irreversible.

People conflate them and then set both low out of caution, which wastes the technology, or both high out of enthusiasm, which is how incidents happen. Set them apart: grant wide autonomy where the actions are reversible and cheap, and narrow it sharply where they are not — read freely, write with confirmation, never send or pay without a person. The tools topic develops this and the security topic makes it structural.

The design most production systems should start from is a deterministic workflow with a model at one step, and it deserves stating plainly because it is unglamorous and usually correct. A fixed pipeline where one stage is "the model decides which category this is" or "the model writes this summary" gets most of the benefit: the model does the part only a model can do, and the sequence, the error handling, the retries and the observability are ordinary software, which you already know how to build and test.

Two extensions cover most of the rest. Model-decided routing: a fixed set of paths, with the model choosing which one — still bounded, still testable, since you can enumerate every path. And a bounded loop: one repeat with a strict limit, such as retry the extraction at most twice if validation fails. Neither is an autonomous agent, and both handle a great deal of what people build agents for.

Then the arithmetic, which is what keeps the idea honest. An agent making a decision per step, with tool results returning into the context, makes many model calls per task — commonly ten to thirty, sometimes far more — and each carries the accumulated conversation, so later calls in a loop are much more expensive than earlier ones. Cost per task is not the cost of one call times the steps; it grows faster, because the context grows with the transcript.

Latency multiplies the same way: the same task taking twenty sequential calls takes twenty round trips, and no amount of engineering makes that feel immediate. And reliability compounds downward — if each step is right ninety-five times in a hundred, ten dependent steps are right about six times in ten, which is a working demonstration and a poor product.

Work that multiplier out before building. Estimate steps per task, tokens per step including the growing transcript, and requests per user, and compare against what a chain would cost. If the agent is ten times the cost of the chain, the flexibility has to be worth ten times, and sometimes it is — but the number should be on the table.

Agent-washing is the failure this topic exists to name. Rebuilding what a function call already does, wrapped in a loop, with latency, cost, nondeterminism and a new class of failure as the only things added. The test is simple and worth applying honestly: write down the steps your agent will take on a typical task. If you can write them down, you do not need an agent — you need those steps.

What you should now be able to explain or do

Distinguish a function call, a chain and an agent by who decides the order. Ask the one question that separates a chain problem from an agent problem. Set autonomy and blast radius as separate dials and say what each grants. Design a deterministic workflow with a model step, plus routing and bounded loops. Compute the cost, latency and reliability multipliers of a loop before building. Apply the write-down-the-steps test.

Check yourself