How to build a company brain: the working parts
Five parts, and an order. The order matters more than any of the tooling choices, because four of the five are useless until the one before them exists.
This page assumes you have already decided you want one. If you have not, the case and the definition are at what an AI company brain is, and this page picks up where that one stops. What follows is the mechanism: the parts, what each one is load bearing for, and what happens if you skip it.
The five parts, and what breaks without each
| Part | What it is | What breaks without it |
|---|---|---|
| Plain files | Ordinary text, one folder per program, deal or partner, on hardware you control | Your record becomes a feature of somebody's product, readable only through their interface |
| One canonical home per fact | Each date, number and status lives in exactly one file; every other view reads from it | Two answers to the same question, both defensible, both cited from your own material |
| Intake from mail and meetings | The system reads the threads and transcripts already happening and files what it finds | Capture stays a chore, competes with the work, and loses inside a month |
| Scheduled passes | A run on a timer that files arrivals, closes what was resolved, opens what was created, drafts the next step | The record is accurate only when someone remembers, which is before meetings and after nothing |
| Records that reconcile | A second look that re-reads conclusions against sources and flags what it cannot support | Confident answers built on something that quietly went out of date |
The fifth part is the one people leave out and the one that decides whether you can trust the other four. Handing more work to a system means checking less of what it hands back, so the check has to live inside the system. In practice that means a pass with no memory of the first one re-reading an answer against the source it cited, and downgrading a stated conclusion to a flagged one when the evidence underneath it is thinner than the claim. The error it catches is usually not a wrong number. It is a sound-looking inference sitting on top of correct numbers.
Build them in this order
Files first, and only the folders you actually have live work in. Three or four is right. A structure built for the company you expect to be gives the intake more places to be wrong.
Canonical homes second, before anything is connected. This is the step people skip, and skipping it is what turns intake into a pile. Decide where the study date lives, where the obligation register lives, where the state of a partner conversation lives. One home each. Everything downstream, including every view you will later want, reads from those files rather than restating them.
Intake third. Read access to the mail and calendar you already use is what makes the record write itself, and without it you are back to pasting. There is nothing to migrate at this step: the system reads back through the mail already sitting in the account and builds the first version of the records from what it finds, which is why there is something worth looking at in the first week.
Passes fourth, once the records exist and are shaped right. A pass on an empty structure produces noise. Be honest about the cadence while you plan: this is hourly at best, it needs a scheduler and a machine that is awake, and without those it is a one-keystroke command you run yourself. Nothing outbound is ever sent on its own; the pass drafts and queues, and a person says yes.
Reconciliation fifth, and continuously after that. It is not a phase you finish.
Two limits to design around, not around which to design. The record only knows what reaches it, so a decision made in a corridor and never written anywhere stays lost. And this is one seat: one owner, one mail identity. It never assigns work to a colleague. Someone else's commitment is held as your own follow-up, which is to check whether they did the thing.
What putting it in place actually costs
Less than a migration and more than an afternoon of prompting. 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. The instructions are written for the person who will use the thing rather than for an administrator, and the work is choosing the folders, granting read access, and setting the schedule.
The larger cost is not the install, it is the decision of what the canonical homes are, and that is yours whichever route you take. If the route in question is whether to have someone on your team build the whole thing instead, the arguments on both sides are laid out in Claude Code for biotech vs off-the-shelf AI tools. If what you actually want is the documentation half rather than the live-state half, that is a different build with a different failure mode, covered in how to build an internal knowledge base.
The part that changes in a drug development company
The five parts are the same anywhere. What changes in a biotech is where the facts come from, and it changes the second step more than any other. Your canonical homes have to be built around state that somebody else owns: a stability study whose timepoints are on a vendor's calendar, a batch release that a manufacturer will confirm or not, a milestone payment that triggers on an event you have to prove happened, a diligence request list with a deadline set by the other side. The date that matters is not one you set. It is one that moves when someone else's email says it moved, on a Friday, to one person.
So the folder for a program is not a project plan with a status field. It is a set of open threads with owners outside your building, each with the last thing they said and the next thing they owe. Get that shape right and the intake has somewhere correct to put a slipped date. Get it wrong and you have built a filing system for correspondence. The broader promise this is all in service of is AI institutional memory, and if you are coming to this from a personal system, the translation problem is a second brain for companies.
All five parts, wired together on one program
Plain files with a canonical home for every date, intake off the mail already sitting in the account, a scheduled pass that files what arrived and drafts what follows, and a reconciliation step that downgrades any claim its source will not carry. The demo shows each one doing its job.
See the demo