Company brain products are genuinely useful. They find the right document across your apps in seconds, answer lookup questions, and show you where knowledge lives. But most of what ships under the name is very good search with a grand name. They search your content; they do not know your business. They rarely resolve the same customer across systems, tell current information from superseded, or answer a question that spans three systems and a chain of relationships. Buy them for lookup. For the questions where a wrong answer costs money, you need something they do not yet build, and there is a simple test for telling the difference.
Why everyone is suddenly selling a company brain
The idea is irresistible: one memory of everything your business knows, available to every person and every AI agent. Y Combinator named "Company Brain" a flagship category in its Summer 2026 Request for Startups, and funded products and open-source projects are gathering around it, from enterprise search platforms to memory layers for AI agents.
Add the agents your existing software vendors now bundle, and a buyer can be pitched three different "brains" in the same week. So the market is loud, and the term is doing a lot of work. That is good news for buyers in one respect: the category is now legible, and budgets are easier to justify. It is bad news in another. A category name tells you what a product aspires to, not what it does. It is worth being precise about both.
What they genuinely do well
Credit where it is due. The better company brain products solve a real and expensive problem: people spend a startling amount of time looking for things.
They connect to the common business apps, index documents, messages and tickets, and respect the permissions already set in those systems, so people only see what they are allowed to see. They are good at knowing which knowledge lives where, which is valuable on its own in any organisation that has grown faster than its filing.
And they answer lookup questions well. What does the expenses policy say about client dinners? Who last worked on this account? Where is the latest version of the sales deck? For questions like these, a well-connected search product with a capable model on top is quick to deploy and pays for itself. If that is your main problem, buy one and move on.
Where they stop
The trouble starts with questions that are not lookups.
"Which customers with an open complaint also have a renewal this quarter?" "Which of our suppliers is party to a live dispute and on a contract we are about to extend?" These need the system to know that the supplier in an email, the one in the finance system and the party named in a contract are the same company, to follow relationships between records, and to know which records are still current.
Most products do not do this reliably. Relationship questions are where explicit structure pays: in the data.world benchmark, GPT-4 answered 16.7% of enterprise questions correctly over a raw database and 54.2% over a knowledge graph of the same data (data.world, 2023). Many products retrieve passages that look relevant and let the model assemble an answer, which is exactly the approach that falls down on relationship-heavy questions, as I explain in why your RAG system keeps missing what is in your documents.
They also stop at the edge of their connectors. The shared drive nobody tidied, the legacy system no vendor supports, the email archive where the real commitments were made: these are often where the expensive knowledge lives.
| Capability | Typical company brain product | A knowledge layer built on your data |
|---|---|---|
| Find documents across common apps | Strong | Not its main job |
| Answer lookup questions | Strong | Strong, within its scope |
| Resolve the same entity across systems | Limited, mostly people and documents | Core purpose |
| Know what is current vs superseded | Usually not recorded | Recorded and used |
| Answer multi-step relationship questions | Unreliable | Designed for it |
| Reach legacy systems and email archives | Limited by connectors | Scoped to where your knowledge is |
| Cite the source for each fact | Often, per document | Per fact |
Why the products have not built the missing part
It is not because the people building them are unaware of it. It is because the missing part is hard, unglamorous and specific to each organisation.
Resolving entities across systems means dealing with your particular mess: the four ways your team spells a key customer, the account codes that changed when you reorganised, the supplier that was acquired and renamed. A product has to generalise. Your mess does not. Every hour spent on one customer's quirks is an hour not spent on features that sell to a thousand customers.
So products sensibly build the horizontal part, search and summarisation across standard apps, and leave the vertical, messy part to the customer. That is a reasonable product decision. It just means you should not expect the product to do the part it was never designed to do.
The three-system test
Before you buy, or before you renew, ask the product one question that needs three of your systems to agree. Pick something real that someone in your business has had to answer by hand.
If the answer comes back as a list of documents that might be relevant, you are looking at search. Useful search, perhaps, but search. If it comes back as a correct answer, with each fact traced to its source, you are looking at something much closer to a brain.
Then ask the vendor four follow-up questions. How do you decide that two records describe the same customer? How do you know which document is current? Can I see the source for every fact in an answer? What happens to knowledge that lives outside your connectors? The answers will tell you more than any demo, and they are the same questions I work through in a knowledge audit.
What I would actually do
Buy for the majority of questions and build for the minority that matter most.
A good company brain product will handle lookup and discovery for most of your people most of the time. For the handful of processes where wrong answers are expensive (contracts, claims, quotes, compliance), build a knowledge layer on your own entities and relationships, one process at a time. The two are not competitors. A well-built knowledge layer can often feed the product you buy, through its connectors, and make its answers better.
I have spent 25 years turning messy signals into one live picture people can act on, from a maritime system that fused radar and vessel tracking in more than 30 countries to agentic AI that resolved 67% of an insurance brokerage's customer service cases. The part these products skip is the part that always took the sweat. It is also the part that made everything else work. I make the full case in your AI does not need a bigger model, it needs to know your business.
If you are weighing up a company brain product and want an independent view of what it will and will not do for your data, I am happy to help. Let's talk.
Related: Your AI does not need a bigger model. It needs to know your business · GraphRAG vs vector RAG. Which one does your business need? · You don't need to build a brewery to drink a pint of beer · Is your software AI-resistant?
