Home / Company brain / AI company brain vs a wiki
Comparison

AI company brain vs a wiki: what each one holds in drug development

These are not competing products. They hold different kinds of thing, and the whole question is which of your problems is which.

A wiki holds content that stays true until somebody edits it. A company brain holds state that goes out of date on its own, without anyone touching it, because the world moved. Almost every argument about whether a team needs a knowledge base or something smarter is really an argument about which of those two a specific piece of information is, and it can be settled in one question.

The test. Does this page stop being true if nobody edits it? If no, it is reference, and a wiki is the right home. If yes, it is state, and a wiki will quietly rot until somebody acts on a stale version of it.

Sorting your own material

The thingReference or stateRight home
How we run a stage-gate reviewReferenceWiki
Which stage gate we are atStateCompany brain
The template for a study reportReferenceWiki
Whether the report is late and by how muchStateCompany brain
Our onboarding guide and glossaryReferenceWiki
What the partner agreed to on TuesdayStateCompany brain
The signed collaboration agreementReferenceWiki or document store
Which obligations in it are live and dueStateCompany brain

Read the right-hand column and the pattern is obvious: the reference rows are the ones a person writes once and revisits rarely, and the state rows are the ones that change because an email arrived. That is why a wiki is a purchase and a company brain is closer to a build. Nobody has to keep a wiki current on your behalf, so anyone can sell you one. Keeping state current means reading the mail and the meetings that changed it, which is a different job entirely.

Why wikis fail in the state rows specifically

The failure is not laziness. It is that updating state is unpaid work with no deadline, done by the person with the least slack, and it competes with the thing that actually caused the update. When a contract research organization writes on a Friday to say the report will slip two weeks, the program lead's next hour goes to working out what that does to the filing date, not to editing a status page. So the page keeps the old date. Two weeks later somebody plans around it.

And a stale page is worse than no page, because people believe it. That is the specific harm: a wiki that is 80 percent current is trusted like one that is 100 percent current, and the 20 percent is invisible. A page nobody trusts at least gets checked.

Search layers do not fix this either. They make the stale page easier to find and put a fluent summary on top of it. The distinction between searching what you own and maintaining what you own is the whole argument in Glean alternatives: AI search vs an AI company brain in biotech. If your team already lives in a general workspace tool and you are trying to work out where it stops, that comparison is Notion for biotech: where it stops and AI starts.

Where drug development makes the split unusually sharp

In most industries the state rows are internal, so at least the person who changed the fact is in your building. In drug development the state arrives from outside and from people who will never open your wiki. The tox contract research organization owns the study schedule. The analytical vendor owns the method transfer date. The contract manufacturer owns the slot. The partner owns half of the joint decisions. The regulator owns the clock. A twenty-person biotech can have its entire critical path determined by five external calendars it does not control, each of which communicates changes by email, to one person, at an unpredictable time.

That is why the reference-versus-state split is not a philosophical distinction here. The reference half of a biotech's knowledge, the protocols and the templates and the how-we-do-it pages, is genuinely small and genuinely stable. The state half is large, fast-moving, externally driven, and it is where every expensive surprise comes from: the notice period that expired, the deliverable that slipped without a downstream update, the amendment that changed a payment trigger nobody re-read.

Running both, which is the honest answer

Keep the wiki. Put the reference material in it, keep it small, and stop trying to make it hold status. Then give the state rows to something whose job is to read what already happened and write the record itself, so that the update is a side effect of the work rather than a chore competing with it. The full definition of that second thing, and what it does not do, is at what an AI company brain is.

Two related reads finish the picture. The discipline-level version of this argument, including what changes when a machine rather than a person writes the record, is AI knowledge management for a drug development team. The larger-organization version, where the word carries regulatory weight and the answer is sometimes to keep buying the validated system, is knowledge management in pharma, run by AI. And if what you are really deciding is whether to build any of this internally, start with the build vs buy decision for a biotech.

WHICH OF YOUR STATUS PAGES IS QUIETLY TWO WEEKS BEHIND?

Only the state rows, and nobody edits them

Keep the wiki for the reference half. There is a working app that takes the other column, and the demo walks it: which gate a program is at, which obligations are live and due, what a partner agreed on Tuesday, each changing because an email arrived rather than because somebody remembered. Have a look, then sort your own material into the two columns.

See the demo