Short answer
A company brain is the layer where a company's knowledge lives so people and AI agents can both use it. It is built one of two ways: a search index over the apps you already use, like Glean, or written pages the company owns that agents can also write back to. Only the second survives the vendor contract.
A company brain is the place a company's knowledge lives so that both people and AI agents can use it. In 2026 it gets built one of two ways: as a search index over the apps the company already runs, or as a written layer of documents the company keeps and its agents can write back to.
Both get sold under the same name, and they are not the same purchase. An index finds what is already scattered across Slack, Drive and the ticket tracker. A written layer is where the answer gets settled once, in a page that someone, or something, maintains. The question that separates them is short: when the agent works something out, where does it write it down, and who owns that page when the vendor contract ends?
What is a company brain?
Slite's guide to the term, published on 31 July 2026, defines it as "a persistent context layer. It gathers knowledge from wherever a company creates it, and it makes that context usable by both people and AI agents." That is a fair definition, and it is wide enough to cover two quite different architectures.
The term took off because of agents. A person can ask a colleague where the pricing decision was made. An agent cannot. It only knows what it can reach in the moment it runs, so a company that wants agents doing real work has to put its knowledge somewhere an agent can read it, under rules about who may see what.
A company brain is not the same thing as a team second brain, though they overlap. A team second brain is the shared notebook a group writes in together. A company brain is the company-scale question of where all of it lives and what reaches it: every team's notes, every agent's access, and who governs both.
Index or written layer: which kind of company brain do you need?
Here are the two architectures side by side.
| Index over your apps | Written layer you own | |
|---|---|---|
| What it holds | Pointers into Slack, email, Drive, tickets, wikis | Pages the company writes and keeps current |
| How knowledge gets in | Connectors pull it automatically | A person or an agent writes it |
| What an agent can do | Search and read | Search, read, and write back |
| When two sources disagree | You get both, and pick | Someone fixes the page once |
| Where it lives | The vendor's index | Files the company holds |
| Examples | Glean | Karpathy's LLM wiki pattern, Baalda |
Glean is the clearest example of the first kind. As read on glean.com on 27 October 2026, it describes itself as "the Enterprise AI platform connected to your enterprise's data", says it "Connects to work apps and data sources" with a figure of 275+, and promises "permission-aware access built in from day one". If your knowledge already exists across a hundred tools and nobody is going to rewrite it, an index is the honest answer, and it is very good at what it does.
The second kind starts from a different observation. Retrieval over raw sources hands the model fragments that contradict each other, and the model has no way to know which one is current. Andrej Karpathy's LLM wiki pattern, covered in the Karpathy LLM wiki post, answers that by having a model compile raw sources into maintained pages, so the next reader gets the settled version. Second brain vs RAG is the longer argument for when a team needs an index at all.
Most companies end up wanting both. The useful question is which one is the brain and which one is the search box in front of it.
Who owns a company brain when the contract ends?
This is the question the vendor guides skip, and for a company it is the one that matters most.
An index is the vendor's. It is built on the vendor's servers from your data, and the thing it adds, the ranking, the connections and the permission map, goes away when the subscription does. Your source documents survive in Slack and Drive. The brain does not, because the brain was the index.
A written layer survives only if it is written somewhere the company holds. That is where Baalda comes in. It is a team second brain built as plain markdown files on your own disk, with real-time multi-user editing, and the code is open source under Apache-2.0, so the server can be self-hosted with no licence key. The company brain in that setup is a folder of .md files. Cancel anything you like and the folder still opens in any text editor, and every agent that can read files can still read it.
Can an AI agent write back to a company brain?
This is the second dividing line, and it is the one that decides whether the brain gets better over time or just gets bigger.
An index is read-only by design. The agent searches, answers, and whatever it worked out disappears with the session. The next agent, or the next person, starts over from the same scattered fragments.
In Baalda, agents work on the same files as everyone else. A local agent such as Claude Code edits the .md files on disk directly, with no integration needed, and the change syncs live to the team. A cloud agent that cannot reach your disk connects to the server's MCP endpoint at /api/mcp with a token created under Vault settings, then MCP. The MCP setup guide has the steps. Registering it in Claude Code against a self-hosted server looks like this:
claude mcp add --transport http context https://your-server/api/mcp \
--header "Authorization: Bearer mcp_…"From there the agent gets the tools a person would use: search_notes, read_note, create_note, and edit_note for targeted changes at exact anchors. read_note returns a revision number, and passing it back as expectedRevision makes the server refuse a write to a note that a colleague changed in the meantime, rather than quietly merging over them. If the note is open in the app, people watch the agent's edit arrive as it types.
So when an agent works out why a customer churned, it can append that to the account page rather than leave it in a chat transcript. The next agent reads the page, not the transcript.
Who decides what each agent can reach?
An agent connected to everything is a liability, which is why "permission-aware" is the line every vendor in this category leads with. The useful version of that promise is specific: the agent sees what the person it acts for can see, and nothing else.
That is how Baalda's MCP endpoint works. Agents get a vault through the same per-folder permissions that govern people. Access is set per folder or per file to Can edit, Can view or No access, for everyone or for named members, and an owner or admin can do it from the app or through the manage_access tool. list_resource_access shows every member's effective access to one folder or file. list_access_audit lists access and membership changes in the vault, newest first, with who made each change, when, and the values before and after.
In practice that means the finance folder can be No access for the contractor, and the contractor's agent cannot read it either, because it connects as the contractor. Nobody configures the agent separately. There is one permission map, and people and agents both sit inside it.
Where Baalda is the wrong company brain
Be plain about what this kind of brain does not do.
- It does not pull from your other tools. There are no connectors to Slack, Gmail, Drive or your ticket tracker. Nothing enters the brain unless a person or an agent writes it there. If your company will not write things down, an index like Glean is the better buy.
- No SSO or SAML in the open core. The repository reserves an
ee/directory, under a separate commercial licence, for features such as SSO and SAML, and describes them as future commercial features. A company that needs single sign-on today should check that before planning a rollout. - It is not enterprise search. It searches the vault, including text extracted from attached files such as PDFs and spreadsheets. It does not search the rest of your stack.
- Markdown is not a database. If your company's knowledge is really relational tables with views and rollups, a database tool fits better.
The honest shape for many companies is both: an index to find what is scattered, and a written layer, owned by the company, where the answers get settled and the agents write back. Only one of those is still yours the day you stop paying.