An assistant that has read everything you have

Every business that has been running for more than a few years is sitting on an archive nobody can use. Policies, contracts, product specifications, past quotes, handover notes, the email thread where a decision was actually made. It is all there, and finding anything in it means asking the one person who remembers.

A knowledge assistant makes that archive answerable. You ask a question in plain language, it retrieves the passages that actually bear on it, and it answers from those with a link back to the source so you can check it. The citation is not a nice extra. It is the thing that makes the answer usable in a business where being wrong has consequences.

Who this is for

• Teams answering the same questions repeatedly (support, reception, sales) where the answer exists in writing but nobody can find it fast enough.
• Regulated or technical businesses where the answer must be traceable to a document, not to a model's general impression.
• Companies whose data cannot leave the building, or cannot leave Europe.

What it actually does

Ingests what you have. PDFs, Word documents, spreadsheets, wiki pages, a shared drive, a website. Including the scanned ones, via OCR, with a confidence check so an unreadable page is flagged rather than silently mangled.

Retrieves before it answers. The question is used to find the passages most likely to contain the answer, and only those go to the model. This is what keeps it accurate, and it is where most of the engineering effort goes.

Cites its sources. Every answer links to the document and section it came from. Staff learn quickly which answers to trust and which to check, and that trust is earned rather than assumed.

Says when it doesn't know. The most valuable behaviour and the hardest to get consistently. An assistant that confidently invents a policy is worse than no assistant.

Respects your permissions. Retrieval is filtered by who is asking, before the model sees anything.

What a build looks like

• An ingestion pipeline that can be re-run, so the assistant stays current as documents change.
• A retrieval layer tuned against your actual questions, not a generic benchmark.
• A chat interface: on your site, in Slack or Teams, or inside a tool your staff already use.
• An evaluation set built from real questions, so we can show you where it is strong and where it is not.
• An admin view: what people asked, what it answered, what it got wrong.
• Hosting on your infrastructure, in European cloud, or wherever the data requires.

That last log is worth as much as the assistant. Within a fortnight you will know exactly what your customers and staff are actually asking, which is usually not what anyone assumed.

Where the data goes

This is the solution where the transfer question bites hardest, because you are deliberately feeding it your most sensitive material. We start from what the data actually is. Public product documentation can go to a managed European API without much ceremony. Patient records, legal files or anything under professional confidentiality often should not leave infrastructure you control, and we will build it that way instead, with the cost and capability trade-off explained before you decide, not after.

What shapes the cost

• How much material there is, and what condition it's in. Ten thousand clean HTML pages is easier than two hundred scanned PDFs.
• Whether permissions matter. One shared corpus is simple. Per-user filtering that mirrors your existing access rules is real work.
• Where it has to run. A managed API is fastest to ship; self-hosting adds infrastructure and ongoing operations.
• How wrong it's allowed to be. An internal helper for staff who know the domain needs less evaluation than something answering customers unsupervised.
• How many places it needs to appear: website, Slack, an internal tool.

Tell us what questions you want it to answer and where the answers currently live, and we will come back with a written scope, a fixed price and a date, at no charge.

Frequently asked questions

How is this different from just using ChatGPT? A general model knows the internet but not your pricing, your policies or last year's contracts. A knowledge assistant retrieves the relevant passages from your own material first and answers from those, with a link to the source. The difference is not intelligence, it is grounding: one guesses plausibly, the other shows you where it got that.

What stops it from making things up? Three things, and none of them is a promise that it never will. Retrieval so it has the right passage in front of it, citations so a wrong answer is immediately checkable, and an explicit instruction to say it does not know rather than fill the gap. We also build an evaluation set from your real questions and measure against it, so quality is something we can show you rather than assert.

Can it run entirely on our own infrastructure? Yes. Open-weight models have been production-viable for a while now, and for anything covered by professional confidentiality or health data it is often the cleanest answer to the transfer question. It costs more to run and is a little behind the frontier on the hardest reasoning, which we will be straight with you about before you commit.

How much of our documentation needs to be tidy first? Less than people fear, but not none. Scanned PDFs, inconsistent formatting and duplicated policies all degrade retrieval, and a large part of a good build is the ingestion pipeline that cleans and structures them. Where we find genuinely contradictory documents we flag them rather than quietly picking one.

Who can see what? Whatever your existing permissions say. An assistant that ignores access control is a data breach with a friendly interface, so retrieval is filtered by the user's own permissions before anything reaches the model. Someone in reception asking about a salary policy gets what reception is allowed to see.