Chapter 5 gave you four questions and the five classes they separate — assistant, RAG, text2SQL, workflow, agent. What it left you to work out on your own is the shape: which question comes first, which ones you never have to ask once an earlier answer has ruled them out, and what to say when the client asks why you picked that class and not one of the others. This chapter supplies both halves. The questions become a tree that ends every branch in one of the five before you have said a word back, and each ending comes with the argument for why the other four lose.
10.1 The tree
Start with who is on the hook for the next step.
- A request arrives
- Does a person read the output before anything happens, or does the system act on its own?
- A person reads it
- The system acts
If a person reads it, the very next question is the one RAG and text2SQL get tangled on most often, so ask it before anything else: is the answer already written down somewhere, is it a number nobody has computed yet, or is there no existing answer at all — just a document the person needs help producing?
- A person reads the output
- Is the answer written down, is it a number to compute, or does it need to be produced from scratch?
- Written somewhere → RAG
- A number from records → text2SQL
- Needs producing → assistant
If the system acts instead, the question that matters is whether the path ever changes.
- The system acts on its own
- Do the steps ever change depending on what's in the request?
- Never — workflow
- Depends on the request — agent
Three questions, five endpoints. Nothing on this tree asks what model powers it, how the vendor describes it, or how many systems it touches — those are implementation details that come after the class is settled, not before.
10.2 Why not the other four
Naming the right class is half the argument. The other half is being able to say, out loud, why the four you rejected were wrong — because that is the part a client actually tests you on.
RAG. Not text2SQL — the answer was decided by whoever wrote the policy, not by data anyone can aggregate, so there is no query that would produce it and no table it could come out of. Not assistant — treating this as a plain assistant task drops the retrieval step, and a model asked a factual question with no passages in front of it will produce something fluent and unsourced instead of saying it doesn’t know. Not agent — the job ends when the passage is handed over; nothing needs to happen in another system. Not workflow — the question changes every time, so there is no fixed sequence to lock in.
Text2SQL. Not RAG — no document anywhere contains this figure; it exists only once someone runs the aggregation. Not assistant — a plain assistant asked “how much did we sell last quarter” will estimate from whatever it can see and sound just as confident as a correct query. Not agent — there is no path to choose between; the system translates a question into one query and runs it. Not workflow — there’s no multi-step sequence to fix in place, just one translation step that has to tolerate however the question happens to be phrased.
Assistant. Not RAG — the person doesn’t want a fact retrieved, they want a draft, a comparison, an explanation built from scratch. Not text2SQL — the output is prose that has to be written, and no aggregation over any table produces a paragraph; the moment you scope this as a reporting question you have replaced the deliverable. Not agent — the person stays the one who decides and presses send; automating that decision is a different, riskier project nobody asked for yet. Not workflow — every draft, every contract, every email is different content going through a task that only looks repeatable from a distance.
Agent. Not assistant — the volume or the speed of the cases means nobody can realistically read every one and decide by hand; something has to act on its own. Not workflow — the path genuinely depends on what’s in the request, so forcing one fixed sequence produces the right action on some cases and the wrong one on the rest. Not RAG — a retrieval step may well happen along the way, but scoping the project as retrieval buys a system that hands a passage to a person who was never going to be in the loop. Not text2SQL — the number is an input to a decision nobody is waiting to read; delivering it and stopping leaves the whole job undone.
Workflow. Not agent — if the steps never vary, paying for a system that re-decides its path every single run buys latency, cost and a new way to fail, for a decision that was never actually in doubt. Not assistant — nobody needs to review each run individually once the sequence is known and safe to fire automatically. Not RAG or text2SQL — both end by producing an answer, and nobody here has asked a question; the deliverable is that three things happened in order, which no answer, however good, accomplishes.
10.3 The tree on six calls
A field technician asks the fault-code manual what a warning light means. A person reads it, the answer is written down in the manuals, nobody needs to compute anything. RAG.
A claims manager asks how much was paid out in a region last month. A person reads the answer, but no document contains that figure — it lives in the claims database and has to be summed. Text2SQL.
A recruiter asks for a first draft of a job posting from a rough set of requirements. A person reads it and will rewrite half of it, but there is no existing answer to retrieve and no number to compute — something new has to be produced. Assistant.
A logistics team wants delayed shipments handled without a human touching every one. The system itself has to notify the customer, rebook a carrier or escalate to a person, and which of those happens depends entirely on why the shipment is late. Agent.
A clinic wants every new patient sent the same three intake forms and a reminder two days later. The system acts on its own, and the sequence is identical for every patient regardless of what brought them in. Workflow.
A property manager asks, in the same call, what the lease says about early termination and how much rent the portfolio collected last quarter. Same person, same tone, two different projects: the lease question is text sitting in a document, so RAG; the rent question is a figure nobody has computed yet, so text2SQL. This is the fork from 10.1 arriving exactly as often as chapter 5 warned it would.
The tree tells you the shape, not the verdict
Everything above answers one question: what shape does this solution take? It does not answer whether the solution is worth building. A perfectly classed agent for a process that runs eleven times a year, or a correctly scoped RAG system over a knowledge base nobody actually consults, is still a wasted quarter — that verdict belongs to the questions in chapter 2, asked before this tree, not instead of it.
Run the tree, name the class, say why the other four lose — and then go back and check that the problem was worth solving in the first place. A right answer to the wrong question is still the wrong question.