Every team is building a company brain. The voice of customer context layer is the part that breaks.
Teams build company brains with Claude, MCPs and skills. Code, design and goals work. The customer layer breaks. Here's the test, and when to buy it.
Walk into any software company with more than 50 people right now and you will find a company brain under construction.
Nobody calls it that. It is a Claude project with the strategy doc and the ICP in it. A folder of markdown in GitHub. A few MCP servers wired into Cursor. A skill someone wrote on a Friday that pulls context from three tools at once.
Each piece works, for the person who built it. The question is what happens when the whole company has to use it.
”The hard part of a company brain is not storage. It’s the customer.”
What a company brain looks like today
We spent the last quarter interviewing product, design and engineering leaders about how they give AI tools context. The pattern was the same almost everywhere: smart people, building in the gaps, one at a time.
- One person’s Claude project. A PM keeps strategy, the ICP and performance data in a single Claude project. It makes their own work faster. For everyone else, it “sometimes means misalignment,” because nobody else’s AI sees the same context.
- A homegrown context library. A founder built a shared library of company context in Obsidian and GitHub. The tooling was easy. Getting people to add to it took “culture change to get people to contribute.”
- Engineers building plumbing. An AI engineer described real sprint time going into “making internal things that provide context to Claude” instead of the product customers pay for.
- An experimental company-wide skill. A design leader built a skill that pulls context from across the company into any conversation. Promising, and owned by one person.
- One context for every agent. A data team wanted every agent and tool to start from the same context, so the answers stop disagreeing.
None of this is wrong. It is how every useful internal system starts. But look at what these setups store: decisions, goals, docs, code. Things that were written down once and change slowly.
Four layers, four very different problems
A company brain is really four layers of context stacked together. They do not behave the same way.
| Layer | Who owns it | How often it changes | Build it in-house? |
|---|---|---|---|
| Code | Engineering | Every commit | Already done. Your repo and coding agent handle it |
| Design system | Design | A few times a quarter | Yes. Tokens and components are already structured |
| Company goals and strategy | Leadership, product ops | Monthly or quarterly | Yes. A well-kept folder of docs works |
| Customer evidence | Nobody, and everybody | Every call, ticket and survey, every day | Only if you’re ready to run a data pipeline |
The first three layers are documents. Someone writes them, someone updates them, and an agent can read them. Retrieval is enough.
The fourth layer is different in kind.
Why the customer layer breaks
Customer evidence arrives all day, from every direction. Sales calls, support tickets, interviews, survey answers, CRM notes, Slack threads. Nobody writes it down as a tidy document, and nobody owns keeping it current.
Worse, the questions people ask of it are not reading questions. They are counting questions:
- How many customers asked for this?
- Which accounts, and what are they worth?
- Is it growing or fading since last month?
A retrieval setup answers those by reading a handful of transcripts and writing a confident paragraph. That works with ten conversations. Past the context window, the answer turns anecdotal, and nobody can tell which claims are real.
To count, you have to process every conversation ahead of time: pull out each need, group the ones that mean the same thing, tie each to an account, and keep a link to the exact quote. Then keep doing it, every day, as new evidence lands.
”Retrieval finds documents. Counting finds the roadmap.”
That is a pipeline, not a prompt. It is also the layer your agents most need when they decide what to build.
The counting test
Here is a quick way to tell whether your company brain has a customer layer or just a pile of transcripts. Ask it one question:
“How many customers asked for this feature last quarter, and what are they worth?”
- If you get a count, the accounts and a link to each request: your customer layer works. Keep building.
- If you get a confident paragraph and no numbers: you have a chat window over your transcripts, not a customer layer.
If it fails, you have two options. Build the pipeline yourself: ingestion from every source, need extraction, clustering, account matching, citations, and someone to keep it running when the builder moves on. Or buy the customer layer and keep building everything else.
That second option is not a retreat from building. Your code, design system and strategy layers stay yours. The customer layer plugs into them through MCP, the same way your other context does, so every agent in the company gets counted, cited customer needs alongside everything else it knows.
What this means for whoever owns the company brain
If you run product ops or AI ops and the company brain landed on your desk, three things are worth deciding early:
- Which layers change faster than people will update them by hand. Those need a pipeline, not a folder.
- Which questions your teams will ask most. If they are counting questions, retrieval will not be enough.
- What happens when the builder gets busy. A context system one person maintains is a context system that stops.
The teams that get this right will not have the most elaborate brain. They will have the one whose answers about customers come with a number and a source.
Want to run the counting test on your own customer evidence? Connect Evermuse to Claude at evermuse.com/mcp and ask how many customers asked for the thing you’re building next.
FAQ
What is a company brain? A company brain is the shared context a company gives its AI agents: code, design system, goals and strategy, and customer evidence, usually connected through tools like Claude projects, MCP servers and skills. It lets every agent and person start from the same knowledge.
Is a company brain the same as a wiki? No. A wiki stores documents people write. A company brain also has to serve context that changes daily, like customer feedback, in a form agents can query, count and cite.
What is context engineering? Context engineering is designing what information an AI model sees and how it gets it. For product teams it means giving agents counted, cited customer needs, not just code and docs.