How to build a company AI knowledge layer

Start from the failure, not the feature list

Company AI fails two ways, and I have watched both up close. Context failure: the system never actually learned the company's facts, so it is fluent and wrong. Trust failure: nobody believes the output enough to send it without redoing it. A knowledge layer is the fix for the first, and most of the fix for the second, because a system that can cite its sources is a system a person can stop supervising.

I have built four of these for four different businesses. The first now has 100+ daily users and over 1,000+ pieces of collateral behind it. What follows is the architecture they share, which survived four generations of revision, and the parts of it that turned out to be load-bearing. Inside the Company OS this layer has a name, the Company Brain, and it is the knowledge core the rest of the system stands on.

One file the system always reads first

Every brain opens with a constitution: who the company is, how requests route, which sources outrank which, and the hard rules framed as things the system will never do. It is the only file that is always loaded. Everything else waits to be asked for.

The constitution earns its position by being short. Mine ran 146 lines in the first build and 80 in the second, because adaptation converges where invention drifts. The third went back up to 110 on purpose: that client was new to AI, and every extra line bought plain language. The length tracks the reader, not the system. What a constitution must never become is a manual. A manual is what the rest of the layer is for.

A routing table instead of a crawl

The single most useful line in the constitution is a table: this request type opens these files. A one-pager request loads the one-pager directions, the matching skill, and that account's facts. It never crawls the whole tree hoping to find something relevant.

This matters more than it looks. Same start every time is why quality is the same every time, and it is also what keeps the layer cheap to run: a system that reads everything to answer anything gets slower and vaguer as the company's knowledge grows, which is exactly backwards.

The folder structure is the architecture

The layer is a folder tree, and the tree is not storage. It is the workflow, made physical. Drafts live in one place, work under review in another, and the approved library in a third, which means position in the tree is approval status. Nothing ships by accident, because shipping means a named human moved it. Superseded work is archived, never deleted, so the history stays legible.

The same principle runs the intake. I never ask a busy owner to organize their own knowledge. I build every folder in advance, named in plain language, and send one instruction: drop everything in. The structure does the sorting. A misfiled document is a thirty-second fix on my side. A client frozen by a blank shared drive is a dead project.

One home per truth

The facts layer holds the company's actual knowledge, and it is governed by one rule: every truth has exactly one home. Pricing lives in one authority file. Claims live in another. When a deliverable needs the number, it cites the file rather than carrying its own copy.

This is the least glamorous decision in the whole architecture and the one that pays longest. Two copies of the same fact will always drift, and the drift is invisible until a partner receives the wrong one. This site runs on the same rule: every figure that appears on more than one page lives in a single metrics file, and the pages interpolate it, so a number changes in exactly one place.

When sources disagree anyway, an explicit trust order settles it: approved beats facts beats drafts. And when a fact simply is not there, the system says UNKNOWN and files a numbered question rather than guessing, because a guess in a facts file is indistinguishable from a fact one week later.

What four generations taught

The interesting part is not any single build. It is what changed between them, and what refused to change. The enforcement moved from prose to pipeline: in generation one the house style was an item on a checklist, and by generation three the same rule was a regular expression inside the deploy with a non-zero exit code. The constitution stopped describing the system and became an output of it, generated from what is actually installed, because a hand-maintained description of a system is a second copy of the truth.

Four rules survived every generation untouched: read the map instead of crawling the folders. UNKNOWN over a guess. Never edit an approved file in place. Archive, never delete. Four out of four means those were the load-bearing primitives, found in the first build and never improved upon.

Where to start

Not with a model, and not with a demo. Start with the questions: what is true about this company, who may approve what, what must never be said, and where does each answer live. My version of that is a structured intake, sixty fields across eleven sections, each mapped to the exact file it produces. The gap between a completed intake and a working knowledge layer is assembly, not invention, and that is the whole point of having an architecture: the thinking happens once, and the fourth build inherits everything the first three learned.