What it is for, and the honest boundary
It answers questions your team currently brings to you, from documents your business already has. How does the onboarding process work, what is our policy on discounts, what did we agree with this client about scope, what is the standard for this deliverable.
The boundary worth stating plainly: it can only answer what has been written down. An assistant over an undocumented business retrieves nothing and produces confident generalities, which is worse than no assistant, because the generalities are plausible.
So this is not a substitute for documentation. It is a multiplier on documentation that exists — and it is a good multiplier, because the reason written material goes unused is usually that nobody can find the right paragraph, not that it does not exist.
It also changes the economics of writing things down, which is the underrated effect. Once the assistant exists, an answer written once becomes findable forever, and the third-time rule — the third time you explain something, the explanation is the artifact — starts paying immediately rather than eventually.
A second boundary: it answers, it does not act. Retrieval over documentation is a well-understood problem with a checkable output. An assistant that also takes actions in your systems is a different build with a different risk profile, and fusing the two at launch means the trust problem from one contaminates the other.
The architecture, part one: the corpus
Stage one is source selection, and being narrow at the start is what makes it work. Process documentation, decision records, standards, and client-specific agreements. Explicitly excluded at launch: general chat history, draft documents, and anything superseded. A corpus assembled by pointing at everything produces an assistant that confidently cites a rejected proposal from 2024.
Stage two is the authority marking, and it is the stage most builds skip. Each source carries a state: current, superseded, or draft. Only current sources are retrieved by default. Without this the assistant has no way to distinguish the policy from a document that describes an old version of it, and neither do you.
Stage three is ingestion and indexing, triggered by a document being marked current. Chunked, embedded, indexed, with the source identity and last-updated date preserved through to retrieval so they can be shown in the answer.
Stage four is the freshness rule. Documents older than a defined age are flagged in the answer rather than silently trusted — a citation that says this document was last updated eighteen months ago is doing important work, because it tells the reader how much to lean on it.
The architecture, part two: retrieval, citation and the gap log
Stage five is retrieval, triggered by a question in whatever surface the team already uses — most usefully the chat tool they are in all day, because an assistant that requires visiting a separate application competes with asking a colleague and loses.
Stage six is generation with a hard constraint: answer only from retrieved material, and if nothing relevant was retrieved, say so. The refusal path is the most important behaviour in the system. An assistant that says I do not have documentation on this is useful; one that improvises is a liability, and the difference is a prompt constraint plus a retrieval confidence threshold.
Stage seven is the citation, shown with every answer: which documents, and when each was last updated. Non-negotiable, for both the verification reason and the corpus-maintenance reason.
Stage eight is the gap log, and it is the highest-value output of the whole system. Every question that retrieved nothing is recorded. That log is a ranked list of what your business has not written down, ordered by how often somebody needed it — which is a documentation roadmap that nobody had to guess at.
Stage nine is the correction loop. When somebody sees a wrong answer, one action flags it, and the flag routes to the owner of the cited document. That turns each error into a documentation fix rather than into a reason to distrust the tool.
The failure edges
The first: no citations. Answers become unverifiable, one confident error destroys trust, and the team reverts to asking the founder — which is the exact behaviour the system was built to remove.
The second: an indiscriminate corpus. Point it at every document in the business and it will retrieve superseded processes and rejected drafts with the same confidence as current policy.
The third: no refusal path. An assistant that always answers will answer questions it has no basis for, and the answers will be plausible, which is the worst combination available.
The fourth: building it over a business with nothing written down. The retrieval finds nothing, the answers are generic, and the conclusion is that the technology does not work. The technology is fine; there was no corpus.
The fifth: no gap log. Without it you lose the single most valuable byproduct, which is a ranked, evidence-based list of what to document next.
The sixth: no ownership of the corpus. Documents drift out of date, nobody marks them superseded, and within a year the assistant is a fast route to stale information — which is more dangerous than a slow route to it.
The seventh: measuring adoption instead of outcome. Query volume rising is not success — it can equally mean the answers are unhelpful and people are rephrasing. The number that matters is whether questions reaching the founder went down.
The surface, and the measurement that justifies it
The surface has to be the tool the team is already in all day, because the assistant is competing with asking a colleague and asking a colleague costs nothing. In practice that means Slack, with the assistant available in a channel and by direct message — a separate web application loses that competition even when it is better, because opening it is a decision.
Permissions need thinking about before launch rather than after. Client-specific agreements and commercial documents should not be uniformly retrievable by everyone, which means the corpus carries an access level and retrieval respects it. This is easy to build at the start and awkward to retrofit once the index exists.
Measure two things or you will not know whether it worked. Question volume reaching the founder, sampled before and after — that is the outcome the system exists for. And the answered rate: what proportion of questions retrieved something usable. A rising answered rate over two quarters means the gap log is being worked, which is the actual mechanism by which this compounds.
What done looks like, and what it takes to build
Done is a measurable drop in questions reaching the founder, answers that cite their sources with dates, and a gap log that tells you what to write next.
The checklist: a narrow curated corpus; a current, superseded and draft state on every source; ingestion triggered by the current marking; retrieval in the tool the team already uses; a refusal path with a confidence threshold; citations with last-updated dates on every answer; a gap log of unanswered questions; and a one-action correction flag routing to the document owner.
The build is two to three weeks. The retrieval is the straightforward part; curating the corpus and establishing the authority states is the work, and it is the part that determines whether the thing is trusted in month three.
The honest prerequisite: enough written material to be worth retrieving over. If the answer to most questions is that it lives in the founder's head, build the documentation habit first — the third-time rule costs nothing — and the assistant becomes worth building about a quarter later.
Cite every answer with its source and date, and log every question that retrieved nothing. The citation makes answers verifiable; the gap log tells you what to document next.