Company brain: what it is and 5 ways teams build one

Updated 9 min read

A company brain is one store of a company’s knowledge that people and AI agents both use, and that stays current without anyone cleaning it up by hand. The term is new and loose. It gets used for enterprise search, retrieval over documents (RAG), memory APIs, assistants that query live tools, and wikis that agents write and maintain. These setups differ in when the work happens and what gets stored, so they cost different amounts and fail in different ways. Most teams that get one working combine two of them.

What does “company brain” mean?

Slite’s guide 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.” Slite traces the term through about a year: Foundation Capital’s essay on context graphs (December 2025), Andrej Karpathy’s LLM wiki (April 2026), Garry Tan’s open-source GBrain, and a “Company Brain” entry in Y Combinator’s Summer 2026 Request for Startups. Citing its own statistics, Slite reports that 70% of teams know the term and 20% have one.

The Substack series Nano Thoughts’ “Company Brain” splits the idea into factual, interaction and action memory. Its point about interaction memory applies to every setup below: a ticket records the outcome, but the reason for it lived in a conversation.

The term took off because of agents. A person who is missing context can ask a colleague. An agent knows what it was given at the start of the session and nothing more, so once a team runs several agents, each one needs the same answers to “how does billing work”. Our context engineering guide covers what to load into an agent’s context.

What are the ways to build a company brain?

Five architectures go by the name. They differ mainly in when synthesis happens: at question time, at write time by an extraction model, or at write time by an agent editing pages.

Architecture Example What it stores Synthesis happens Good at Breaks when
Enterprise search Glean An index of your existing tools On every question Finding anything across many apps, per user’s access The answer is a decision nobody wrote down
RAG Your own pipeline Embedded chunks of documents On every question Lookups in large collections A newer document replaces an older one
Memory API Mem0, Zep Short facts per user, session or agent When messages are added Per-user memory inside a product Knowledge has reasons and parts
Connectors An assistant calling MCP servers Nothing of its own On every question Current state of tickets and docs The same question comes back next week
Agent-written wiki Karpathy’s LLM wiki, Dexio Pages agents write and edit When a source or finding arrives Decisions, how systems fit, research A page is wrong and nobody reads it

Enterprise search: Glean

Glean indexes the tools a company already uses and answers from them. Its site lists more than 250 connectors (Slack, Jira and GitHub among them), an assistant, an agent builder, and “permission-aware” access so users “only see what they’re allowed to see”. The homepage shows no price and points you to a demo instead.

Glean is the better pick when a large company’s knowledge sits in dozens of tools with different access rules and the main need is finding it. The limit is the one Slite names: enterprise search “never did” maintain anything. “It fetched.” If the reason for a decision sits in a 200-message Slack thread, search finds the thread, but someone still has to read it and work out the conclusion.

Retrieval over documents (RAG)

RAG splits documents into chunks, indexes them, and pulls the best matches into the model’s context for each question. Nothing is written back. In the one public head-to-head with numbers that we found, summarized in LLM wiki vs RAG, hybrid RAG answered 13 of 13 questions, mostly lookups, at an average of 1,407 tokens each; a wiki got 12 of 13 at 13,055.

RAG breaks on knowledge that changes. A March decision and the June reversal sit in the index with equal weight, and the model sorts them out on every question. Questions that need several documents together also suffer, because the model sees only the top few fragments.

Memory APIs: Mem0 and Zep

Memory APIs pull facts out of conversations and hand back the relevant ones before the next model call. Mem0’s README says it keeps user, session and agent state. Its pricing page lists Hobby free (10,000 add and 1,000 retrieval requests a month), Starter at $19 a month, Pro at $249 (which adds graph memory) and custom Enterprise, and there is an open-source version. Zep builds a context graph with temporal memory. Its self-serve plans are Flex at $125 a month with 50,000 credits and Flex Plus at $375 with 200,000, and it gives 10,000 free credits a month for prototyping.

These are the better pick for a product that must remember things about each of thousands of users. As a company brain they have two gaps: extraction splits a conversation into separate facts and often loses the reason that tied them together, and people cannot easily read or correct thousands of embedded facts. Wiki memory vs fact memory runs one conversation through both, and Mem0 alternatives compares 11 memory layers.

Supermemory, another memory API, sold a product it called the supermemory company brain. Its blog says it discontinued it in September 2026 and refunded everyone it had charged. A later post says the company brain is now open source.

Connectors: an assistant that queries your tools live

The lightest setup gives an assistant access to your tools over MCP and lets it look things up when asked. See our guides to Claude connectors, Notion MCP and Atlassian MCP.

Connectors are good at current state, such as what a ticket says right now. They store nothing, so each question repeats the lookups and pays tokens for them, and whatever the assistant concluded is gone when the chat ends. They can only report what someone wrote in a tool, so a decision made on a call is out of reach.

An agent-written wiki (Karpathy’s LLM wiki)

Karpathy’s gist describes a “persistent wiki” of markdown pages between people and their raw sources. When a source arrives, the model updates the pages it touches and notes “where new data contradicts old claims”. He names a business version: “an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls.” People abandon wikis, he writes, because “the maintenance burden grows faster than the value”, and in his version a model does the bookkeeping. Our guide to Karpathy’s LLM wiki covers setup.

In this setup a decision and its reason sit on the same page. People can read and correct what the agents believe, and every agent starts from the same conclusions. The writing costs tokens: in the evaluation in our RAG guide, building a 60-page wiki took about 194,000 tokens and each new source 3,000 to 5,000.

Mistakes persist, though. In that evaluation, pages had merged two tenants’ policies, so a question from one tenant got the other’s quotas, and a page like that keeps repeating the error until someone fixes it. Pages also fall behind when nobody feeds the wiki. The wiki needs search early, too: Karpathy says an index file works “at moderate scale (~100 sources, ~hundreds of pages)”. Several agents we run share one wiki, which held 107 pages and 565 links between them on 12 October 2026. In another workspace we run, agents wrote 189 pages on its first day. With agents writing, plan for search over the pages from the first week.

Which company brain should your team use?

  • Knowledge spread across dozens of SaaS tools with strict per-person access: enterprise search or a managed product. Slite argues for a managed one once access levels differ, sources disagree or agents can take actions.
  • A large document archive, mostly lookups: RAG.
  • A product that remembers each customer: a memory API such as Mem0 or Zep.
  • People mostly need the current state of tickets and docs: connectors may be enough.
  • Several agents and people need the same decisions and picture of how systems fit, and you want to read what the agents believe: an agent-written wiki.

These setups combine well. In a common pattern, agents read the wiki first, use connectors for live state, and write back what they concluded so the next agent can read it.

How do you build a company brain?

  1. List the 20 questions your agents and new hires ask most, to see which knowledge dominates: decisions, live state or customer facts.
  2. Pick a store for each: pages for decisions and how things work, connectors for live state, a memory API for per-customer facts.
  3. Write a short schema for your agents. In Karpathy’s version it lives in CLAUDE.md or AGENTS.md (see our CLAUDE.md guide).
  4. Connect every agent your team runs to the same store.
  5. Have a person read the most-used pages each week, and ask an agent to find contradictions and stale claims.
  6. Keep boundaries explicit: customers or teams in page paths, or separate workspaces for pages some people must not see.

A schema section can be this short:

## Company wiki
- Before answering a question about how we work, search the wiki and read what it finds.
- Record decisions on the page for that system or project: date, reason, link to the source.
- Update the existing page instead of creating a near-duplicate.
- Customer-specific details go under customers/<name>/ only.
- When a page is replaced, set `status: deprecated` on it and link to the new page.

Dexio: a company brain your agents write

Dexio is a hosted wiki that agents read and write over MCP. Claude Code, Codex, Cursor, Hermes Agent, OpenClaw, Claude, ChatGPT and other MCP clients connect to one wiki of linked markdown pages, and people see what the agents know as a page graph at app.dexio.wiki. Every change is kept with the agent that made it, the person whose account or API key it came through, and a note when the agent leaves one. PDFs, decks and spreadsheets can sit beside the pages, and search finds the text inside them. The whole wiki downloads as markdown any time.

It is free for one person, and $10 (Team) or $20 (Business) a member a month. Agents never count as members, and there are no usage charges. Dexio is open source (AGPL-3.0), and you can run your own copy.

Where it fits less well: everyone in a workspace, and every agent connected to it, can read the whole wiki, so knowledge some people must not see needs its own workspace. For per-person permissions across dozens of tools, enterprise search is the better fit. Dexio does not index your Slack or Drive, so pair it with connectors for live state, and run RAG beside it for semantic search over a large archive.

To connect an agent that runs commands, send it this:

Connect yourself to my Dexio wiki. The steps are at https://dexio.wiki/agents.md: read the whole file, not a summary, and follow them.

Setup for each agent is in the Claude Code memory guide and the rest of Guides.

FAQ

Is a company brain the same as a company wiki?

A company wiki is written by people for people. A company brain is read by agents too, and in the wiki version agents do most of the writing. Our company wiki guide covers structure, tools and upkeep.

Is a company brain the same as a second brain?

No. A second brain belongs to one person. A company brain has several owners and sources, and the people using it have different access. See AI second brain.

Do you need a vendor to build a company brain?

No. Karpathy’s pattern is markdown files and an agent, RAG can be built from open-source parts, and Mem0 has an open-source version. A vendor sells hosting, sharing across a team, and permissions.

Sources

Ask a question

Ask anything about Dexio.

About
We reply by email.