A company brain AI is an assistant that finds and uses what a company knows across chat, documents and connected tools. It is good at the first layer of that knowledge: what people said. The other 4 layers, what words mean, who may approve what, what the systems recorded and what people do without saying it, have to be written down or connected before any brain can use them.
The search problem behind it is real. In Atlassian's State of Teams 2025 survey of 12,000 knowledge workers and 200 executives, "leaders and teams waste 25% of their time just searching for answers" (Atlassian, 2025). A company brain promises to cut that time. This article is about what it cannot find, because nobody wrote it anywhere.
I came to this while setting up Claude Code agents for marketing at EmpoweredHouse, agents that share one memory in files. To make them useful, I had to write down what no chat history held: which words the company avoids, which actions need a person's yes, and which facts no agent may invent. That is the lens I use here.
Company brain AI is moving up to the board
In October 2026 McKinsey described what it calls an AI operating system as "a second brain for the enterprise", a layer that "maintains enterprise context (that is, the knowledge that gives data meaning)". The same article cites McKinsey's 2026 State of AI survey: 40% of respondents at large companies report scaling AI agents, yet only 6% say AI generates at least 5% of EBIT (McKinsey, October 2026).
McKinsey puts context first. This article looks at where that context sits in a company of 50 to 300 people, before any system can read it.
What a company brain AI does well
On 26 September 2026 Supermemory open-sourced Company Brain. Its README describes it as "a teammate in your Slack" that remembers "decisions, projects, owners and context from the channels it's in" and reaches other tools over MCP. The code is free under the Apache 2.0 licence and runs on Cloudflare Workers; memory goes through a Supermemory API key, and the language model through a provider key that you pay for directly.
The part that matters for this article is access. The README says memory is "a permissions graph", and the brain "only ever reads with the asker's own access". When a request needs a tool that only a teammate has connected, it asks that teammate first with an approve or deny card.
For a team that decides in threads, this means the decision from March can be found in October, with the thread that led to it. That is real value, and it covers 1 of the 5 layers below.
"No one has to write anything down" is true for 1 layer of 5
That line sits in the Company Brain README, next to its promise to remember decisions from channels. For what people say in a channel, it holds. For the rest of what a company knows, someone still has to write it down, or connect the system that holds it.
The gap shows in 2 places. Access and authority differ: reading with the asker's access settles what a person may see, and what that person may approve is a separate question. Being able to read an order gives nobody the right to change its delivery date. Meaning is the second gap: a brain can recall every thread about "late orders" and still not know whether late means past the promised date or past the requested one.
The 5 layers of company knowledge
The way I sort it, company knowledge comes in 5 layers. This is my working model for finding missing context, not an industry standard, and the layers overlap: a rule can be mentioned in Slack, written in a policy and built into a system.
| Layer | What it is | Where it lives | What a chat-based brain gets |
|---|---|---|---|
| Said | Decisions, projects and owners mentioned in channels | Chat and threads | This layer, well |
| Meant | What "active customer" or "late order" means in this company | A glossary or data model, if anyone wrote one | Only what someone said about it |
| Allowed | Who may approve a refund, change a price or skip a step | Roles, limits and approval rules | What the asker may see, not what they may approve |
| Happened | What the systems recorded when the work was done | ERP, CRM and other records | What its connected tools expose |
| Done, never said | The steps people take without talking about them | In people's hands | Not from chat; system records show what, not why |
5 layers of what a company knows. Memory of chat reaches the first.
The point is not to file every fact under exactly 1 layer. It is to see which layer is missing when someone, or something, has to explain a decision or act on it. In my view the second and third layers decide whether an answer is right.
One supplier change, 5 kinds of knowledge
An illustration. A manufacturer switches the supplier of 1 component. The buyers discuss it in Slack: said. The company's definition of a late supplier, 3 missed dates in a quarter, sits in a quality procedure: meant. The operations manager approves the switch because the order is above the buyer's limit: allowed. The ERP records the new purchase order: happened. And the planner adds a week to the new supplier's quoted lead time, because the old supplier missed its dates and nobody expects the new one to do better yet: done, never said.
A company brain built on chat finds the first. A connected ERP gives the fourth. The definition, the limit and the planner's extra week sit elsewhere, and those 3 decide whether the next supplier change goes the same way.
Tribal knowledge: the layer that retires with your best people
Tribal knowledge means what people in a company know about how the work gets done that is not written down. Other names for it are undocumented knowledge and know-how, and the term itself draws objections; the thing it names is the same.
In manufacturing it is the setter who knows which press needs a longer warm-up after the weekend, or the planner who knows which supplier's quoted lead time nobody believes. In finance it is the controller who knows which customer pays on the 40th day and is not chased for it. None of it gets said in a channel, because the people who know it do not need to say it to each other.
Few companies capture it before it leaves. In a global survey of 1,000 organisations by APQC with eGain, only 8% said they consistently capture knowledge from employees who retire, and 16% do not try at all (APQC, September 2025). Retirement is the easy case, because the date is known in advance.
Some of this knowledge leaves traces. A machine log shows the late start, and the ERP shows the missed delivery date. The trace says what happened; the reason the setter waited or the planner added a week is missing from it. That reason sits with the person, and when they leave, it leaves with them.
Why AI projects stall before the model matters
Gartner describes the same problem from the data side. In its survey of 1,203 data management leaders, 63% of organisations either do not have or are unsure if they have the right data management practices for AI, and Gartner predicts that "through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data" (Gartner, February 2025). Among its recommendations are metadata management and AI governance: in the terms of this article, layers 2 and 3.
A company brain makes the first layer searchable. It does not make the other 4 ready.
Run the 10-decision test
I would start with this before choosing any tool. Take 10 decisions your company made last month: a discount, a delayed order, a supplier change, a hire, an exception to a rule. For each one, answer 4 questions in a table. The 2 rows below are an illustration.
| Decision | Said in a channel? | Reason written anywhere? | Rule behind it written? | Authority on record? |
|---|---|---|---|---|
| Discount for a late delivery | yes | no | no | no |
| Supplier switched for one part | no | no | no | yes, in the purchase order |
Then read the columns. The first is what a company brain built on chat can recall. The other 3 are what it needs to answer why, and whether the same decision is allowed next time. Where they stay empty, the brain will remember that something happened without knowing why, and an AI agent will have no basis to tell who may repeat it.
Step 2: check the answers against the work
A filled row is still only a claim. For 2 or 3 of the decisions, open the system record and ask the person who did the work whether the written rule is the one they used. Where the record, the rule and the person disagree, you have found the layer to fix first.
| Most common gap | Where to start |
|---|---|
| Decisions not recorded anywhere | A decision log with the date and the owner |
| Reasons missing | 1 line of reason per decision in that log |
| Rules or definitions missing | 1 definition per term, agreed with the person who owns it |
| Approver unclear | A table of who may approve what, up to which amount |
| Record and practice disagree | Watch the step with the person who does it |
Where the other 4 layers can live
In my experience, each layer needs a home that a person builds before any AI reads it. For a company, I would start here:
- Meaning: 1 definition per business term, agreed with the person who owns the term.
- Authority: roles written as rules rather than habits: who may approve what, up to which amount. Limits that matter belong in the system that carries out the action, not only in an AI prompt.
- Records: they stay in the systems that keep them, connected rather than copied.
- The work nobody says: a process map drawn with the people who do it, by watching the work rather than reading the chat, and checked with them afterwards.
At EmpoweredHouse we call these homes, written down together, a business contract: a description of a process that the business can read, with its terms, rules, events and who decides. The PNS Method is how we shape it with a company.
Our company brain is a Git repository
McKinsey's example is a scenario at a global insurer. At around 100 people the same idea starts smaller. The company brain I rely on most is a repository of plain text files (Markdown) we call the Company OS, and its starter kit is public under the MIT licence (company-os on GitHub). Its README draws the same line as this article: "The OS owns intent and operating rules. Live state belongs in systems of record such as CRM, Linear, GitHub Issues, accounting, analytics, calendar, Slack, or other operational tools."
In the terms of the 5 layers, the repository holds meant and allowed: our terminology, the claims we may make, the words we avoid, who decides what, and company decisions as numbered files. Happened stays in the tools that record it. Said stays in Slack until someone turns a thread into a decision.
3 habits make it work for people and agents:
- Every file has a status. Accepted, draft or archive, with an owner and a date. Agents read accepted files by default, so a half-finished idea does not become a rule.
- Changes go through a pull request, a proposed change that someone reviews before it counts. When we decided in October that the word "platform" is allowed when we describe ourselves, it was 1 reviewed pull request. Every agent that started a session after the merge read the new rule; nobody had to repeat it in a chat.
- Drafts stay apart from accepted context. Generated drafts sit in an output folder until a person moves them into the accepted context.
What it changed for me: a new agent session starts from the same context as the last one, a decision made once does not get argued again in the next thread, and a fact about our product carries its status, so a plan does not get presented as a shipped feature. What it costs: someone has to keep the register current. When a decision lives only in a call, the repository is out of date, and the agents repeat the outdated version with full confidence.
My marketing company brain: 14 AI agents and 3 shared files
On top of the Company OS, our marketing works as 14 Claude Code agents, one per area, from brand and website to copy, graphics, community and analytics. Each works in its own session, and they coordinate through 3 shared files rather than a chat:
- A state file. 1 row per department: what it is working on and what is blocked. Every session starts by reading it.
- A findings log. When one agent learns something another needs, it writes 1 line addressed to that department.
- An orders file. A coordinating agent asks a department for work there, and the department changes only the status in its own row.
2 more files keep what they write true:
- A facts register. Every product claim sits on 1 line with a status (works today, internal test, in progress, vision) and a note on whether a developer has signed it. An agent may only write what the register allows.
- A rule on the day of a rejection. When I reject a draft, the reason becomes a rule in the file the agent reads next, so the same mistake does not come back.
The Company OS above holds what stays true for months. These files hold what changes every day. None of it needed a platform. It needed someone to decide what each term means and who may approve what: layers 2 and 3 above. I have tested this only in marketing. For an operations team I would expect something similar to help, with stronger controls than a shared file where money or customers are involved. The full setup, including what broke, is in my multi-agent orchestration case study.
FAQ
What is a company brain in AI?
A company brain is an AI assistant that finds and uses what a company knows across chat, documents and connected tools, and answers from it. Supermemory's open-source Company Brain, for example, lives in Slack and reaches other tools over MCP.
What is the difference between a company brain and a knowledge base?
A knowledge base holds documents people wrote on purpose. A company brain also picks up what was said along the way and answers in conversation. The 2 overlap, and a company brain is only as good as the definitions and rules it can read.
What does tribal knowledge mean in business?
Tribal knowledge is what people know about how the work gets done that is not written down. It lives in habits, exceptions and judgement, and it leaves when the person does.
How do you capture tribal knowledge?
I would watch the work rather than the chat. Sit with the person who does the step, write down the rule they use to decide, and ask them to correct it. Then put it where people and systems can read it.
Is a company brain the same as an AI operating system?
Not quite. McKinsey uses "AI operating system" for a wider layer that also reasons across functions and recommends decisions. A company brain is the memory part of it: what the company knows and where that knowledge sits.
Can a company brain replace documentation?
In my view it replaces searching old threads. It does not decide what a term means or who may approve an exception; somebody writes that down first, and the brain then reads it.
If the reason and rule columns of your test stay empty, a company brain will give you a faster search of the past and little context to decide with. Start with the layer that is missing. If you want to work through your 10 decisions with people who run a process in another company, apply to Empowered Community: the founding group starts on 1 December 2026, and applications close on 27 November.
Facts checked against the Company Brain README, McKinsey, Atlassian, APQC and Gartner on 19 October 2026.
