A company brain is a single, maintained store of what an organisation knows about itself, kept in a form that people can read and AI agents can retrieve as working context.
That means the material a business runs on and rarely writes down properly: who the ideal customer is, how pricing works, how a deal moves through the pipeline, what was decided about the roadmap in March and why. Most of it lives in chat threads, slide decks and the heads of four people. A company brain is the decision to give it one address.
The phrase is new enough that people use it loosely, so this post pins it down: what a company brain is made of, how it differs from the things it gets confused with, why the idea is arriving now, and how to build one with whatever tools you already have.
What is a company brain made of?
A company brain is made of files, not a database. In almost every implementation it is a folder of plain text documents: one document per concept, a small block of structured metadata at the top of each file, and links between them.
Each document carries:
- a body written for a person to read
- a type: customer profile, pricing policy, decision record, runbook
- a title and a one-line description
- a few tags drawn from a vocabulary the team agreed
- an owner, and a date somebody last checked it
- links to the other documents it depends on
None of that requires special software. The dominant shape is Markdown with YAML frontmatter (a text file with a fenced metadata block at the top), because it stays readable in any editor, diffs cleanly in version control, and needs no parser you had to write yourself. Google's Open Knowledge Format now formalises that same shape as an open standard, which is a reasonable signal that it's the one to build on.
The links matter more than they look. One file per concept, with explicit links between concepts, produces a graph, and a retrieval system can walk a graph. It can't walk a 40-page handbook.
How is a company brain different from a wiki?
A wiki is written for people to read. A company brain is written to be retrieved, by people and by machines, and every document in it has someone responsible for keeping it true.
Most wikis fail the same way. They get written in a burst, organised by whoever set them up, and then nobody is accountable for any individual page. Six months later the pricing page is wrong, and the only person who would notice is the one who stopped reading it.
A wiki can go stale without consequence, because nothing downstream depends on it. A company brain can't, because something does: an agent reads it and acts on it. That one change, a machine consuming the document, forces properties a wiki never needed: retrievable units instead of long pages, explicit metadata instead of context you were expected to already have, a named owner instead of collective goodwill, and provenance, so you can tell what a person vetted apart from what a model asserted.
This isn't a case for deleting the wiki. The wiki was written for a reader who could fill in the gaps, and your agents can't.
How is a company brain different from a knowledge base or a RAG pipeline?
A knowledge base and a RAG pipeline are both about retrieval. A company brain is about the source. A support knowledge base is written for customers and scoped to product questions, so it holds almost none of the internal knowledge an agent needs. A RAG pipeline is a technique for finding relevant passages in a corpus, so it presupposes a corpus worth searching. The company brain is that corpus.
| Written for | Kept current by | How a machine gets at it | |
|---|---|---|---|
| Company wiki | People | Whoever remembers | Scraping, or a bulk dump |
| Support knowledge base | Customers | The support team | A public API or help widget |
| RAG pipeline | A model | A re-indexing job | Embeddings and nearest-neighbour search |
| Company brain | Both, from one file | Named owners, plus agents writing back | Direct retrieval over the source documents |
Retrieval-augmented generation is a real and useful technique, and a company brain is a perfectly good thing to point a RAG pipeline at. The mistake is treating retrieval as the whole problem. Embed a corpus of stale, unowned, contradictory documents and you get fast access to stale, unowned, contradictory documents. Worse, the chunks arrive stripped of any sign of which one was current.
RAG is how a machine finds a document. It says nothing about whether the document was worth finding.
Why is the company brain surfacing as a category now?
The company brain is surfacing now because the limit on useful AI moved from the model to the context, and because assistants finally have a standard way to reach outside data. Four things changed in the last two years.
Models stopped being the bottleneck. Current models reason well, follow instructions and use tools reliably. What they lack is your company's specifics, which is a supply problem, not a capability one. We wrote about that shift in why your AI agents keep forgetting what your company knows.
A standard connector arrived. The Model Context Protocol (MCP) is an open standard that lets an assistant call an external tool or data source. Claude, ChatGPT and Gemini all speak it. Before a common protocol existed, you couldn't build "one context store that every assistant reads". You built a connector per vendor, or you pasted.
The file shape settled. Markdown with YAML frontmatter went from a convention among engineers to something being written down as a standard. Google's Open Knowledge Format formalises it: no proprietary schema, nothing you couldn't open in a text editor.
The market named it. Y Combinator named the company brain in its Summer 2026 Request for Startups. That's usually when a category stops being a niche opinion and starts getting crowded, which is a good reason to understand the idea on its merits rather than through whoever markets it hardest.
What belongs in a company brain?
A company brain holds knowledge that is specific to your company, stable enough to be worth writing down, and needed by more than one person or agent. In rough priority order:
- Who you sell to. Ideal customer profile, segments, and the customers you deliberately turn away.
- What you sell. Positioning, packaging, pricing, what's on the roadmap and what was cut on purpose.
- How work moves. The sales process, the support escalation path, the release checklist, the onboarding sequence.
- Decisions and their reasons. Nobody writes down the reason, and it's the part an agent needs most, because it stops the same argument being relitigated every quarter.
- Your vocabulary. What your team means by "activation", "account" or "qualified". Agents get this wrong constantly, and confidently.
- The rules. Brand and voice, legal boundaries, claims an agent may never make.
What doesn't belong:
- Anything that changes hourly: live metrics, ticket queues, inventory. Point at the system of record instead.
- Secrets and credentials.
- Raw transcripts and meeting dumps. A brain holds what you concluded, not everything that was said.
- General knowledge. The model already knows what GDPR is. It doesn't know your data retention policy.
How to build a company brain, step by step
To build a company brain, start with about ten documents that are true, give them owners, and connect one agent. The first version takes an afternoon. The maintenance never ends, and that's the right ratio.
Step 1: Write down the ten things you re-explain most
Don't start with a taxonomy. For one week, note every time you paste context into a chat or explain something to a new hire for the second time. That list is your first ten documents, and it will be uncomfortably obvious: the ICP, the pricing, the two objections, the thing about how the trial works.
Ten documents that are true beat four thousand migrated pages. A bulk migration is the single most common way this goes wrong, because it fills the store with content nobody has vetted and wrecks your ability to trust any answer that comes out of it.
Step 2: One document per concept, named for the concept
Each file covers one thing, and its title says what that thing is. The reason is mechanical, not aesthetic: a query returns documents, so the document is the unit of precision. "Company Handbook" returns a handbook. "Pricing and packaging" returns pricing.
If a document needs the word "and" twice in its title, it's two documents.
Step 3: Put the machine-readable facts at the top
Give every document a small structured header. Markdown with YAML frontmatter is the default for good reason, and the fields that carry weight are unglamorous: type, title, description, tags, owner, updated.
The description field does more work than anything else. A retrieval layer ranks on titles and descriptions before it opens a single body, so a one-line description that says what the document contains is the difference between an agent finding the right file and finding a plausible one. Tags let a query narrow the candidate set before search runs at all.
Step 4: Agree a small vocabulary and stop there
A handful of document types and one short tag list is enough. The usual failure is a sixty-tag scheme designed in week one and abandoned in week three. A useful test: if you can't hold the whole tag list in your head, nobody will apply it consistently, agents included.
Two or three tiers is plenty of structure. Tatara ships an Area / Topic / Goal split.
Step 5: Connect the agents over MCP
Point the assistants your team already uses at the store instead of copying content into each one. MCP makes that connection, and you set it up once per tool, not once per conversation.
To test whether it worked, change a fact in one document, then ask a fresh chat in a different tool. If the new answer is right and nobody pasted anything, you have a company brain. If not, you have a folder.
Step 6: Give every document an owner and a review date
A company brain dies of staleness, not bad structure. Every document needs a named human owner, and every owner needs a cadence: quarterly is enough for most things, monthly for pricing and positioning.
Ownership of the whole store is a separate question, and the answer is one person, not a committee. Early on that's usually a founder, a chief of staff or whoever runs operations. "Everyone owns it" reliably means nobody does.
Agents can and should write into the brain, because they run into new facts constantly. The condition is that agent writes are governed and attributable: required fields, so a write can't be a shapeless note, and provenance on every save, so you can always tell whether a human or a model put a claim there.
What makes a company brain fail?
A company brain almost always fails through staleness, and staleness is a symptom of one of these:
- Nobody owns it. The most common failure, and it looks fine for about four months.
- It was migrated, not written. Four thousand imported pages of unknown accuracy make every retrieval result untrustworthy, including the good ones.
- The structure is bigger than the content. Forty folders and twelve documents means somebody designed a system instead of writing down what they know.
- Agent writes go unchecked. If you can't tell what a person vetted from what a model asserted, the store turns into a pile of confident text and you stop relying on it. This one gets worse the more useful your agents become.
- It's locked in a format only one tool can read. Knowledge you can't take with you is rented, and it won't survive your next change of tool.
- It's run as a documentation project. A brain is an operating habit with a review cadence. It isn't a quarter-long initiative with a completion date.
Every company brain that failed, failed the same way: it was true on the day it was written, and nobody was responsible for the day after.
What does a company brain look like in practice?
In practice, a company brain is a folder of Markdown files with YAML frontmatter, one file per concept, wikilinks between them, and an MCP endpoint the assistants point at. That's the whole shape, and you can assemble it yourself from a git repository and an open-source MCP server. Plenty of teams do, and it works.
Tatara is one implementation of that shape. It exists because the assembled version has three parts that are tedious to build and easy to get wrong: keeping documents readable for people while staying parseable for machines, keeping agent writes governed rather than freeform, and letting people who don't work in git keep the whole thing current.
Here's what that looks like in the product. Documents are plain Markdown you could open anywhere. Agents connect over MCP and read the same brain from any client that speaks it. Every agent write must carry a type, a title, a description and tags, steered to your taxonomy. A write without them is rejected with an instructive error, so agents correct themselves instead of writing rubbish. Every save is stamped with who or what made it, so an agent can't pass itself off as a person. A document can also be given a format, and then it opens as a board, a task tracker, a typed table, a filtered view or a mind map. It stays one Markdown file underneath, so nothing gets converted. The free tier holds 500 documents and doesn't ask for a card; pricing and the documentation cover the rest.
Whichever tool you pick, the more useful framing is this: a company brain is a decision about where your company's knowledge lives and who is responsible for keeping it true. The tool comes second. Governed documents and an end to pasting context are what that decision buys you.
The test isn't whether the brain is complete. It's whether you can name the owner of any document in it, and whether the last thing an agent read from it was true.
