Customer conversations
Making an AI assistant admit it does not know.
Building an assistant that answers only from approved material and refuses the rest — and turning those refusals into a to-do list written by your customers.
The problem
DockAI
Every organization that put a general-purpose assistant in front of customers found the same thing in the same week: fluent, confident, and on the questions that mattered, making things up.
A model has no internal signal separating 'I retrieved this' from 'this sounds like the kind of thing that would be true', and the output looks identical either way. The customer cannot tell. The organization finds out downstream.
So the problem was never making an assistant answer. It was making it refuse.
The constraints
Fixed before anything was drawn.
Not requirements, which move. These are the facts of the problem that no amount of engineering was going to change, and every decision downstream had to survive them.
Refusal cannot be achieved by asking
'Only answer from the provided context' works most of the time. Most of the time means the failure is rare, therefore unmonitored, therefore first found by a customer.
Every answer must be traceable to a passage
If the system cannot point at what it used, there is no way to audit it and no way to improve it.
Acting wrongly costs more than answering wrongly
An assistant with tools can move money. A persuasive conversation must not be able to collapse the distinction between reading an order and refunding one.
The customer must never repeat themselves at handover
Failing to a human who opens with 'how can I help you today' wastes the customer's time twice.
The architecture
What the constraints forced.
No path from ungrounded question to answer
Retrieval runs first. If nothing clears the relevance bar, the generation step is not reached — the path does not exist, rather than the model having been asked not to take it.
Chunk on the document's structure, not a token count
Fixed-size chunking cuts a policy in half and produces two individually irrelevant passages. Chunks follow the document's own structure and carry their heading path, so a fragment knows what it is a fragment of.
Retrieve wider than you generate
The relevance threshold becomes an explicit decision with a real cost, tuned per deployment against questions with known answers.
Tools split by consequence
Permissioned individually, and anything a customer cannot reverse routes to a person.
Handover carries the work
The person receives the conversation, the retrieved passages, and what the assistant already tried.
The decisions
Each one cost something.
A decision presented without its cost is a decision nobody had to make. These are the ones we would defend, and what we gave up to take them.
Enforce grounding in the architecture, not the prompt
A prompt is a request. On the failure that matters, a request is not a control.
The trade-off
The assistant refuses more than a competitor's, and in a side-by-side demo that reads as weaker until you check the answers.
Tune the relevance threshold per deployment
How often an organization would rather say nothing than risk being wrong is their decision, not a default we should make for them.
The trade-off
It is real work with a real evaluation set, and it means deployment is not instant. We say so during scoping.
Report every refusal back to the organization
An unanswerable question is either a documentation hole or an unmade scope decision. Both are actionable.
The trade-off
It surfaces uncomfortable things about a knowledge base that nobody asked to be told.
Where it stands
The platform is built and running: grounded answers with citations, structural refusal, permissioned actions, and handover that carries the full context.
The unexpected result is that the refusals turned out to be the most valuable output — a to-do list for a knowledge base, written by customers. Organizations act on that in a way they never act on a content audit.
We build systems like this for other organizations.
DockAI exists because we met the same operational failure enough times to engineer it properly. Yours is probably a different failure. That is the conversation we want, and you will have it with an engineer.