Guide

What's inside a company brain?

The 9 parts strong B2B teams of 50 to 500 people are putting into their company brain, how they lay it out, and the one part most of them still miss.

8 min read · Updated November 2026

The short answer: a company brain is one place every person and every AI agent in the company reads from. The teams doing it well build it from 9 parts: connectors to the tools you already use, a start-here file, a knowledge base that keeps raw records apart from what you concluded, a map of your customers, people and projects, a decisions log, a skills library, one way in for every agent, permissions and source links that travel with every answer, and an upkeep loop that keeps it current. Most of them still miss one more: a customer layer that can count.

What a company brain is (and what it isn't)

A company brain is a shared, permissioned record of what your company knows, what it decided and how it does things. People and agents both read from it, and both write back to it.

It is not a chatbot on top of your wiki, and it is not one person's Claude setup. Search finds documents. A brain knows what they mean. A personal setup remembers for you. A company brain remembers for everyone.

Most teams arrive here the same way. They roll out Claude, ChatGPT or Cursor, and a few months later every person's AI knows a slightly different company. What one agent learned stays on one laptop. The company brain is the fix: one source, many agents.

The 9 components

We read about 40 write-ups and case studies from teams that built one, most of them between 50 and 500 people. The same parts come up again and again.

Component	What it holds	What breaks without it
🔌 Connectors	Live links to Slack, email, docs, CRM, call recorder, tickets and code. Mostly MCP today.	Agents answer from the two tools that are wired up and never mention the other eight.
🧭 Start-here file	What the company is, who's who, where things live, which source wins when two disagree.	Every session starts with "let me explain who we are".
📚 Knowledge base	Raw records (transcripts, notes) kept apart from synthesized knowledge (playbooks, policies, one topic per page).	A meeting transcript gets treated as the truth.
🧩 Entity map	Customers, accounts, people, products, projects, and how they link.	"Acme" in the CRM, the ticket tool and Slack are three different companies.
📝 Decisions log	What was decided, by whom, when, and what it replaced. Plus what agents learned.	Agents repeat a decision you reversed in March.
🛠️ Skills library	How work gets done: written, versioned procedures any agent can run.	Every person rewrites the same prompt, worse each time.
🚪 One way in	A shared MCP gateway or server, a Slack bot, a workspace for people who don't use a terminal.	Each agent needs its own integrations, and non-builders are locked out.
🔐 Permissions and sources	The agent sees only what the person asking can see, and every answer links to where it came from.	A salary file shows up in a sales answer, or nobody trusts any answer.
🔄 Upkeep loop	Owners per area, nightly clean-up, stale-content checks, a test set of questions.	It works for a month, then quietly goes stale.

🔌 Connectors

The brain is only as complete as the tools it can reach. Most teams now connect through MCP, so one connection serves every agent. nao Labs, a YC startup, now picks new tools partly on whether they have an MCP server, and calls connectors the bottleneck. At Assembled (about 120 people), one search across Notion, Drive, Slack, Gong and Salesforce was what got the whole company using it. Connect the source of truth before the discussion about it: the spec before the Slack thread arguing over it.

🧭 Start-here file

One short file every person and agent reads first: what the company does, who works here, how the folders are laid out, and which document wins when two disagree. It goes by many names (CONTEXT.md, CLAUDE.md, AGENTS.md, index.md). Keep it short. It is a map, not the territory.

📚 Knowledge base

The best setups keep raw records apart from conclusions. A meeting transcript is a record. What you learned from it, checked against other records, is knowledge. Write knowledge one topic per page, make each heading a question and put a date on anything that can go stale. Many small teams keep one folder per client or team, each with its own context and memory file.

🧩 Entity map

Documents talk about things: customers, accounts, people, products, projects. The brain needs one record for each, linked across tools, so "Acme" in the CRM, the ticket queue and Slack is the same Acme. The links are where the value is: the call connects to the deal, the deal to a product gap, the gap to a roadmap decision.

📝 Decisions log

Newest first, one line each: what was decided, who decided, when, and which earlier decision it replaces. Agents also write down what they learned, scoped to the person or team it belongs to, with a date so old lessons can expire. Without this, the brain knows what you wrote and forgets what you chose.

🛠️ Skills library

Knowledge says what is true. Skills say how work gets done: how to prep a call, triage a bug, write a battlecard. Teams keep them as versioned files, reviewed like code, in one shared folder that every agent (Claude Code, Codex, Cursor) reads. Ramp's internal library passed 350 shared skills. Once one person figures out the best way to do a task, everyone's agent can do it that way.

🚪 One way in

Connect once, serve every agent. Strong teams put one MCP server or gateway in front of the brain, so Claude, Cursor and in-house agents all get the same answer to the same question. They add a Slack bot or a shared workspace for sales, CS and leadership, who will never open a terminal. Some split read and write access, so agents can read freely and write carefully.

🔐 Permissions and sources

The agent should never see more than the person asking could. That means passing the person's identity through every lookup and filtering before the model reads, not hiding things in the answer afterwards. Every answer should link to the record it came from, and should say whether it is official, context, or the agent's own inference.

🔄 Upkeep loop

A brain nobody tends goes stale in weeks. The teams that last name an owner for each area, run a nightly job that files the day's notes and flags contradictions, check their instruction files for drift, and keep a set of test questions with known answers. One 400-person SaaS team kept 180 such questions, owned by sales enablement, and reran them on every change.

The part most company brains miss: the customer

A brain stores what was written down. Customers mostly say things out loud: on calls, in tickets, in chats. Those pile up faster than anyone can read them, and dropping the transcripts into the knowledge base doesn't make them countable.

Try this question on your setup: “How many customers asked for this last quarter, and what are they worth?” A retrieval setup returns a handful of similar snippets. It can't give you a count you'd defend in a roadmap meeting.

The customer layer has its own jobs: process every conversation, group the same need across sources, link each need to the accounts and revenue behind it, and cite the clip every claim came from. The brain has the documents. The heart listens to the customer.

How strong teams lay it out

We saw three layouts. They differ by who uses the brain most.

A shared repo of plain files

Most common under 100 people, and in builder-heavy teams. A start-here file, a memory file, one folder per team or client, a skills folder and the MCP settings, all in Git. Changes are reviewed like code.

Repo plus tables

Decisions and notes stay as text. Heavy data (lead lists, transcripts, usage) goes into a database the agents query. Good when volume outgrows files.

A platform over your tools

More common from about 100 people, when non-builders are the main users. Connectors, search and agents live in one workspace. Assembled runs this way on Dust, Intelligems on Type.

A typical repo layout:

company-brain/
├── START-HERE.md      what we do, who's who, which source wins
├── MEMORY.md          lessons true for the whole company
├── decisions/         one line per decision, newest first
├── customers/         one folder per account
├── teams/             sales, marketing, product, cs
├── skills/            how work gets done, one file per skill
└── connections/       MCP settings and how to use each tool

Who owns it at 50 to 500 people

One central owner for the plumbing. Connectors, the gateway and permissions. At this size it's usually one product ops or AI ops lead, not a team.
Each team owns its own content. Sales owns the sales playbook, CS owns the support runbook. Nobody owns everything, and every area has someone accountable for it.
A regular show-and-tell. Assembled runs a monthly AI Collective where people share the agents and skills they built. That is how good skills spread.

What to build first

Remember first, reason second, act third. Start with connectors, the start-here file and one team's knowledge. Then do real work in it from day one and add context only when a task needs it, so the brain holds what you use instead of everything you own. Agents that act on their own come last, once the memory underneath them is reliable.

Check your company brain

Component	Ask
🔌 Connectors	Can it see every tool where customers and decisions show up?
🧭 Start-here file	Can a new hire's agent tell which pricing doc is current?
📚 Knowledge base	Is what you concluded kept apart from raw notes?
🧩 Entity map	Does each customer have one record across your tools?
📝 Decisions log	Can it tell you what you decided last quarter, and who decided?
🛠️ Skills library	When someone finds a better way to do a task, does everyone's agent get it?
🚪 One way in	Can sales use it without a terminal?
🔐 Permissions and sources	Does every answer link to its source, under the asker's permissions?
🔄 Upkeep loop	Who notices when it goes stale?

And the one most setups fail: can it count how many customers asked for something, and what they're worth?

How Evermuse fits

Evermuse is the customer layer for your company brain. It processes every call, ticket, chat and note into a structured model of what customers need, counts the customers and accounts behind each need, and links every answer to its source. Your agents reach it through MCP. Your team uses the same answers in one shared workspace. We maintain the pipeline.

Deciding whether to build that layer yourself? Read Build or buy a company brain? and What is a product context layer?

FAQ

What are the components of a company brain?

Connectors, a start-here file, a knowledge base, an entity map, a decisions log, a skills library, one shared way in for agents, permissions and source links, and an upkeep loop. Teams that build products also need a customer layer that can count what customers ask for.

Do I need a vector database to build one?

Not to start. Many teams run on plain files, Git and MCP. Search becomes important once the content outgrows what an agent can read in one go, and counting customer requests needs more than search.

Is a Git repo enough for a company brain?

For a builder-heavy team under about 100 people, often yes. It gets hard when non-builders need it, when permissions differ by person, and when you need counts across thousands of customer conversations.

Who should own the company brain?

One central owner, often in product ops or AI ops, for connectors, access and permissions. Each team owns its own content and skills.

How is a company brain different from enterprise search?

Search finds documents. A company brain also holds the entity map, decisions, skills and memory, and agents write back to it.

How do AI agents get into the company brain?

Through one MCP server or gateway that passes the user's identity, so every agent gets the same answer under the same permissions.

Ask how many customers asked. Get a number.

Connect your calls, tickets and chats. Evermuse counts every request, ties it to the account, and links every answer to its source.