The knowledge assistant is the AI feature every team asks for first, and the one most often abandoned three months after launch. The reason is rarely the model. It is that "an assistant that knows our documents" describes three different products, and teams build the easy one while expecting the outcomes of the hard one.
This post separates the three, tells the story of one that failed and one that stuck, and ends with how we decide which to build.
Three products that look like one
Search with answers. A person has a question, the assistant finds the relevant passages and summarises them with citations. Value comes from time saved finding things. Failure looks like confident answers from outdated documents.
Guided decisions. A person is doing a task with rules: eligibility, policy interpretation, configuration. The assistant applies the documented rules to their case and shows its working. Value comes from consistency. Failure looks like a plausible answer to a case the rules do not cover.
Customer support. A customer asks, the assistant answers or hands off. Value comes from deflection and speed. Failure is public: a wrong answer to a customer is a complaint, sometimes a liability.
The one that was abandoned
We built an internal assistant over a company's policy and procedure library. Retrieval was good, citations were accurate, the pilot group liked it. Usage fell steadily from the second month. When we asked why, the answer was simple: the library was out of date, everyone knew it, and the assistant faithfully surfaced the outdated version. People went back to asking the colleague who knew the current rule.
The assistant did not fail. It exposed that the organisation had no process for keeping the source current. The fix was not technical. It was an owner for each document set and a review cadence, with the assistant flagging documents past their review date. Once the library was trustworthy, usage came back.
An assistant is only as trustworthy as the least maintained document it can find.
The one that stuck
For a services company, we built a guided-decision assistant for their quoting team. The rules were in a fifty-page pricing guide that new staff took months to learn. The assistant took a described job, found the applicable rules, and produced a draft quote with each line linked to the guide. Experienced staff used it to check edge cases. New staff used it to learn.
Two design decisions made the difference. First, the assistant refused when the job description did not match any documented rule, and said so, rather than guessing. Second, every quote was reviewed by a person before it went out, and corrections were logged against the guide, which surfaced where the guide itself was ambiguous.
Deciding which one to build
The decision comes from two questions: how current and complete is the source material, and what happens when the answer is wrong?
If the material is current and a wrong answer is cheap, search with answers is a fast win. If the material is complete and structured but a wrong answer is costly, build guided decisions with mandatory review. If the answers reach customers, start with the assistant drafting replies for an agent to send, and only let it answer directly for a narrow set of questions you have tested exhaustively.
Security and access, which are not the same thing
Two problems appear in every assistant project. The first is access: the assistant must never answer from a document the asker could not open themselves. This means permissions are enforced at retrieval time, per user, not by trusting the model to be discreet. The second is injection: documents can contain text that reads like instructions, and a model that treats document content as commands can be steered by whoever wrote the document. The content is data. The assistant's allowed actions are fixed by the system, not by anything it reads.
For customer-facing assistants there is a third: the assistant must not disclose internal material even when asked cleverly. That is a testing problem as much as a design problem, and it is why we build an adversarial test set before launch rather than after the first incident.
Using assistants purposefully
The assistant that stays in use is the one attached to a job someone already does, over material someone already maintains, with a person still accountable for the result. Everything else is a demo.
- Name the job the assistant supports and the person who does it.
- Check who owns the source documents and how often they are reviewed.
- Choose search, guided decision or support based on source quality and the cost of a wrong answer.
- Enforce document permissions at retrieval, per user.
- Keep a reviewer in the loop until the test set says otherwise.