An AI operating system for companies
What a company calls institutional memory is what one person calls remembering why a decision was made two years ago, what was promised to whom, and where everything stands right now. It is the same problem. Three things change when more than one person depends on the answer.
The problem does not change, the stakes do
A personal operating system exists because a person cannot hold their own commitments, decisions and reasoning in their head. A company version exists for the same reason, except the forgetting is distributed. The context sits with whoever was in the room, the reasoning behind a decision leaves when they do, and the new person spends their first three months reconstructing what was already known.
Companies usually answer this with search: a tool that indexes everything and finds the document. That helps and it is not the same thing. Finding the document tells you what was written. It does not tell you what was decided, why, or what changed since, because nobody wrote that down anywhere for the search to find. The distinction is drawn out across the company brain pages.
The three things that change
| Changes | Because |
|---|---|
| Who is allowed to see what | A personal system has one reader. A shared one needs the record to be useful without exposing everything to everyone, which is a structural decision made early or painfully later. |
| Where the raw material comes from | One person's mail and calendar becomes many people's, and the assistant has to know which project a thread belongs to without being told by the person who sent it |
| What happens when someone leaves | This is the one that justifies the whole project. If the reasoning lives in files rather than in a person, a departure is a staffing problem rather than an amnesia event. |
Notice what is not on that list. The structure barely changes: projects, people, decisions, reference, and routines that run over them. The layers are the same layers, described in how to build one. What changes is who the record has to be true for.
Build it or buy it
The honest answer depends on whether the thing you need is already a solved category. If your problem is a regulated process with validated software behind it, buy the validated software; a self-maintaining record is the wrong tool for that job and saying so is more useful than selling around it. If your problem is that the state of your projects, partnerships and commitments lives in people's heads and in threads nobody can find, no vendor sells that, because the answer has to run on your own material. That trade-off is worked through case by case across the build versus buy pages, and against the named alternatives in the comparison set.
The useful test: would this system still be right if the person who set it up left tomorrow? A personal operating system can afford to fail that. A company one exists precisely to pass it.
Where to start, and it is not with the company
Build it for one person first, on one machine, where the loop is short enough to actually learn what works. Almost everything that makes a shared system good is discovered by running a personal one for a few months: which structure survives contact with a real week, which routines get used, which of the assistant's judgment calls you trust and which you want to approve. Rolling out a shared version before anyone has run a personal one produces a system designed against a guess.
That is the order this site is built in, and the reason the book is about the single-person version. If you want the industry-specific version of the company layer instead, that work lives at AI for life sciences.
Start with the version you can build yourself
The book builds the whole thing for one person, hands-on, in plain files you own. It is the cheapest way to find out what a shared version should be.
Get the bookSee what it looks like with a team on it
Projects, partnerships, commitments and decisions kept current from a company's own email and meetings. Try the demo.
See the demo