An assistant that actually read your documentation,
and cites where an answer came from
Internal knowledge usually lives scattered across documents, chats and someone's memory. We build an assistant that answers from the real documents, cites where the answer came from, and respects who is allowed to see what.
An assistant that answers from your own documents
A knowledge base assistant answers questions from documents your organization already has: policies, onboarding material, past decisions, technical runbooks. It shows where each answer came from so a person can verify it. It fits any team where the same question gets asked repeatedly in a group chat, or where institutional knowledge lives in one person’s head and nowhere else. It is not a general chatbot. It is scoped tightly to your own documents, which is exactly why it can cite sources instead of guessing.
Retrieval, access control, and an easy edit
Documents get ingested and split into retrievable chunks, each tagged with its source. An answer always points back to where it came from, not a plausible-sounding paraphrase. Access control sits at the retrieval layer. A document tagged for one department never surfaces in an answer to someone outside it, enforced by the system, not by trusting the model to behave. The admin view lets whoever owns the documentation add, correct or retire a document directly, keeping the assistant current without a development request. Delivery happens wherever your team already talks: a Telegram group, Slack, or a simple web chat. An assistant nobody opens is not useful, no matter how well it answers.
Getting the source material right first
We start with an audit of what documentation actually exists and where it lives. The real work is less about the model and more about getting the source material into a state the model can answer from reliably. Documents get structured and indexed with citations wired in from the first version, tested against real questions your team already asks in chat. Access rules get mapped to whatever permission structure you already use, department, role, or a simple allow-list, and enforced at retrieval time. We launch against one document source first, then expand coverage once retrieval quality is proven. That beats ingesting everything at once and debugging answer quality across a moving target.
Stale answers and misrouted permissions
The real risk is a stale document cited as current fact. That is why versioning and a clear retirement workflow matter as much as the retrieval model itself. Access control is the other place to be careful. A misconfigured permission rule can either hide information from people who should see it, or worse, surface something it should not. We test this deliberately against real role combinations before launch, rather than trusting the access rules on paper. Query logs are worth reviewing regularly. They reveal documentation gaps your team did not know existed until someone asked and got a weak answer.
Timeline and price
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| MVP | from $1,800 | One document source, citations, web or Telegram front end | 4 to 5 weeks |
| Production | from $4,500 | Multiple sources, access control by role, admin view for document management | 6 to 8 weeks |
| Full control (handover-ready) | from $5,500 | Everything in Production, plus a full handover package: architecture docs, test suite, admin access audit, and a walkthrough so your own team or another vendor can run it without us | 8 to 9 weeks |
Running cost on top of the build is usually $20 to $70 a month in model and vector-store costs, depending on document volume and query frequency.
What stays yours
You own the document index, the access rules, the admin interface and the full source code, hosted on your own infrastructure. The handover package documents how the retrieval pipeline works, so your own team, or ours on a maintenance basis, can keep adding document sources after launch.
Related
Pairs with the AI support agent product when the same knowledge needs to reach customers as well as staff. See the RAG search product for the retrieval architecture underneath this page. For staff-facing use beyond Q&A, see the internal AI copilot. See the AI agents service page for the full range of agent builds. Real builds: the visa consulting centre support bots case study, whose admin bot edits a knowledge base live, and the SENET memory engine case study. Have documentation scattered across ten places and nobody who reads all of it? Get in touch.
FAQ
How much does a knowledge base assistant cost?
From $1,800 for a single-source assistant (one wiki or document set) with citations and a web or Telegram front end. A build with access control across departments and multiple document sources runs $4,500 to $7,500.
How long does it take?
Four to five weeks to launch against a reasonably organized document set. Messy or scattered documentation adds time upfront, since the ingestion and structuring step is what determines answer quality later.
What is the stack?
Python and FastAPI. A vector store, pgvector on PostgreSQL, or a dedicated vector database for larger corpora. Claude or GPT handle retrieval and answer generation, with citations tied back to source document IDs.
Who owns the assistant and the index?
You. The document index, the access rules and the code are yours, running on your own infrastructure. Nothing requires an ongoing subscription to a third party beyond the model API itself.
How does it handle outdated documents?
Documents are versioned. Retiring or replacing one updates the index immediately, so the assistant stops citing it. The admin view makes this a direct edit, not a request to a developer.