The 4-Layer Architecture for Sharing Context Across Your Whole Company

A credible builder asking unprompted, in public, with that exact framing matters. Technical teams ship context through git, dotfiles, README files, and shared repos. Non-technical teams ship context through Notion pages, Slack threads, Loom recordings, and what gets shared in passing between colleagues or on calls. Neither pattern produces a shared, queryable, role-aware foundation the whole company can build on. The gap is articulated, the obvious workarounds have been tried, and nothing in the consumer AI stack closes it.

By the end of this you should know what the four layers of a working answer look like, why each one has to exist, how to evaluate whether yours is doing its job, and which part of the build is genuinely hard versus which part is buildable in a few weeks. If you have already started building toward this and are stuck somewhere, this should help you locate where.

The four layers above are the engine. The engine is not the hard part.

By “schema” I do not mean a JSON schema or a database schema. I mean the operating logic of the knowledge base itself. The curated CLAUDE.md that tells the system how to think. The node type taxonomy that decides what counts as a “principle” versus a “case study” versus a “lesson” versus a “reference.” The validator rules that reject malformed nodes before they enter the graph. The governance lifecycle that promotes emergent observations into validated canon. The seed knowledge that gives the graph enough density to be useful on day one. The ingestion patterns that decide how raw transcripts and meeting notes get atomized into nodes. The conventions that decide what to link, when to supersede, how to handle contradictions.

Knowing what should be in that schema for sales operations versus customer success versus finance versus product is what takes years of shipping operations to learn.

The validator rules that work for a GTM team do not work for a finance team. The node type taxonomy a sales operation needs (ICP, objection, case-study, decision-criteria) is different from what a product team needs (user-research, decision-log, experiment-result, open-question). The lifecycle rules that fit a customer-success team's daily ingestion cadence look nothing like the rules that fit a finance team's monthly close cycle. You cannot describe what good looks like for your niche if you have not lived inside that operation.

The reason memory engines and “company brain” startups stall in this category is almost always a vertical-fit problem dressed as a technology problem. Founders say “retrieval is bad” or “the AI hallucinates” or “the team is not adopting it.” Underneath, the actual issue is that the schema was generic, the validator rules were borrowed from a different domain, and the seed knowledge did not match how the operation actually runs. The graph fills with noise inside a month not because the engine is broken but because no one decided what the engine should be tracking.

This is also why a generic, off-the-shelf “context OS” tool tends to underperform. The foundation works. The vertical-specific design judgment is the part that has to come from somewhere. You either build it slowly through trial and error in your own operation, or you start from a schema someone has already battle-tested in your vertical and tune from there.

That is the real product question. Not whether you can stand up the engine, but whether you have the vertical-specific schema judgment to make the engine produce compounding intelligence rather than slowly decaying noise.