A new account executive asks: "What did we promise Acme last quarter?" Nobody knows off the top of their head. The answer exists — in a Slack thread, a Gmail draft, a HubSpot note — but finding it takes twenty minutes and two people. That is the problem a company brain solves, and the clearest way to understand what goes inside one is to start with the questions.
Key takeaways
- A company brain is a living knowledge layer that ingests from the tools your team already uses and makes that knowledge queryable by both people and AI agents.
- The most useful company brain examples are not about storing documents — they are about answering specific questions that would otherwise require hunting across three or four apps.
- Sources divide into four categories: communication (Slack, Gmail), structured records (CRM, accounting), documentation (Notion, Drive), and code/ops.
- Permissions matter as much as ingestion: not every answer should be visible to every person or agent.
- A company brain that stays current is fundamentally different from a wiki or a search index over stale files.
What a company brain actually is
A company brain is a living knowledge layer that captures what an organization knows, keeps it current, and makes it queryable by both humans and AI agents. It ingests from the tools a team already uses — Slack, Gmail, Notion, HubSpot, Google Drive, QuickBooks, Salesforce — organizes that knowledge with permissions and provenance, and surfaces the right context at the moment it is needed.
The distinction that matters: a wiki is static. A search index returns documents. A company brain returns answers, with the source attached, from data that is kept current as the underlying apps change.
As vectorize.io's breakdown of company brain architecture puts it, the key difference from a vector store or RAG pipeline is that a company brain consolidates contradictions rather than returning whichever chunk scored highest in embedding space. The right answer is resolved once, not re-derived approximately on every query.
The four source categories
Every question a team asks maps to one or more source types. Getting the categories right is what determines whether the company brain can actually answer the question.
Communication: Slack and email
This is where most decisions actually happen and where most knowledge gets lost. A Slack thread from three months ago contains the real reason a pricing decision was made. A Gmail chain has the commitments made to a customer before the deal closed. Neither shows up in the CRM.
Communication sources are high-value and high-volume. The practical approach is selective indexing: index channels and threads where decisions get made, not every message in every channel.
Structured records: CRM, accounting, ticketing
HubSpot, Salesforce, and QuickBooks contain facts with dates attached — deal stages, invoice amounts, support ticket histories. These are the sources that answer financial and customer-status questions precisely. They are also the sources most likely to have permission requirements: not everyone should be able to query revenue figures or customer contract terms.
Documentation: Notion, Confluence, Google Drive
This is where teams store what they intended to remember. The problem described in the Nano Thoughts post on building a company brain for a year is that documentation goes stale fast. A process doc written eight months ago may describe a workflow that no longer exists. Indexing documentation without tracking when it was last verified produces confidently wrong answers.
Code and ops: GitHub, Jira, runbooks
Engineering teams need a company brain too. "What does this service do?" and "who owns the payments module?" are questions that should be answerable without paging someone. Repos, pull request descriptions, and issue histories are valid sources — scoped to the engineering team.
Company brain examples: questions and the sources that answer them
The clearest way to understand what goes in a company brain is to map real questions to real sources. These are the kinds of queries teams actually type.
Sales and customer success
"What did we commit to Acme before they signed?"
Sources: Gmail (pre-close email thread), HubSpot (deal notes, meeting logs), Slack (channel with the account owner).
"Has Acme ever raised a billing issue?"
Sources: HubSpot (support ticket history), Slack (customer channel), QuickBooks (invoice history).
"What is our standard SLA for enterprise customers?"
Sources: Notion or Google Drive (contract templates, CS playbook).
"Which deals are stuck in proposal stage and why?"
Sources: HubSpot or Salesforce (deal stage, last activity date, notes).
Engineering
"Who owns the payments service?"
Sources: GitHub (CODEOWNERS file, recent commit history), Notion (service registry), Slack (engineering channels).
"Why did we choose Postgres over MySQL for the main database?"
Sources: Notion (architecture decision records), Slack (engineering thread from the decision period), GitHub (PR descriptions).
"What broke in last Tuesday's deploy?"
Sources: GitHub (commit history, PR), Jira (incident ticket), Slack (on-call channel).
"What does the data pipeline do and when was it last changed?"
Sources: GitHub (repo README, recent PRs), Jira (tickets referencing the pipeline).
Operations and finance
"What did we spend on AWS last quarter vs. the quarter before?"
Sources: QuickBooks (vendor spend), Slack (finance channel discussions), Google Drive (budget spreadsheets).
"What vendors are we paying for that fewer than three people use?"
Sources: QuickBooks (recurring vendor payments), Notion or Drive (tool registry if one exists).
"What is our current headcount and when did the last hire start?"
Sources: HR system if indexed, Slack (announcements channel), Notion (team page).
People and onboarding
This is where the company brain pays off most visibly. Claire Gouze's account of building a company brain for a YC startup describes the core problem: a new hire's first two weeks are spent asking questions that were answered months ago in threads nobody can find. The company brain makes those answers retrievable without interrupting anyone.
"What is our deployment process?"
Sources: Notion (engineering runbook), GitHub (contributing guide), Slack (engineering channel history).
"Who do I talk to about getting access to the staging environment?"
Sources: Notion (team directory, onboarding doc), Slack (ops or IT channel).
"What is our policy on customer data in staging?"
Sources: Notion (security policy), Google Drive (compliance docs).
"What tools does the company use and what is each one for?"
Sources: Notion (tool registry), Slack (announcements channel), Google Drive (onboarding guide).
Strategy and leadership
"What did we decide at the last board meeting?"
Sources: Google Drive (board deck, meeting notes), Notion (strategy docs), Gmail (board communications, scoped to executives).
"What is the current product roadmap and what changed last month?"
Sources: Notion (roadmap doc), Jira (epics and milestones), Slack (product channel).
"What have customers asked for most in the last 90 days?"
Sources: HubSpot or Salesforce (call notes, feature request tags), Slack (customer success channel), Jira (feature request tickets).
What makes a source useful vs. noise
Not every data source deserves to be indexed. The Sentra guide to building a company brain makes the point that a bi-temporal knowledge graph — one that tracks when a fact became true and when it stopped being true — is what separates a useful company brain from a search index over stale documents. The same principle applies at the source level.
A source is worth indexing when:
- It contains decisions, commitments, or facts that people ask about repeatedly.
- It updates when reality changes (a live CRM record, not a PDF export from six months ago).
- It has a clear owner and is maintained as a matter of course.
A source is noise when:
- It is a one-time export or a document nobody has opened in a year.
- It duplicates information that is more reliably maintained elsewhere.
- It contains sensitive data that cannot be appropriately permissioned.
The permission layer is not optional. A company brain that surfaces executive compensation data to a junior contractor, or customer PII to an AI agent without access controls, creates a different kind of problem. The answer to "what did we pay the CFO last year" should only be available to people who have that access in the underlying system.
What breaks when the sources go stale
The most common failure mode is not a bad query — it is a correct-sounding answer drawn from outdated source material. As the Gyld explainer on what a company brain has to do notes, content drift, deleted sources, and permission rot are the three things that break a company brain after the first year.
Content drift: a process doc describes how things worked before a reorg. The doc is still indexed. The answer is wrong.
Deleted sources: a Slack channel gets archived. The decisions made in it are gone unless they were captured somewhere else before archival.
Permission rot: someone leaves the company. Their Gmail and Slack history remains indexed. Whether their messages should still surface in queries is a policy question that most setups do not answer automatically.
The practical implication: a company brain needs a mechanism for keeping sources current, not just a one-time ingestion. This is what separates a managed knowledge layer from a RAG pipeline you build once and forget. For a deeper look at why stale context causes agents to give wrong answers, see why AI agents give wrong answers about your business.
How AI agents use the same sources
The questions above are ones a person types. The same sources answer the same questions when an AI agent asks them — provided the company brain exposes its knowledge in a format agents can consume.
This is where the Model Context Protocol matters. An MCP server built on top of a company brain lets an agent running in Claude, ChatGPT, or Cursor query the same permissioned, source-cited knowledge that a human would get. The agent asking "what did we commit to Acme?" gets the same answer from the same sources as the account executive asking the same question in a chat interface — with the source attached so the answer can be verified.
For more on how agents consume company context through MCP, see what a managed company brain looks like on your own apps and the post on how to ground AI in your company data.
Frequently asked questions
What is a company brain, in plain terms?
A company brain is a knowledge layer that ingests from the apps a team already uses — Slack, email, CRM, docs — and makes that knowledge queryable by people and AI agents. The key difference from a wiki or search index is that it stays current as the underlying apps change and returns answers with source citations, not just documents.
What sources should go into a company brain first?
Start with the sources that answer the questions your team asks most often. For most companies, that means the CRM (customer and deal history), Slack (decisions and context), and one documentation tool (Notion or Google Drive). Add more sources once those are working well and kept current.
How is a company brain different from a knowledge base or wiki?
A wiki is static — someone has to update it manually, and it goes stale. A company brain ingests from live systems and updates as those systems change. It also returns answers with provenance (which source, from when) rather than returning a document and asking the reader to find the relevant part.
Can a company brain answer questions about past decisions?
Yes, if the sources that captured those decisions are indexed. A Slack thread from six months ago, a Gmail chain before a deal closed, or a Notion doc with a decision record can all be queried. The limitation is that decisions made verbally or in unindexed channels are not recoverable.
Who should have access to what in a company brain?
Permissions should mirror the underlying systems. If a finance document is restricted to the finance team in Google Drive, queries against that document should be restricted to the same group in the company brain. A company brain that collapses permissions is a security problem, not a knowledge tool.
How do you keep a company brain from going stale?
By indexing from live sources rather than one-time exports, by tracking when source documents were last updated, and by having a process for flagging or removing content that is no longer accurate. The sources that go stale fastest are documentation and process docs — these need the most active maintenance.
Can AI agents use the same company brain as human employees?
Yes, when the company brain exposes its knowledge through a protocol that agents can consume — such as MCP servers. The agent queries the same permissioned, source-cited knowledge that a human would, with the same access controls applied. This is what makes agent answers verifiable rather than hallucinated.
Related reading
- Why AI Agents Give Wrong Answers About Your Business (And How to Fix It) — the root cause is almost always missing or stale context, not model quality.
- How to Ground AI in Your Company Data (So Agents Stop Guessing) — practical steps for connecting live sources to AI queries.
- The Four Types of Enterprise AI Context Agents Actually Need — a framework for deciding what context to give agents and when.
- Why AI Agents Go Rogue — And How Company Context Fixes It — what happens when agents act without grounding in real company knowledge.
If the questions in this post sound like the ones your team is already asking, the sources that answer them are probably already in the apps you use. Start building your company brain with Gyld and connect the first source in a few minutes — no pipeline to build, no fine-tuning required.