An assistant that answers from your documents, and cites them.

The problem

The question is always a small one. What did we agree with this supplier about delivery windows. Which version of the method statement is current. Have we ever done a job like this in Tromso. What is the policy on weekend overtime. Each takes about four minutes to answer if you know where to look, and about forty if you do not. The published figure for information searching is 19% of the working week, or roughly nine hours.

It takes forty minutes not because the information is missing, but because it is in five systems with five search boxes and none of them searches the others. The contract is in a drive. The discussion about the contract is in a chat thread. The amendment is in an email. What actually happened is in the project tool. The one person who knows all four is in a meeting. So the question gets asked of a human instead, which is faster for the asker and considerably slower for the company.

Then somebody leaves, and it gets much worse. A long-serving employee is a working index of where everything is and why it is the way it is, and essentially none of that was ever written down, because writing it down was never anybody's job that particular week. The gap stays invisible for about a month. Then it surfaces as a run of decisions being made slightly wrong by people who had no way of knowing better.

The obvious fix is to hand everyone a general chatbot, and plenty of companies have. It is excellent at general knowledge and knows nothing whatsoever about you, so it will answer confidently about your overtime policy using somebody else's. The second obvious fix is the search box that came with your file storage, which finds documents whose title you could already have guessed. Both are missing the same thing: an answer, taken from your own material, with the source attached so a human can check it.

How it works

Six things happen between a question being typed and an answer appearing, and the sixth is the one that makes it trustworthy enough to use.

1. 01Your material is indexed where it already livesDocuments, drives, the wiki, the project tool, the ticket history, the code and whichever shared inboxes are in scope, read in place rather than copied into a new system nobody will maintain. Nothing is migrated. That is the difference between a knowledge base that is current in year two and the three abandoned ones most companies already have.
2. 02It is split and indexed in a way that survives being quotedDocuments are broken on their own structure rather than every thousand characters, so a clause comes back as a clause and a procedure step comes back with the step before it. This sounds like plumbing and is actually most of the quality: badly split material produces answers that are each individually plausible and collectively wrong, which is the worst failure mode available.
3. 03Permissions are carried through to the answerWhat somebody can be told is exactly what they could already open. The index holds the access rules alongside the content and the retrieval step filters before the model ever sees a word, rather than retrieving everything and asking the model to be discreet. A system that is trusted to be tactful about salary bands is not a system, it is a hope.
4. 04Live systems are read at the moment of askingSome questions are not about documents. What is the status of this order, is this customer in arrears, who is on call tonight. Those are queried live from the systems that hold them rather than from an index built last night, so the answer is true when it is read rather than true at three in the morning.
5. 05The answer is assembled, not retrievedA question whose answer lives across a contract, an email and a change note gets one answer that reconciles the three, including saying when they disagree with each other. That is the actual job. A search result that hands somebody six documents has given them the forty minutes back exactly as they were.
6. 06Every claim carries its source, and not knowing is an allowed answerEach statement links to the document, the page and the paragraph it came from, so checking takes a click rather than a search. Where the material does not contain an answer it says so and offers the nearest thing it did find, instead of producing something fluent. These two rules together are what make the difference between a tool people check and a tool people stop using after the second wrong answer.

What it's built from

Five pieces. The connectors are the part that varies most, because they are whatever your company actually keeps things in.

• Claude, for the reading and the answeringReads the retrieved material and writes the answer against it, with instructions that make abstaining a correct outcome rather than a failure. On the versions that have to run entirely inside your network this is swapped for an open-weight model on your own hardware, which costs some quality and buys the thing those companies actually need, which is that nothing leaves the building.
• Supabase, for the index and the permissionsPostgres with vector search, holding the chunked material, its embeddings, its source references and the access rules that travel with it. Row-level security is the reason the permission model is enforced in the database rather than in a prompt. It is self-hosted on infrastructure you control, in the EU or on your own metal.
• Notion, Drive, SharePoint, or wherever the documents areConnected and indexed in place, with changes picked up rather than requiring a reindex somebody has to remember. Most companies have two or three of these and one of them is a drive with eleven folders called final. Part of the build is deciding what is in scope, which is a more useful conversation than it sounds.
• Slack, for where the asking happensThe assistant answers where people already ask each other, which is the single biggest factor in whether it gets used at all. Teams works the same way, and there is a web interface for people who want one. A good assistant behind a link people have to remember is a good assistant nobody opens.
• GitHub, for the technical corpus and for the system itselfWhere a software company's real documentation lives, in the code, the pull request discussions and the issue history. It also holds this system's own configuration, so the prompts, the permission rules and the connectors are versioned and reviewable rather than being settings somebody changed once.

What it's worth

Do this with your own numbers rather than ours. It takes a minute, and it is the only version of it worth believing.

• You have 25 people and the published figure holds that about 19% of the week goes on finding information.Roughly nine hours each a week, which is around four and a half full-time people doing nothing but looking things up. That is the number this system is aimed at, not the chatbot novelty.
• A quarter of that searching is for things the company definitely already knows and has written down somewhere.About two and a quarter hours a person a week that is pure retrieval, with no judgement in it at all. Retrieval is the part a machine is genuinely better at.
• Six times a day somebody interrupts a colleague to ask a question that has a documented answer.That is two people stopped, not one, plus the reorientation afterwards. The interruption cost is usually larger than the search cost and it never appears in anybody's estimate.
• One experienced person leaves this year.The handover document covers the parts they thought to mention. An indexed corpus covers the parts they did not, which are most of them, and it is worth building before the resignation rather than during the notice period.

These are illustrations using published averages and round numbers, not results we are reporting. Your headcount, how much is written down and how scattered it is will move every line, and the first thing the build does is find out how much of your material is actually answerable.

The research behind those assumptions

These come from one landmark study of how interaction workers spend a week. It is old enough to predate every tool in the list above, which is slightly the point: the proportions have not moved.

• 19%of the working week goes on searching for and gathering information, around nine hours. McKinsey Global Institute, The Social Economy
• 28%goes on reading and answering email, which is where a great deal of the answerable material is also buried. McKinsey Global Institute, The Social Economy
• 30-35%of that information search time could be repurposed if the material were searchable in one place, on the same study's estimate. McKinsey Global Institute, The Social Economy
• 20-25%is the productivity improvement the study attributes to making internal communication and knowledge properly searchable. McKinsey Global Institute, The Social Economy

What it costs

This is an advanced system rather than an automation, so it is quoted from that panel on the services deck. What moves it is the corpus and the permission model rather than the number of people using it. The bottom of the range is one or two document sources, a flat permission model and a cloud model. It climbs with every additional connector, with permissions that genuinely differ by team, and most of all with the requirement that nothing leaves your network, because that version has to run on hardware somebody has to specify, buy and keep running.

The running cost has two shapes depending on which version you take. On the cloud model it is a per-question cost in fractions of a cent plus a small hosting line, so it scales with use. On the fully private version it is the hardware and the electricity, which is a fixed cost that does not care how many questions get asked. For a company with a reason to keep everything inside, the second shape is usually also the cheaper one past a certain volume.

Outside the build price is somebody watching it, which is the care retainer, and on this system it is not optional in the way it very nearly is elsewhere. The corpus changes every week. An assistant quietly answering from a policy that was superseded in March is worse than having no assistant at all, because by then everybody has stopped checking.

What goes wrong, and what happens then

Every one of these is in the build because it happens, not because somebody raised it once in a workshop.

• It answers confidently and is wrongThe one failure that ends adoption, so three things work against it: every claim carries a link to its source, not knowing is an explicitly allowed answer, and answers are generated only from retrieved material rather than from the model's general knowledge. Wrong answers are reported with one click and reviewed weekly.
• Somebody asks about a salary they should not seePermissions are applied at retrieval, before the model sees anything, so the material is not in the answer because it was never in the context. The assistant can say that something exists and they cannot see it, which is better than pretending it does not exist, and that behaviour is a choice you make during the build.
• Two documents disagreeIt says so and shows both, with dates, rather than silently picking the one that retrieved better. Finding contradictions is one of the genuinely useful side effects of indexing everything, and a system that hides them is actively harmful.
• The policy was updated this morningChanges are picked up incrementally rather than on a monthly reindex, and documents carry their dates into the answer so a reader can see how fresh the source is. Supersession is explicit where your document structure supports it.
• A question is really about live dataRouted to the system that holds it rather than answered from an index that was built overnight. Order status, stock, arrears and who is on call are read at the moment of asking, because an index is the wrong shape for a fact that changes hourly.
• Nobody uses it after week threeThe usual outcome for internal tools, and it is a design problem rather than a people problem. It lives where the asking already happens, it answers in one message rather than linking to six documents, and the questions it could not answer are reviewed weekly, because those are the map of what is missing from the corpus.
• The scanned material is unsearchableOld contracts and site paperwork are frequently images rather than text. Those are read into text during indexing, and anything that cannot be read reliably is listed rather than silently skipped, so you know what the system is blind to instead of assuming it saw everything.