Search Plus Context: the Intuition
Four pages in, Tessa's routine has a shape she can feel without being told. Find the pages that matter. Put them in the window. Ask the question against them. It is the same three moves whether the source is a contract, a policy folder, or a pile of reviews, and by now she does it without thinking.
That habit has a name, and the systems built on it are being sold to Waymark right now. This page connects the two, because the surprise is worth having: the thing engineers build to answer questions over thousands of documents is Tessa's habit, automated.
The Pattern, Named from Your Own Hands
Look back at what the chapter actually taught. The contract page was not about fitting 120 pages into a window; it was about locating three. The document pages were not about cramming; they were about choosing. Every one of them is the same move: retrieve, then ask — find the relevant text, supply it as context (Chapter 2), and put the question to what is now in view.
The skill was never "get everything in front of the model". It was "get the right thing in front of the model". That distinction is the whole chapter in one sentence, and it survives every change in how big windows get, because a bigger window does not make irrelevant material relevant.
Scaling the Find Step
Now make the pile bigger than any human can search. Waymark's policy folder holds hundreds of documents — supplier terms, refund rules, insurance notes, four years of amendments. No window holds that, and no coordinator wants to read it.
So put a search in front of the model. A question arrives; a search runs over the folder first and picks out the handful of passages that best match; only those passages go into the window; the model answers from them. The finding is done by software that is good at finding, and the explaining is done by the model, which is good at explaining. Tessa's two-step, with the first step automated.
Engineers call this RAG — retrieval-augmented generation, which unpacks exactly as it sounds: generation, augmented by retrieval. You now understand it, because you spent a chapter doing it by hand. How the search itself finds "matching" passages when the wording differs is a genuinely interesting mechanism, and it is where this book stops: that machinery is built, from zero, in Agentic AI from Scratch, Chapter 6.
Why Products Answer from Your Documents
This is also the explanation for a whole category of tools Tessa will be shown this year. The help desk that answers from your own manuals. The assistant that knows your company wiki. The support bot that quotes your refund policy correctly. None of them has a model that learned your company. Each of them runs a retrieval step before the model, invisibly, on every question.
It explains a behaviour people find odd, too. When one of these tools says "I could not find anything about that in your documents", it is not being unhelpful — it is being honest about a failed retrieval, which is exactly the fix for Chapter 3's inventions, built into a product. A tool that answers anyway is the one to worry about.
And it gives Tessa the right question to ask a vendor, which is worth more than any feature list: what does it retrieve, and can it show me the passages it used? A product that can point at its sources is one she can check. A product that cannot is asking for trust the machine underneath has not earned.
When the Fetch Goes Wrong
Think of a librarian who fetches three books before the expert answers your question. The expert may be excellent; the answer can still only be as good as the fetch. Bring the wrong three books and you get a confident, well-argued answer built on the wrong shelf.
That is the failure mode to carry forward. The model answers from what retrieval found. If the search surfaced the 2023 version of the cancellation policy instead of the current one, the answer will be fluent, well-organized, and out of date — and nothing in its tone will mark the difference, because tone never marks anything (Chapter 3).
Which is why the habit from earlier in this chapter survives at every scale: ask what the answer is based on, and read the passage yourself when the answer matters. Tessa does it by scrolling to a clause in her own copy. A product does it by showing you the retrieved passage with a link. Same check, same reason, twenty documents or twenty thousand.
That closes the chapter. Documents go in, by the door you choose and with a spot-check. Big documents get cut to the part that answers the question. The three verbs do the bulk of the work, numbers stay with a tool that computes, and the whole routine has a name that turns out to be the industry's. What comes back is still prose, though, and prose is where the next chapter starts: getting output you can actually use.
- "Retrieve-then-ask is an advanced technique for engineers." You have been doing it by hand for a whole chapter. The systems automate the finding step; the shape of the thing is the one you already use.
- "A document assistant has read the entire archive." For any single question it has read the handful of passages retrieval selected, and nothing else. The archive is searched, not memorized.
- "Retrieval fixes hallucination." It shrinks it, by grounding the answer in real text that was actually fetched. Fetch the wrong document and you get fluent wrongness from a real source.
- "If a tool cites a source, the answer must be right." A citation tells you which passage was used, not that it was read correctly. It makes checking possible, which is the point — and checking is still yours to do.
- One pattern explains a whole product category Tessa will be sold this year, and it hands her the question that separates the good ones from the rest: what does it retrieve, and can it show me?
- Her manual habit turns out to be the industry's architecture — which is this book's quiet argument, and the reason the chapters ahead can show you what is under the chat box without any of it feeling foreign.
Knowledge Check
What is the retrieve-then-ask pattern, in one line?
- Add the documents to the model, so it knows them from then on
- Find the relevant text, put it in the window, then ask about it
- Ask the question twice and compare the two answers you get back
- Put the whole archive in the window and let the model pick from it
A support tool answers questions from a folder of thousands of company documents. What happens on each question?
- The model learned the whole folder in advance and answers from memory
- Every document in the folder is loaded into the window before answering
- The folder is condensed into summaries, which the model reads
- A search runs first, and only the passages it selects go into the window
Why is "I could not find that in your documents" a good sign in such a tool?
- It reports a failed search instead of inventing an answer
- It proves the document is genuinely missing from the archive
- It shows the question was too long to fit inside the window
- It means a human will be given the question to answer next
The search surfaced an old version of the refund policy. What does the answer look like?
- Hedged, because the model notices the version is out of date and says so
- Broken, because a stale document cannot be read properly
- Fluent and well-organized, and wrong in the way the old policy was
- Correct anyway, since the answer came from a genuine document
You got correct