Published 4 November 2026. Every product description below was read from the vendor's own page or post on 4 November 2026.
A company brain is a shared memory layer that pulls what a company knows out of the places it is written down, such as Slack, Notion, meeting notes, docs, tickets and code, keeps it as facts that stay current, and serves those facts to people and to any AI assistant with the source attached. The connectors that pull the data in and the database that holds it are the part every launch video shows, and they are the easy part. Whether a company brain can be trusted depends on five things it has to know about every fact it keeps: who may see it, when it was true, what to do when two sources disagree about it, where it came from, and when it has to be forgotten.
The term moved from essays into product launches this autumn. On 3 November 2026 Merge introduced its Universal Context Layer, which it calls "a self-improving company brain that every AI tool or agent can draw on"; the same day SurrealDB launched SurrealDB 4 as "the database and memory for every agent", and Atlan opened its Context Conference with the line "Rent the intelligence but own the context." Cognee published its own definition on 29 October. Supermemory went the other way: it discontinued its company brain product on 10 September and open-sourced the code on 25 September, saying it wanted to focus on the memory system itself. An integrations company, a database company and several memory companies now sell the same idea, which is a good reason to be precise about what the idea requires.
What is a company brain?
A company brain is a persistent, shared memory of how a company works: its decisions, its processes, who owns what, what was agreed with which customer, and what changed last week. It is built from the company's existing tools rather than written by hand, it is kept current as those tools change, and it is exposed to people and AI agents through an API, an MCP server or a chat interface, so that any assistant answering a question starts from what the company already knows.
Slite's guide defines it as "a persistent context layer", and that is a fair one-line version. The word that matters is persistent. A company brain is not a search over documents at the moment of asking; it is a maintained store of facts that someone (or something) is responsible for keeping right.
Company brain vs wiki, enterprise search, RAG and a vector store
Most confusion about the category comes from treating these as the same thing. They sit at different layers.
| What it holds | Who keeps it current | What it answers well | Where it breaks | |
|---|---|---|---|---|
| Wiki (Notion, Confluence) | Pages people wrote | People, by hand | "What is our documented process?" | Pages go stale and nobody is told |
| Enterprise search | An index of documents | The indexer, on a schedule | "Where is the doc about X?" | Returns ten documents that disagree |
| RAG | Chunks retrieved at answer time | Nobody; it reads whatever is indexed | "What does the text say about X?" | Cannot tell the 2024 answer from the current one |
| Vector store | Embeddings and metadata | The pipeline that writes to it | "What is similar to this?" | Has no idea of truth, time or permission on its own |
| Company brain | Facts with scope, dates and sources | A pipeline that extracts, reconciles and expires facts | "What is true now, for this person, and how do we know?" | Only as good as its reconciliation and permission model |
A company brain usually contains a vector index and often a knowledge graph, and it usually reads from the wiki. What it adds is the maintenance: deciding which statements are facts, which fact is current, and who is allowed to see each one.
What goes in a company brain, and what stays out
In: decisions and the reasons behind them, processes as they are actually run (not only as documented), ownership (who owns the billing service, who is the account lead for a customer), commitments to customers and partners, definitions the company uses ("an active user means..."), and pointers to where the live state of something can be checked.
Out: the live operational state itself. The open ticket count, a deployment's status and an invoice's payment status change by the minute, and copying them into memory produces a second, staler copy. Supermemory's write-up of its harness makes the same split: durable organisation knowledge goes to memory, while connected tools such as Linear and GitHub are queried live to verify current status, because ingesting everything into one store, in its words, "increases stale info and confuses the model a lot." Secrets and credentials stay out entirely. Raw transcripts can be kept as source material, but the brain should store what was decided in the meeting, not the forty minutes of discussion.
A personal brain (one person's notes, or a single assistant's memory of one user) can skip most of what follows, because there is one reader and one author. A company brain has many readers with different access, many authors who contradict each other, and a legal obligation to forget some of what it holds. That difference is the whole design problem.
Why connectors and storage are the easy part
Connecting to Slack, Notion, Google Drive, Jira and a meeting recorder is a solved problem; Merge's context layer launched with synced connectors for file storage, ticketing and HRIS, and Cognee Cloud lists Google Drive, Slack, GitHub, Jira, Salesforce and Zendesk as sources. Storing the output is also solved, in Postgres, a graph database or a vector index. What a connector delivers, though, is text with a timestamp and an author. It does not say whether the statement is still true, whether it overrides an older one, who else may read it, or whether the person who wrote it has since left and asked for their data to be erased.
Suppose an engineer asks an assistant which region a customer's data must stay in. A Slack thread from March says "EU only". A Notion page last edited in January says "EU or UK". A sales call transcript from last week mentions the customer is "fine with UK now". A system that only connects and stores will retrieve all three, rank them by similarity and let the model pick, which is how an assistant ends up confidently quoting the January page. A company brain has to resolve that before the question is asked.
What a company brain has to know about every fact: scope, time, conflict, provenance and forgetting
Scope: who may see what
The rule is that an agent should see exactly what the person behind it is allowed to see, and nothing more. Merge states it in nearly those words for its launch: "Each request runs under your employees' permissions, so an agent sees what the person behind it would see, and nothing more." Supermemory's open-sourced harness scopes memory by where it was learned: public-channel knowledge goes to an organisation-wide scope, a direct message to a per-user scope, and a private channel or group DM to a scope for that channel, so a fact said in a private channel does not surface in a public one.
The hard part is derived facts. If the brain reads a private HR channel and a public engineering channel and concludes "the platform team is losing two people in December", that conclusion must carry the stricter of the two permissions, not the looser one. Cognee's guide makes a related point worth repeating: it carries permissions with ingested data, offers dataset-level permissions on top, and tells readers to "test permission behavior for each connector you plan to use before relying on it in production." Permission has to be checked at retrieval time, per fact, against the source's current access list, because a person who loses access to a Notion page on Tuesday should stop getting answers built from it on Tuesday. The same scoping questions come up between agents, which we cover in multi-agent shared memory.
Time: when a fact was true
Every fact needs at least two dates: when it was true in the world (valid time) and when the brain learned it (recorded time). "Our refund window is 30 days" said in a 2025 doc and "we moved to 14 days in September" said in Slack are not a contradiction; they are one fact with a history. SurrealDB's Agent Memory page describes three clocks per fact (system time, known time and, where the source gives it, valid time) and says a new value closes the old value's validity instead of overwriting it, so the system can answer what it believed on a given date. Without valid time, an assistant cannot answer "what was the policy when this customer signed?", which is the question auditors and support leads actually ask. We go into the two-clock model in knowledge graph vs vector search for agent memory.
Conflict: what to do when Slack says one thing and Notion another
Sources disagree all the time, and a company brain needs a written policy for it; leaving the choice to the model at answer time is how the stale answer wins. The policy usually combines three inputs: source authority (a signed contract outranks a Slack message; a policy page owned by legal outranks a team wiki), recency within the same authority level, and who said it (the account owner's statement outranks a guess from someone outside the account). Vectorize's guide describes the same three options as recency-weighted, source-weighted and policy-driven reconciliation, and Falconer designates canonical sources and flags drift when other sources contradict them.
The part most systems skip is what to do when the policy cannot decide. SurrealDB's page says its reconciler lets corrections supersede, while "disagreement below the floor is recorded as uncertainty" and not applied. That is the right default. For the data-residency example above, the honest answer is "the January page says EU or UK, a March Slack thread says EU only, and last week's call suggests UK is now acceptable; the contract has not been checked", not a confident pick. A brain that can say it does not know is more useful than one that always answers.
Provenance: where each fact came from
Every fact the brain serves should point back to the message, page, transcript span or record it was extracted from, with the author and the date. Merge says its agent "answers with its sources"; SurrealDB says each fact keeps its source, the span of text it came from and a confidence score; Cognee lists answer provenance among its Enterprise features. Provenance does three jobs: it lets a reader check an answer, it lets the conflict policy rank sources, and it is the only way to find every derived fact that has to go when a source is deleted. A fact without provenance cannot be corrected or erased reliably, so it should not be stored.
Forgetting: what has to go, and how far the deletion reaches
A company brain has to forget for three different reasons, and each needs its own mechanism. Facts go stale and must be withdrawn, not just outranked, or they come back the first time ranking shifts. People leave, and what an agent wrote on their behalf (summaries, embeddings, cached tool results, shared team memory) stays readable after their access is revoked unless offboarding reaches memory too; we wrote up that checklist in AI agent deprovisioning. And some data has to be erased on request, which under GDPR means reaching the derived facts and embeddings built from it, not only the original message. SurrealDB separates a forget verb, which retires a fact so it is no longer recalled, from a purge that removes the history as well, which it says is what erasure requires; Cognee's SDK has a forget operation but its guide does not state how far a deletion propagates. That propagation question is the one to ask any vendor.
A company brain architecture checklist
| Layer | What to decide | What fails if you skip it |
|---|---|---|
| Ingestion | Which sources, at what frequency, with their access lists and authors attached to every record | Permissions and provenance cannot be rebuilt later |
| Extraction | What counts as a fact, a decision, an owner, a definition; what is discarded | The brain becomes a second copy of Slack |
| Reconciliation | Source authority order, recency rules, and what happens below the confidence floor | Contradictions reach the model and it picks one |
| Time | Valid time and recorded time on every fact; supersede instead of overwrite | No "as of" answers; history is lost on every update |
| Scope | Per-fact access list inherited from the strictest source; checked at retrieval | Private facts leak through derived summaries |
| Live state | Which questions are answered from memory and which from a live tool call | Stale ticket counts and statuses served as fact |
| Retrieval | Filter by scope and validity before ranking by relevance | Relevant but forbidden or outdated facts reach the prompt |
| Provenance | Source, span, author, date on every fact and every answer | Answers cannot be checked, corrected or erased |
| Forgetting | Withdrawal of stale facts, offboarding, erasure that reaches derived data and backups | Revoked or erased data keeps answering questions |
| Writes from agents | Which agents may write, what needs human approval, how writes are labelled | One wrong agent conclusion becomes company truth |
The last row deserves a note. Merge's launch has the system work overnight and leave recommendations "for an admin to approve or decline", and Supermemory's harness suspends a turn and posts approve or deny cards in Slack before consequential tool calls. Approval for actions is becoming standard; approval for what gets written into shared memory is the less discussed and more important half, because a bad write is read by every agent afterwards.
How to test a company brain before you trust it
Vendor demos ask easy questions. These tests ask the ones that break company brains, and each can be scripted with a small seeded workspace and an answer key. The general method (seed histories with known answers, grade the store, retrieval and final answer separately) is in how to test agent memory before you ship.
- Permission leak. Put a fact only in a private channel. Ask about it as a user outside the channel, directly and indirectly ("summarise what the platform team is worried about"). Pass: the fact never appears, including in summaries.
- Revocation. Remove a user from a Notion page, then ask a question only that page answers. Pass: the answer is withheld within the sync interval the vendor states.
- Supersession. State a policy in a doc, change it later in Slack. Ask for the current policy and for the policy as of a date before the change. Pass: both answers are correct and each cites its source.
- Unresolvable conflict. Seed two sources of equal authority that disagree. Pass: the answer reports the disagreement and cites both sources without picking one.
- Authority order. Seed a casual Slack claim that contradicts a document owned by the responsible team. Pass: the owned document wins, and the answer says so.
- Provenance check. For twenty answers, open the cited source. Pass: every citation exists, says what the answer claims, and is the version that was current.
- Erasure reach. Delete a person's messages through the erasure path, then ask questions whose answers were derived from them. Pass: no derived fact, summary or embedding still answers.
- Live state. Ask for something that changes hourly, such as an open-incident count. Pass: the answer comes from a live call or says it cannot be answered from memory, not from a stale stored value.
Run the same suite after every connector change, because permission behaviour often differs from one connector to the next, as Cognee's guide itself warns.
Build or buy: what to ask a vendor
Building a company brain in-house means owning connectors, extraction, reconciliation, a temporal store, a permission model and an erasure path, and the last four are where the engineering time goes, long after the connectors work. Buying one means trusting someone else's answers to the five questions above. Either way, ask for specifics: whether permissions are checked per fact at retrieval or per dataset at ingestion; whether facts carry valid time; what happens when sources of equal authority disagree; whether every answer carries source, span and date; and how far a deletion propagates. A vendor that answers all five with documentation rather than a roadmap is worth a pilot. Atlan's keynote line, "Rent the intelligence but own the context", is a useful test of the contract too: if the company cannot export its facts, dates, sources and permissions in a usable form, it does not own the context, it rents that as well.
Frequently asked questions
What is a company brain in AI?
A company brain is a shared, persistent memory of how a company works, built from its tools (Slack, Notion, docs, tickets, meeting notes, code) and served to people and AI assistants with sources attached. It differs from search and RAG because it maintains facts over time: it decides which statement is current, who may see it, and when it must be forgotten.
What is a context layer for AI agents?
A context layer is the service an AI agent calls to get company-specific knowledge before it answers or acts. "Context layer" and "company brain" are used for the same thing in current launches; Merge calls its company brain a Universal Context Layer, and Slite defines a company brain as a persistent context layer. Either name should mean scoped, dated, sourced facts, not just a search index.
Is a company brain the same as RAG?
No. RAG retrieves passages at answer time and leaves the model to work out which one is current and correct. A company brain does that work before the question: it extracts facts, reconciles conflicts, records when each fact was true and applies permissions per fact. A company brain often uses retrieval internally, but RAG on its own has no notion of supersession or ownership.
Does a company brain need a knowledge graph?
Not always, but it needs what a graph usually provides: entities (customers, services, people), relationships between them, and dates on those relationships. A vector index alone can find similar text but cannot tell you that one fact replaced another. Teams with many entities and frequent changes tend to need the graph; a small team answering policy questions may not.
Can a company brain take actions?
Some products now let agents act on what the brain knows, and the pattern settling in is human approval for consequential steps. Merge collects overnight recommendations for an admin to approve or decline, and Supermemory's open-sourced harness pauses a turn for approve or deny in Slack. Writes into shared memory deserve the same gate, since every later agent reads them.
Does a small team need a company brain?
A team of a few people who share every channel can usually manage with a well-kept wiki and an assistant with project instructions, because there are no permission boundaries and conflicts get settled in conversation. The need appears with different access levels, sources that disagree, sensitive or regulated data, or agents that act on the company's behalf, which matches the line Slite and Vectorize both draw in their guides.
Who owns the data in a company brain?
The company should, in a form it can export: facts, their dates, sources and permissions, not just raw documents. If a vendor holds the reconciled facts in a format that cannot leave, switching vendors means rebuilding the brain from the raw sources again.
Sources
All retrieved 4 November 2026.
- Merge, "Introducing the Universal Context Layer: a company brain that works with every AI tool and agent", Shensi Ding: https://www.merge.dev/blog/universal-context-layer ; launch post, 3 November 2026: https://x.com/merge_api/status/2117649727835525382
- SurrealDB, SurrealDB 4 launch post, 3 November 2026: https://x.com/SurrealDB/status/2117662416091648196 ; Agent Memory: https://surrealdb.com/agent-memory
- Atlan, Context Conference opening keynote post, 3 November 2026: https://x.com/AtlanHQ/status/2117617848822407306
- Cognee, "What Is a Company Brain? Definition, How It Works, and Uses", 29 October 2026: https://www.cognee.ai/what-is-a-company-brain
- Supermemory, post open-sourcing its company brain and describing the multiplayer harness, Dhravya Shah, 25 September 2026: https://supermemory.ai/blog/open-sourcing-company-brain/ ; blog index (10 September 2026 discontinuation notice): https://supermemory.ai/blog/
- Slite, "What is a Company Brain? A full guide for 2026", 31 July 2026: https://slite.com/learn/company-brain
- Vectorize, "How to Build a Company Brain for AI Agents", 1 June 2026: https://vectorize.io/articles/how-to-build-company-brain
- Falconer, "What is a company brain, and why you need one", 28 April 2026: https://falconer.com/guides/what-is-company-brain
