Enterprise knowledge assistant: a build guide over Drive, Slack and wikis

An enterprise knowledge assistant is an internal AI assistant that answers staff questions from the documents the company already has: Google Drive or SharePoint, Slack or Teams, Confluence or Notion, and the ticketing system. Done properly it ingests each source with its permissions intact, refreshes when documents change, and answers with citations a person can click. Done badly it is a chatbot over a pile of exported PDFs that leaks the finance folder to an intern. The difference is engineering, and this guide sets out the layers in the order we build them.

The work fits the Retrieval & Knowledge Engineering service, and most of what follows is the practical version of the failures described in why basic RAG fails in production, applied to the specific sources an office runs on.

What an enterprise knowledge assistant is, and why the sources decide the design

A company knowledge base AI is not one corpus. Drive holds long, structured documents with folder-level sharing. Slack holds short, threaded, conversational messages where the answer is often three replies down and the channel membership is the permission. Wikis hold curated pages with page-level restrictions and a lot of stale content. Tickets hold problem-and-resolution pairs with customer data mixed in. Each source needs its own connector, its own chunking, its own permission mapping and its own refresh cadence. A single ingestion script cannot serve all four.

Layer 1: connectors that respect the source's permissions

The connector is where most assistants go wrong, because it is tempting to authenticate as an admin, pull everything, and sort out access later. Later never arrives. The right pattern is to pull content and its access-control list together, store both, and treat the ACL as part of the document. For Drive that means recording every principal (user, group, domain, anyone-with-link) on each file and resolving group membership through the directory. For Slack it means indexing only public channels by default and treating channel membership as the entitlement for any private channel you deliberately add. The Slack API documentation is explicit about scopes, and requesting the minimum is a design decision, not just a security one.

Store the source's native identifiers so a change in the source can be mapped back to the chunks it affects. This is what makes incremental refresh possible.

Layer 2: permission-aware retrieval, enforced in the query

Every query carries the identity of the person asking. Before ranking, the retriever filters to chunks whose ACL includes that person or one of their groups. This filter runs in the database, never in the prompt. A model that is told "only use documents the user may see" will sometimes comply and sometimes not; a WHERE clause always complies. We test this with negative cases: user X asks a question whose only answer is in a document X cannot see, and the assistant must say it found nothing.

Two details catch people out. Group membership changes, so entitlements must be resolved at query time or refreshed frequently, not frozen at index time. And a document that is later restricted must have its chunks re-scoped or removed immediately, which means the refresh pipeline must handle permission changes as well as content changes. The design is covered in more depth in permission-aware retrieval.

Layer 3: refresh on change, with versions

Staff trust an assistant that knows the policy changed on Tuesday. Drive and Slack both offer change notifications; wikis usually offer webhooks; helpdesks emit events on ticket updates. Subscribe to these for near-real-time refresh and run a nightly reconciliation to catch anything missed. Give each chunk the version of the document it came from, show the version date in citations, and keep the previous version queryable for a short period so an answer given last week can be reproduced in an audit.

Layer 4: hybrid retrieval and re-ranking

Office questions are full of exact tokens: a project codename, a ticket number, a colleague's name, an internal acronym. Pure vector search treats these as vaguely similar to everything and returns the wrong page. Combine keyword search with vector search, merge the candidates, and pass them through a re-ranker that scores each against the actual question. This is the single largest relevance gain most assistants can make, and it applies equally whether the store is pgvector or a dedicated vector database; the choice of store is discussed in pgvector vs Pinecone vs Qdrant.

Layer 5: answers with citations and an honest "not found"

The answering layer composes a response only from the retrieved passages, cites each one with a link back to the source (the Drive file, the Slack permalink, the wiki page) and states when nothing relevant was found. The citation is not decoration: it is how a person checks the answer in ten seconds, and it is how a wrong answer gets reported with enough context to fix. Design the response so the citation is visible without scrolling and the source opens in one click.

Where the assistant lives: Slack knowledge bot, browser or both

A Slack knowledge bot meets people where they already ask questions, and channel context can be passed as part of the query. A browser or intranet interface suits longer answers, document previews and follow-up filters. Most deployments start in Slack or Teams because adoption is faster, then add a web surface for the search-heavy users. Whichever you choose, log the question, the retrieved passages, the answer and the feedback so the eval set grows from real use. The pattern is close to the in-app copilot work we do inside products.

Evaluation: the golden set and the three numbers

Before tuning anything, collect one to three hundred real questions staff have actually asked, with the passage that answers each and the person who asked (so permissions can be tested). Measure retrieval recall, precision and answer groundedness on every change. Add a fourth check for this use case: the permission test above, which must be zero failures. Without this set every improvement is an opinion. The full method is in how to measure RAG quality.

A worked example

A professional-services firm with a few hundred staff wanted an internal assistant over Drive, Confluence and their helpdesk. The first prototype, built internally, used an admin export of Drive and answered well in the demo. In review it surfaced a partner-compensation spreadsheet to a junior analyst, and it did not know that the leave policy had been rewritten a month earlier.

The rebuild started with the permission model: Drive ACLs and Confluence restrictions stored on every chunk, group membership resolved at query time. Slack was added later with public channels only. Change notifications drove refresh, and citations showed the document's last-modified date. Hybrid search caught the client codenames that vector-only retrieval had missed. The assistant launched in Slack, and the questions it could not answer were fed back to the wiki owners as a gap list, which improved the wiki as much as the assistant. The shape is the same one we used in the in-app copilot case study, pointed inward instead of at customers.

Team and timeline

A typical build is a retrieval-focused AI engineer, a data engineer for connectors and refresh, and an architect for the permission model, over six to ten weeks. Weeks one and two: corpus audit, permission model signed off, golden set collected, first connector. Weeks three to six: remaining connectors, chunking per source, hybrid retrieval tuned against the golden set. Weeks seven to ten: refresh pipelines, citations, the Slack or web surface, observability and the permission test suite. The Retrieval & Knowledge Engineering service starts at $14,000 / ₹8.8L; a three-week ProofRun at $6,250–10,500 is the right first step when the corpus is messy or the permission model is unclear. Current figures are on the pricing page, and clients own the connectors, index and eval set.

Before you start: a checklist

• List every source, its owner, its permission model and how often it changes
• Decide which Slack channels are in scope; exclude DMs and private channels by default
• Get the permission model signed off by security before writing a connector
• Collect 100–300 real questions with source passages and the asker's role
• Plan refresh per source: events where available, nightly reconcile everywhere
• Decide where citations link and how a wrong answer gets reported
• Choose the surface (Slack, Teams, browser) based on where questions are asked today
• Put recall, precision, groundedness and permission failures on a dashboard

Questions clients ask

• Can it answer from Slack threads? Yes, if threads are indexed as units with the parent message as context and channel membership is the entitlement.
• Will it leak documents? Not if permissions are enforced in the retrieval query and tested with negative cases; it will if they are enforced in the prompt.
• Does it need a dedicated vector database? Usually not at a few hundred thousand chunks; pgvector inside Postgres is the default.
• How does it stay current? Change notifications plus a nightly reconcile, with versions shown in citations.

Related reading

See why basic RAG fails in production for the engineering behind each layer, chunking strategies for RAG for how each source should be split, and hybrid search for why keyword matching still matters.

Build the permission model first, the connectors second and the model choice last, and the assistant will be one staff trust rather than one security switches off.