When you need an agent, and when you do not

The previous chapter separated retrievers, workflows and agents. This one is the decision procedure, because choosing wrongly here is expensive and the pressure runs in one direction: agents demo better than they deploy.

Four questions, in order

1. Can you write down the steps?

Take the ten requests you expect most often and write the steps for each, in plain language, as if instructing a new hire.

If you can write them down, you have a workflow. Implement it as one. A model may still do the language-shaped parts — extracting a figure from a paragraph, classifying a request — but the sequence belongs in your code where you can read it, test it and fix it.

If you genuinely cannot write down the steps, because the path depends on what you find along the way, that is a real reason for an agent.

2. Does anything change?

Answering a question changes nothing. Drafting a quote, opening a ticket or sending an email changes something, and anything that changes something needs a different standard of care: confirmation, an audit trail, idempotency, and a way to undo.

Systems that only read are dramatically cheaper to build and to be wrong in. Be honest about whether you need the write side in version one.

3. How wrong can it afford to be?

Put a number on it. If the honest answer is "it must be right every time," you do not want a model making unsupervised decisions — you want a workflow with a model inside it, and a human on anything consequential.

A useful framing: what happens on the worst plausible wrong answer? If that is "someone is mildly annoyed," you have room. If it is "we ship to the wrong address," you need confirmation steps before you need cleverness.

4. Who is asking?

If every user may see everything, your life is much simpler. If different people may see different things — almost always true of company data — then permissions must be enforced during retrieval, not described in a prompt.

This question is here, near the start, deliberately. It is the one most often deferred, and it is the hardest to retrofit. We return to it in the data layer, and again when we build the guardrails.

The honest answer for most companies

The proportions vary. The shape rarely does. A system that treats all hundred as the fourth case is slower, costlier and less reliable at the seventy than a search box would have been.

Build the search box first. If it answers seventy percent of what people ask, you have delivered most of the value before writing a single tool definition — and you have the retrieval quality that everything else depends on.

Where the pressure comes from

It is worth naming, because it is not a technical force.

Agents are what everyone is talking about. "We built a very good internal search" is a harder sentence to say in a board meeting than "we deployed an AI agent," even when the first one describes the more useful system. If you are the engineer, expect to make this argument more than once, and expect to make it with numbers rather than taste.

The numbers that win it: cost per request, median latency, and the proportion of answers a human had to correct. Measure all three on a retriever first, and you will have a baseline that any agent proposal must beat.

What Atlas does with this

Atlas, introduced properly in chapter 5, routes on exactly these questions. Every incoming request is classified before anything expensive happens: can this be answered from documents, does it match a known workflow, or does it need the model to plan.

That router is itself a small model call, and it is the highest-leverage component in the system. We build it in section 3, once retrieval is good enough to be worth routing to.

Key points

• Write down the steps for your ten most common requests. If you can, build workflows.
• Reading is cheap and safe; writing needs confirmation, audit and idempotency.
• Put a number on how wrong it can afford to be, before choosing an architecture.
• Permissions are a retrieval concern, not a prompt concern. Decide early.
• Expect to defend the boring architecture. Bring cost, latency and correction rate.