The missing middle of company knowledge
Three layers, not one
Talk to anyone about “company knowledge” and the phrase does too much work. It collapses three very different things that live in different places and decay at different speeds. Pull them apart and the gap becomes obvious.
The first layer is your systems of record. Customers in Salesforce or HubSpot, people in Workday, clicks in GA4, money in the books. This is structured data that lives in rows, and the industry has spent thirty years getting good at it. It is governed, queryable, and mostly correct. It also stays put. We are not interested in rebuilding it.
The second layer is canonical knowledge. Your pricing, your positioning, the company vision, the answer to “what is our stance on X.” This is the durable thinking a team does once and then references for years. It is governed in a different sense: the new intern cannot quietly rewrite the mission statement. Wikis, Notion, and Guru handle this reasonably well, and the recent wave of “company brain” setups is mostly aimed here. We wrote about that wave in Agents need a brain they can write to.
Then there is the third layer, and almost nobody is focused on it.
The operational layer nobody maintains
The third layer is operational knowledge. What is actually going on with a customer right now. Who on the team just learned a new skill. The open question that has been sitting unanswered in a thread since Tuesday. The support issue a client keeps bringing up that has not made it into any ticket yet.
This knowledge is born in communications. It changes by the hour. And today it is maintained badly or not at all, which is strange, because its absence does measurable damage.
Picture a salesperson walking out of a good meeting. The contact’s new title and phone number flow into the CRM, because that part is structured and a form exists for it. But the customer’s growth plans for next year, the three questions they are weighing, the renewal they are quietly nervous about, all of that goes nowhere. It stays in one person’s head and a few lines of a recap that nobody reads. The next teammate to touch the account walks in blind, asks something the customer already answered, and the deal is jeopardized. Multiply that across every account and every handoff.
That is the operational layer leaking, every day, in every company.
Why you cannot solve it the old way
Here is the uncomfortable part. You cannot fix the operational layer with the tools that fixed the other two. It has a shape, just not a rigid one: it is organized around the things you care about, a customer, a competitor, a teammate, but what you know about each one is prose, not fields.
It will not fit in rows the way the systems of record do. “The customer seems hesitant about the migration timeline and keeps circling back to data residency” is not a field. There is no dropdown for it, and the moment you try to force one, you lose the thing that made it useful.
It also will not survive hand-curation the way the wiki does. A canonical page about your pricing is worth writing by hand because it is true for a year. An operational note is stale the day after you write it. Ask people to keep it current by hand and they will not, because the job is endless and thankless, and they have actual work to do. The knowledge-base literature has a name for what happens next: systems die of staleness, and teams end up with parallel truths, two pages that disagree and no one sure which to believe.
So the only way to hold operational knowledge is to stop treating it as something a person writes down. It has to be maintained continuously and automatically, from the same communications it was born in. That is a genuinely hard problem, and we are not going to pretend it is finished. It is the direction we are building.
What it looks like when it works
The point of maintaining this layer is that the rest of the system gets to lean on it.
A workflow can read competitor and partner news every morning and write what changed into the brain, so the CEO is not the last to learn about a rival’s move while walking into a conference. The knowledge accrues; it is not a report that scrolls past in a channel and is gone.
The operational layer also makes your automation smarter, because the two halves compose. When Susie finishes a machine-learning course, that fact lands in the brain. The next time an ML task comes in, the workflow that routes work already knows Susie is the right person, without anyone updating a rule by hand. Knowledge feeds the automation, and the automation, in turn, keeps producing more knowledge worth keeping.
And the salesperson from earlier? The next teammate opens the account, and the context is already there, written from the threads instead of stuck in one person’s head.
A clear boundary, on purpose
One thing we are deliberate about: this is not a CRM, and it is not trying to become one.
Transactional data stays in its systems of record. Layer one does not move. The operational layer sits between the CRM and the wiki, holding the living context that neither of them was built for. The contact record stays in Salesforce. The pricing page stays in the wiki. What is happening with this customer this week, who knows what, the question still open in the thread, that is what we maintain in the middle. Drawing that line clearly is not a limitation we are apologizing for. It is the position.
Karpathy was right that an LLM-maintained knowledge base is a compounding artifact, and the company-brain trend that followed is a real and smart idea. The piece still missing is the middle layer, the one that is too fast-moving to curate and too unstructured to schematize. Nobody owns it yet. That is where we are building.