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.
What it is and who needs it
A knowledge base assistant answers questions from documents your organization already has, policies, onboarding material, past decisions, technical runbooks, and shows where each answer came from so a person can verify it. It is for 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.
What is inside
The documents are ingested and split into retrievable chunks, each tagged with its source so an answer always points back to where it came from, not just 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 is wherever your team already talks, a Telegram group, Slack, or a simple web chat, since an assistant nobody opens is not useful regardless of how well it answers.
How we build it
We start with an audit of what documentation actually exists and where it lives, since 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 the retrieval quality is proven, rather than ingesting everything at once and debugging answer quality across a moving target.
What to watch
The real risk is stale documents cited as current fact, which 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, so this gets tested deliberately against real role combinations before launch, not assumed to work from the access rules on paper. Query logs are worth reviewing regularly, since 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 $7,650 | 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 you own at the end
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, and 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 for 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, and 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.