← Journal

Field notes · Architecture · Oct 2026 · 3 min read

Two kinds of questions need two kinds of helpers

A question goes to a sorter. How-to questions go to the instruction book: search the guides, copy the exact lines, show the page. Questions about connections go to the map of connections: ask a checked question and let the computer write the numbers. If the sorter is unsure, it asks the person.
In one sentence: Some questions are answered by a book of instructions, and others by a map of connections, so a good assistant first works out which kind it was asked.

Think of a school library

If you ask "How do I do this science experiment?", the librarian points you to a book. If you ask "Which bus does each child in my class take?", you need a chart of connections: who goes with which bus.

People ask AI assistants both kinds of questions in the same chat. The assistant has to notice the difference. In AI, the part that decides this is called a router. We will call it the sorter.

Book questions: "how" and "what does it mean"

Examples: "How do I reset my password?" or "What changed in the new version?" The answer is written down in a guide. So the assistant searches the approved guides, finds the best pages, and shows the exact lines with the page they came from.

Map questions: "what is connected to what"

Examples: "Which computers are in Room 5, and how many are there?" This is a question about connections, like a map of a school. The answer is not in one page of a book. It comes from a database that holds the connections.

For these questions, use a ready-made, checked question to ask the database. Then let ordinary computer code write the answer. The AI may introduce the table, but it must never write a number or a name that came from the database. If the database says 14 computers, the AI must not say 12.

The sorter is the hard part

Knowing which kind of question was asked is the hardest step. A good sorter does four things:

  • It makes one quick AI call to decide which kind of question it is.
  • It has a simple back-up, a list of key words, for when the AI is not reachable.
  • When a name could mean several things, it shows the real choices and lets the person click. Like asking "Which Sam: Sam from class 5 or Sam from class 6?", instead of guessing.
  • When a question has two parts, it splits them and sends each part to the right helper.

What to do

  • Decide which questions your assistant must answer from documents, and which from a database of connections.
  • Build a sorter that picks the right helper, and asks the person when unsure.
  • Let code write every number and name that comes from a database.

The limits of this advice

  • Some questions need both helpers. Splitting them well takes testing.
  • A sorter can be wrong. That is why it must ask the person when it is unsure, and why you should test it with real questions.
  • A graph database is only worth building if you really have many connection questions. Many assistants only need documents.

Words explained

  • Router (the sorter): the part that decides which helper should answer.
  • Database: an organised store of facts, such as lists and tables.
  • Graph: a way to store connections, like a map of who is linked to what.
  • Retrieval: finding the right pages for a question.
  • Citation: showing where an answer came from.

For engineers

This section has the exact details. Everything above is the simple version of it.

  • Document questions. Combine meaning-based (dense) and word-based (sparse) search, re-rank the candidates, and answer with quotations and citations.
  • Relationship questions. Use fixed, reviewed, parameterised graph queries. Let code format the result. The model never writes a value that came from the database.
  • Router. One cheap classification call extracts the intent and any names, with a keyword fallback when the model is unreachable. Ambiguous names return real candidates for a click. Compound questions are split, one part per source.
  • Where it fits. This is the hybrid pattern from Chapters 10 and 16.

In the book

General engineering lessons from the author's own experience, with illustrative examples. They describe no particular company, product or customer and are the author's personal views. Disclaimers
Get new articles by email

The Architecture Brief: one useful engineering idea at a time. Unsubscribe any time. Prefer a feed reader? RSS.