AI knowledge base for business: should a 20-50 person company buy one or build one?

What is an AI knowledge base, and how is it different from a wiki or a search box?

Three different machines get confused for each other. A wiki is a place people write things down. A search box returns a list of files and leaves the reading to you. An AI knowledge base answers the question in sentences and shows you the passage it took the answer from.

The mechanical difference is grounding. Your content gets ingested, split into passages, indexed for both keyword and semantic matching, filtered against your permissions, and only then handed to a model that is instructed to answer from those passages and nothing else. A good one says "I don't have that" when the answer genuinely isn't in your corpus. A chatbot bolted onto a wiki says something confident instead.

You will see the same product sold under several names: AI knowledge base, AI-powered knowledge base, enterprise AI search, and the framing we use elsewhere on this site, a second brain for a business. Vendors pick whichever word their buyer types. Underneath, they are all doing retrieval over your content.

A wiki stores answers, a search box finds files, and an AI knowledge base answers the question and shows its receipt.

Do you actually need one at 20-50 people?

Run one test before you shop. Write down the last ten questions someone asked inside your company, the real ones about a pricing exception or a client's history or why a decision went the way it did. Then mark how many were answered by interrupting a specific person. If it's two, you have a documentation habit and you don't need software. If it's seven, the knowledge is in people, not in systems, and that is what an AI knowledge base is for.

Three events reliably tip a company at this size into buying: someone senior left and took context with them, onboarding a new hire eats a week of a manager's time, or support and sales are opening five tools to answer one customer. Absent one of those, wait.

The trigger isn't document count, it's how often a human is the only index.

Should you buy an off-the-shelf AI knowledge base or have one built?

Buy, unless one specific thing is true. The decision rule we use on discovery calls: list every system that holds knowledge you would want answered from, then check which of them the tool connects to. If the list is covered, buy seats and stop reading. If the single most valuable source is your internal admin tool, your practice management system, or a database somebody built in 2019, no vendor is going to add that connector for a 35-seat account.

Pricing and product details checked against each vendor's own pages on 23 August 2026: notion.com/pricing, dashworks.ai/pricing, getguru.com/pricing, glean.com/pricing. Vendors change prices; re-check before you sign anything.

If everything you know lives in Slack, Drive and Notion, buy a tool and don't hire an agency. That includes us.

What does it cost, buy versus build?

Do the per-seat arithmetic before anything else, because it is the number that decides most of these. Thirty-five people on a $12 seat is $420 a month, roughly $5,000 a year, and it goes up every time you hire. A custom build is a fixed fee from around $8,000 for a first production scope, then infrastructure and model usage rather than licences. Year one, buying wins at this headcount. It usually takes until year two or three, or a doubling of headcount, before the maths flips.

The number nobody quotes you is the run cost of the thing you built. Embeddings on re-index, inference per question, and any scheduled job you forgot to bound. We watched this go badly on an adjacent project: a 20-50 person company gave every employee an always-on personal agent with its own token budget, spend hit roughly $3,000-$5,000 a month, and the programme was dead inside two months. That was an agent rollout rather than a knowledge base, but the mechanism transfers exactly. Idle loops and unbounded re-indexing bill you whether anyone asks a question or not.

So set a monthly ceiling and an alert on day one, cache aggressively, and route the cheap retrieval-only queries to a cheap model. This is boring and it is the difference between a $70 month and a $700 one.

Buying is a subscription that grows with headcount; building is a capital cost plus a usage bill you have to actively cap.

Why do AI knowledge base answers come back wrong, and what fixes it?

Almost always because retrieval failed, not because the model made something up. Barnett and colleagues catalogued seven distinct failure points in production RAG systems across three real deployments (Barnett et al., 2024), and several of them happen before the model writes a single word. The content was never captured. The right document ranked too low. The passage got cut off. The answer was in a table whose header was split away during chunking.

Four specific failures account for most of what we get called in to fix. Employees ask using internal acronyms and product codenames, and pure vector search misses exact strings, which is why hybrid keyword-plus-vector retrieval keeps winning in systematic RAG benchmarking (Wang et al., 2024). Tables and spreadsheets get chunked away from their headers, so a price appears with no label. Scanned PDFs never got OCR'd and are invisible. And the outdated policy outranks the current one because it is longer and better written.

None of that is fixed by a better model. It is fixed by an evaluation set: thirty real questions your team asked last month, with the correct source document written next to each one, run against the system every time anything changes. That paper's own conclusion is blunt about it, that validation of a RAG system is only feasible during operation.

If a vendor cannot show you retrieval quality on your own thirty questions, you are buying a demo.

How do permissions work, and can it show the salary doc to an intern?

It can, if permissions are asked for in a prompt instead of enforced at retrieval. Instructing a model to "only answer HR questions for HR staff" is not access control; it is a suggestion. The design that holds is that every indexed passage carries the access rules of the document it came from, and the retrieval step filters on the identity of the person asking, so nothing can surface that the asker couldn't already open.

Two things catch companies out, and neither is a software bug. The first is that your Drive is more open than you think. Search is what converts "technically shared with everyone" into "found by everyone", and plenty of teams discover their real permission state on the day they index it. The second we learned the hard way.

Credit where it is due: the seat-based tools are good at this inside their own territory. Dashworks lists document-level access control with instant permission updates on its pricing page, and permission mirroring is central to Glean's enterprise pitch. What none of them can do is enforce permissions in a system they have no connector for, because they cannot see it. That gap is the honest argument for a build, and it is the only one we make.

Permissions belong in the retrieval filter, never in the prompt. Ask any vendor which one they do.

What sources can it actually connect to?

The mainstream set is well covered by everyone: Slack, Microsoft Teams, Google Drive, Notion, Confluence, SharePoint, Gmail and Outlook, HubSpot, Salesforce, Zendesk, Jira, Linear, GitHub. Glean advertises more than 250 connectors. If your list is a subset of somebody's connector catalogue, that is your answer and this section is over.

The interesting sources are the awkward ones. Meeting recordings, which need transcription first. Scanned contracts, which need OCR. Your practice management system, your booking system, the internal admin tool a contractor wrote. Anything with an API or a readable database can be indexed, and that is usually the actual reason a company stops shopping and starts scoping a custom knowledge layer.

Whatever you pick, connect two or three sources first, not twenty. A knowledge base covering three sources that people trust beats one covering twenty that they don't, and the first wrong answer costs you more adoption than the tenth right one earns.

The source that decides buy-versus-build is nearly always the internal system you forgot to put on the list.

How long does it take to set up?

Off-the-shelf: an afternoon to connect OAuth to your main tools, then about a week of real use before you know whether it is any good. Do not evaluate on day one; the index is still backfilling and every early answer is unfair to the tool.

A custom build runs around four weeks to first answers in production on a deliberately narrow first scope, with two or three sources connected and permission-aware retrieval working. Additional sources and deeper permission models come in later phases.

Neither of those numbers is the real timeline, because indexing is not the long pole. In our company-wide rollouts the shape is consistent: the founder and exec team go first, the first department is onboarded two to four weeks later, and roughly 30% of staff are active users at three months. The months in between are spent on department-specific configuration, choosing or building connectors, and training people, not on infrastructure.

Two weeks to a working system, three months to a habit. Plan the second number.

How do you know it's working, and what should you measure?

Not queries per day. That number tells you people opened it, which is the metric every vendor dashboard shows because it is the one that always goes up. Four numbers are worth collecting, and all four are cheap.

• Questions that stopped being asked. Count "does anyone know" messages in your busiest channel for two weeks before launch and two weeks after. This is the only number that maps to money.
• Citation accuracy. Hand-check twenty answers a week: does the cited passage actually support the claim? Below roughly 90% and people stop trusting it, which is unrecoverable without a relaunch.
• Refusal rate. If the system never says "I don't have that", it is guessing. A healthy internal assistant refuses regularly, because plenty of internal questions genuinely have no documented answer.
• Active users at three months. Around 30% of staff is what a good rollout looks like in our deployments. Treat that as the target, not as a shortfall.

One pattern worth stealing. In team deployments, nobody touched the generic assistant until we built configuration specific to each department. Adoption followed specificity, every time. A knowledge base marketed internally as "ask it anything" gets tried once; one introduced as "this answers pricing and contract questions for sales" gets used.

Measure trust, not traffic. One confidently wrong answer costs more adoption than ten right ones earn.

What happens when two of your documents contradict each other?

Nothing visible, which is the problem. Retrieval pulls both passages, the model reconciles them into one fluent paragraph, and you get a third version of the policy that was never true. No error, no warning, no flag. Somebody quotes last year's rate to a client six weeks later and that is how you find out.

This is not a retrieval problem and no tool solves it for you. In our second-brain work, ownership and versioning had to be fixed before AI was connected to anything: one named owner per money topic, one document that wins, every duplicate archived or pointing at the winner. That work is unglamorous and it is most of the project. Our AI knowledge readiness audit is the five-check version you can run yourself this week, free, before you spend anything.

If you are buying rather than building, Guru's verification workflow is the closest an off-the-shelf tool gets to handling this, because it forces a named human to re-verify a card on a schedule. It still needs the human.

AI doesn't fail loudly on contradictory documents. It fails fluently, which is worse.

Can your AI agents use the same knowledge base?

Only if it exposes an API or an MCP server, and this is where seat-based tools get thin. They are built for a human typing in a chat window. Agents need programmatic retrieval, per-agent identity so permission filtering still applies, and rate limits that assume machine traffic.

It matters more than it sounds. Once you run a sales agent, a support agent and an ops agent, each one ends up carrying its own half-right copy of company knowledge, and they drift apart at different speeds. One index that every agent queries is the fix. We treat it as the memory tier of a company's agentic OS, and if agents are where you are heading, our guide on how to implement AI agents covers the rollout side.

Ask the vendor for API and MCP access before you buy, even if you have no agents yet.

Who should not buy an AI knowledge base, and when should you not hire us?

Four groups, and we say all of this on discovery calls. A team of ten with one tidy Notion workspace should buy the Notion AI tier or nothing at all; you will pass the readiness checks in an hour and learn nothing. Any company whose knowledge genuinely lives inside Slack, Drive and Notion should buy seats from one of the vendors above and not commission a build, and we will tell you that rather than scope one.

Third: companies where almost nothing is written down. Indexing empty drives returns an empty assistant. What you have is a management problem with a management fix, and it has to come first. Fourth: if you have an engineer with real spare capacity and two or three source APIs, build it yourself. The pipeline is well documented and you will understand your own retrieval better than any vendor explains theirs.

The failure mode we would most like you to avoid is the flat rollout. Access for everyone on day one, an all-hands demo, and then a slow fade. That is exactly how the $3,000-$5,000-a-month agent programme we mentioned earlier died inside two months. What we do now is start with one department that has a specific, repetitive, expensive-to-answer question, and expand only after that department stops asking it.

We would rather lose the build than sell you the wrong row of that table.

Frequently asked questions

Related reading

• AI knowledge readiness audit — the five pass/fail checks to run on your documents before you connect anything to them.
• Company second brain — what we build when off-the-shelf tools can't reach the systems that matter.
• All Cognio guides — agents, costs, security, and knowledge, written from deployments rather than press releases.