Chapter 1 · Foundations
What an agent actually is
The word covers three different things, and most disappointing projects are a team building one while expecting another. Here is how to tell them apart.
4 min read
"Agent" is doing a lot of work in most conversations. Before you design anything, it helps to separate the three systems people mean when they use the word, because they have different costs, different failure modes, and different reasons to exist.
The three things people mean
A retriever
You ask a question, the system finds relevant text, and a model writes an answer grounded in that text. Nothing changes in the world. This is what most "chat with your documents" products are.
It is the cheapest of the three, the easiest to evaluate, and it solves more real problems than its reputation suggests. A great many requests that arrive described as "we need an AI agent" are satisfied completely by a good retriever.
A workflow
A fixed sequence of steps, some of which call a model. Read the invoice, extract the line items, match them against the purchase order, flag the differences. The path is decided by you, in code. The model does the parts that need judgment about language.
A workflow is predictable, testable with ordinary methods, and debuggable by reading a stack trace. When the steps are known in advance, this is almost always the right answer.
An agent
The model decides what to do next. You give it a goal and a set of tools, and it chooses which tools to call, in what order, and when it is finished. The control flow is not in your code — it emerges at runtime.
That is the actual distinction, and it is worth being precise about:
A workflow is a program that calls a model. An agent is a model that calls your program.
Everything difficult about agents follows from that inversion. You can no longer read the code to know what will happen.
Why the distinction decides your architecture
The right-hand path costs more in every dimension. More tokens, because the model reasons about what to do before doing it. More latency, because it may take several turns. More engineering, because an unpredictable system needs evaluation and guardrails that a predictable one does not.
That cost buys one thing: the ability to handle requests you did not anticipate. If you can anticipate them, do not pay for it.
Atlas is all three
The assistant we build across this series is not one of the three. It is a retriever for most questions, a set of workflows for the common requests, and an agent only where the path genuinely cannot be known in advance.
A realistic breakdown of what people will ask it:
| What someone asks | What should handle it |
|---|---|
| "What is our returns policy for damaged goods?" | Retriever |
| "How many units of SKU-4411 are in the Dallas warehouse?" | Workflow — one database query |
| "Draft a quote for the Henderson order at the usual discount" | Workflow — lookup, calculate, template |
| "Why is the Henderson account past due and what should I do?" | Agent — it must look at several places and decide |
Most teams build the fourth row first, because it demos well. Then the first three rows arrive through it, cost ten times what they should, and occasionally get a creative answer to a question with one correct answer.
Build the cheap paths first and route to the expensive one only when you must. This is the single decision that most affects what the thing costs to run.
What this means for the series
We build in that order. A retriever that works comes first, because retrieval quality sets the ceiling on everything above it — an agent reasoning over the wrong documents is just a slower way to be wrong. Tools come next, then the loop that chooses between them.
That ordering is also why the next chapter is about deciding you need an agent at all, and why we do not write one until the foundations under it are measurable.
Key points
- A workflow is a program that calls a model; an agent is a model that calls your program.
- The inversion of control is the source of every difficulty, and the only thing you are buying.
- Most systems should be a retriever and some workflows, with an agent at the edges.
- Route cheap requests to cheap paths. It is the biggest lever on running cost.