How to build an internal knowledge base, with AI doing the filing

Nobody fails at this because the structure was wrong. They fail in month two, when the structure is still fine and nothing in it is true any more.

Building an internal knowledge base is genuinely easy, and that is the trap. An afternoon gets you a clean set of pages that answer the questions people keep asking. Six weeks later half of those pages describe a process that has since changed, and the half that is still correct is indistinguishable from the half that is not. From then on nobody trusts any of it, so nobody updates any of it, and the thing becomes a monument.

So the useful version of this guide spends one section on the build and the rest on the only question that decides the outcome, which is who does the filing next month.

The build, which takes an afternoon

Whether you are building a company knowledge base for everyone or a narrower one for a single function, the same six moves get you there.

• Start from the questions, not from a taxonomy. Write down the last twenty things somebody asked in chat or mail. That list is your table of contents. A category tree invented in advance is a guess.
• One page per answer, not one page per document. A page called "how we handle vendor change orders" is useful. A page that is a link to a folder of change orders is a shortcut with ambitions.
• Put a name against every page. Not a committee. If a page has no name on it, it has no future, and you may as well find that out in the first hour.
• Mark what is current. Every page carries the date it was last known true and what it supersedes. This one line does more work than any amount of tagging.
• Write the smallest useful version. Five sentences that are right beat two pages that will not be maintained.
• Then stop. The instinct to keep going is the instinct that produces sixty pages nobody reads. Ship the twenty and let demand tell you what is missing.

Most people arrive at this with a platform already in mind: a wiki, a shared drive, a folder tree, or SharePoint because it is already in the building. That choice decides less than it feels like it does, because what kills a knowledge base is not where the pages live.

Month two, where these actually die

A knowledge base has a decay rate, and it is set by how fast your business changes rather than by how carefully you wrote. Every week some pages go stale. Fixing them is unpaid, invisible work that arrives on the desk of whoever is busiest, and it always loses to the thing with a deadline attached. That is the economics, and no amount of process design changes it.

Then the second-order effect arrives, and it is the one that finishes the job. Once a reader has been burned twice by a stale page, they stop reading the base and go ask a person. Usage falls, so the case for maintaining it weakens, so it decays faster. Both of the classic failures, the abandoned wiki and the shared drive with eleven versions of the same document, are the same failure at different speeds.

What changes when an agent does the filing

The reason this page has AI in its title is not that a model writes better pages. It is that the maintenance economics change when the filing stops being somebody's unpaid second job. An agent with read access to the mail, meetings and documents already moving through the business can do the unglamorous half: file what arrived to the right page, close the items it resolved, open the ones it created, move the dates it affected, and flag the page it just contradicted.

Being precise about the shape of that claim matters. It runs on a schedule, hourly at best, on a machine that is awake. It only knows what reaches it, so anything decided verbally and never written stays outside. Nothing outbound goes without a person approving it. And it is one seat, one owner, one mail identity, which means the honest description is a knowledge base maintained for the person who owns it rather than a platform a whole company edits. The version of this argument aimed at what such a system reads and what it puts back is company knowledge base AI, and the wider category is covered in AI knowledge management for a drug development team.

If you would rather not build the maintenance layer yourself, the app installs in about 30 minutes, yourself or done with you, and it is in limited early access, so getting a copy starts with a conversation. There is nothing to import: it reads back through the mail already in the account and builds the first version of the pages from what it finds.

The biotech version of the same problem

In a drug development company the pages that matter are not the process pages. They are the ones holding external state: which version of the analytical method the tox lots were run against, what the contract research organization committed to in the last change order, which shipment the courier holds, and what the partner asked for at the last steering committee. Every one of those is authored outside your building and updated by email, so the page describing it is stale the moment somebody else changes their mind.

That is also why the DIY version struggles here more than in most industries. The maintenance load is not proportional to your headcount, it is proportional to the number of organizations you depend on, and a twenty-person biotech can easily depend on a dozen. The structural argument for holding that as live state rather than as documentation is what an AI company brain is, and the promise it is trying to deliver is AI institutional memory. If what you want is the live-state build rather than the documentation build, that has its own parts list in how to build a company brain.