Company brain: what it is and how to build one for AI agents

A company brain is the shared, written memory of how a company works: its decisions, definitions, processes, customers and lessons, kept current and structured so that both people and AI agents can find it, read it and trust it.

It's the answer to questions like “what counts as an active customer here?”, “why did we drop the free plan?” and “who owns the billing export?”. Those answers usually live in someone's head, a chat thread from last spring, and three wiki pages that disagree. A company brain puts one current answer in one place, and records where it came from.

A few things a company brain is not:

• Not a model. The brain is the knowledge. The chatbot or agent that answers questions from it is an interface on top.
• Not a pile of everything. Indexing every email and chat message gives you search, not memory. A brain holds the distilled version: the decision, not the 200 messages that led to it.
• Not a personal notes app. A second brain serves one person's thinking. A company brain is shared, so accuracy, ownership and review matter more than speed of capture.

Companies have wanted a single source of truth for as long as there have been wikis. What changed is who reads it. AI agents now write code, answer customers, draft reports and run analyses, and every one of them needs company context to do that well.

A person works around missing context: they ask a colleague, remember last quarter, notice that a number looks off. An agent does none of that. It knows what's in its context window and nothing else, and most agents start every session from zero. Claude Code's documentation says it plainly: each session begins with a fresh context window, and what carries over is what's written in files, such as CLAUDE.md or AGENTS.md. If the context isn't written down, the agent guesses.

The second reason is that wikis rot. Andrej Karpathy's LLM Wiki note, published in April 2026, names the problem in one line:

“Humans abandon wikis because the maintenance burden grows faster than the value.”

His proposal: let the model do the bookkeeping. An agent reads raw sources, writes and updates interlinked markdown pages, and periodically checks them for contradictions, stale claims and orphan pages. People curate and ask questions. That idea, agents maintaining the knowledge instead of only searching it, is what separates a company brain from the wiki you already have. (Our LLM wiki guide walks through the pattern.)

The term spread from there, and today it covers hosted wikis with AI search as well as open-source projects that keep an agent's memory as markdown files in git. They differ most on the question Karpathy's note leaves to people: who checks what the agents wrote.

Whatever tool you use, a company brain has four jobs. Most setups do the first three reasonably well. The fourth is where they differ most, and it decides whether anyone relies on the answers.

1. Capture what matters

Knowledge has to get in without a person copying it by hand: meeting notes, decisions, support patterns, incident write-ups, changes to pricing or process. In practice this means agents that read the raw material and write or update the relevant document.

2. Stay current

A brain that was right in March is dangerous in September, because it sounds just as confident. Every fact that can change needs a date after which someone checks it again, and a way to find everything that depends on a fact when it does change.

3. Be queryable by people and agents

People need to browse and search it. Agents need to read it without a special integration for every tool: plain text, predictable structure, short descriptions they can scan before opening a whole document.

4. Be trustworthy

When agents write a large share of the content, every document has to answer four questions on sight:

• Who wrote it? A person, or an agent (and which one)?
• Who checked it? Has a person reviewed it, or only another agent, or nobody?
• Where did it come from? Which source backs each claim?
• Is it still true? When was it last confirmed, and when does it expire?

Without these, the brain slowly fills with plausible text that nobody verified, and people stop trusting any of it. An AI answer that cites an unreviewed, year-old document is worse than no answer, because it looks authoritative.

Hosted wiki plus AI search

The most common route: keep (or adopt) a hosted knowledge base and add an AI layer that searches it and your other tools. The products in this category differ in reach and in how much their AI may change:

• Enterprise search. Connects to hundreds of work apps (chat, shared drives, issue trackers, CRMs) and answers questions across them, showing each user only what they're allowed to see.
• Wikis with a built-in assistant. Answer questions from the wiki and some connected apps, and let their agents create and edit pages.
• Self-maintaining wikis. Watch your other tools, draft an update when a page goes out of date, and route it to a person to approve.

Good at: permissions, onboarding non-technical teams, searching everything at once, zero setup for most people. Weak at: the knowledge lives in a vendor's database, and coding agents working in a repo usually reach it through an API or MCP server rather than reading it directly. Search across raw sources also finds the conflicting chat thread as readily as the settled answer.

Vector store and RAG

Engineering teams often build their own: chunk documents, embed them, store the vectors, and retrieve the closest chunks at question time (retrieval-augmented generation). It's flexible and scales to huge corpora.

Good at: large, fast-changing collections; custom pipelines. Weak at: nobody can read a vector store. Contradictions sit side by side, retrieval returns whichever chunk scores highest, and there's no natural place to record who checked a fact or when it expires. You end up building a review layer on top anyway.

Markdown files in git, read directly by agents

The approach coding teams arrived at on their own: the knowledge is a folder of markdown files in a repository. Claude Code, Codex, Cursor and other agents read and edit the files with the same tools they use for code. A conventions file (AGENTS.md, an open format that agents.md lists as supported by Codex, Cursor and many other coding agents, or Claude Code's CLAUDE.md) tells them how the folder is organised. This is the shape of Karpathy's LLM wiki.

Good at: agents can read and maintain it with no integration, every change is a diff you can review, git gives you history and blame for free, and nothing is locked into a vendor. Weak at: no permissions beyond what the repository allows, no polished editor for non-technical colleagues, and git alone doesn't tell you which documents a person has checked.

None of these is wrong. If you have hundreds of employees, strict access rules and few people who open a terminal, a hosted wiki will serve you better. The rest of this page is about the third approach, because it's the one where agents do the maintenance, and the one Knowtarium is built for.

You can start this in an afternoon with a git repository and the coding agent you already use. The steps below follow the Open Knowledge Format (OKF), an open specification published by Google Cloud (v0.2 on GitHub) for markdown knowledge that agents write. The format doesn't depend on any tool, and while one or two people touch the folder, git diffs and a careful eye can be enough. Most steps note what Knowtarium adds.

1. Pick one painful area first

Don't try to capture the whole company. Pick the questions that get asked most or answered wrong most: pricing and plan limits, metric definitions, the release process, on-call runbooks. A brain that is right about ten things beats one that is vaguely right about a thousand.

2. Create the repository and a folder layout

One concept per file, grouped in folders that make sense to your team:

company-brain/
  AGENTS.md                 # the rules agents follow in this folder
  index.md                  # what's here, one line per document
  log.md                    # what changed, newest first
  company/
    glossary.md             # what we mean by 'active customer', 'churn', 'MRR'
    decisions/
      2026-08-pricing.md    # one decision per file, with the why
  product/
    plans-and-limits.md
    release-process.md
  meetings/
    2026-08-14-pricing-review.md
  customers/
    segments.md
    accounts/northwind.md
  runbooks/
    refunds.md
    on-call.md

index.md and log.md are reserved names in OKF: the first lists what a folder holds, the second records what changed. Agents read the index first, so they open only the documents they need.

3. Write the rules down for your agents

Put the conventions in AGENTS.md (and point CLAUDE.md at it if you use Claude Code). Keep it short and specific. Our guide to AGENTS.md for knowledge bases has a fuller version.

# Rules for this knowledge base
 
- One concept per file. Search before creating; update the existing file instead.
- Every file starts with frontmatter: type, title, description.
- When you write or change a file, set generated.by to your agent name and version.
- Never add yourself, or anyone, to verified. Only reviewers do that.
- Every factual claim cites a source with a footnote: [^source-id].
- Give fast-changing facts (prices, owners, limits) a stale_after date.
- Link related documents with markdown links from the bundle root: [Churn](/metrics/churn.md).
- Add one line to log.md for every change: date, file, what and why.

4. Record provenance in every document

The frontmatter is what makes the brain trustworthy. OKF defines fields for exactly the four questions above: generated (who wrote it, and when), verified (who checked it), sources (where claims came from) and stale_after (when it needs checking again).

---
type: Decision
title: Annual plans get two months free
description: Why annual pricing is 10x monthly, and when to revisit it.
status: stable
generated: { by: claude-code/2.1, at: 2026-09-20T09:12:00Z }
verified:
  - { by: human:sara, at: 2026-09-21T14:30:00Z }
stale_after: 2027-03-31T00:00:00Z
sources:
  - id: pricing-review
    resource: /meetings/2026-08-14-pricing-review.md
    author: human:sara
---
 
Annual plans cost ten times the monthly price.[^pricing-review]
We revisit this at the end of Q1, after the churn numbers are in.

Actors are named in a fixed form: an agent with its version (claude-code/2.1), a person (human:sara) or a process (process:billing-sync). A reader can then work out a document's trust level from the verified list instead of trusting a label. See how to make agents cite sources for the footnote convention.

5. Seed it from what you already have

Point an agent at your existing wiki export, meeting notes or a folder of decisions and ask it to write one document per concept, citing the source file for each claim. Expect duplicates and contradictions in the first pass. That's useful: they show you where your current documentation disagrees with itself.

6. Review every change before anyone relies on it

This is the step most teams skip, and the one that matters. Agents should open a pull request (or leave changes uncommitted) rather than write straight to the main branch. A person reads the diff, checks the cited source, and adds their own verified entry when it's right. The review in how to review agent edits covers what to look for.

It works in the other direction too. When a person edits a document by hand, say to change a price, other documents that mention the old price are now wrong. Ask an agent to check every connected document against the edit and propose fixes.

7. Put freshness on a schedule

Anything that can drift gets a stale_after date. Once a week, have an agent list documents past their date or expiring soon, re-check them against their sources, and propose updates. Documents nobody re-checks get marked status: deprecated rather than left to mislead.

8. Give every agent the same entry point

Coding agents that work in the repository read the files directly. For chat apps without file access, an MCP server over the folder can hand them documents on request. Either way, the agents read the same files people review, so there's one version of the truth.

Here's the same build with Knowtarium in the loop, following the pricing decision from the example above. Knowtarium doesn't replace your agent or your repository. It's where you see what the agent did and decide what counts as checked.

Open the company-brain folder in Knowtarium and run your agents in it with the included skill.

1. Let an agent write, then review the queue. Ask the agent to turn the pricing meeting note into a decision document. It arrives in the review queue as a diff, marked unverified. Read it, open the cited meeting note, and approve it: Knowtarium adds you to verified with the time. If it's wrong, send it back with a comment.
2. Edit a fact yourself, and have an agent check it. Say the annual discount changes. You edit the decision in Knowtarium, the change is marked as yours, and it waits in the queue for an agent check. Ask your agent to “check today's edits”: it reads the diff, follows links to documents such as plans-and-limits.md, and proposes fixes wherever the old number still appears. Those fixes wait for your review. Once both checks are recorded, the decision is fully verified.
3. Watch freshness. The decision expires on 31 March 2027. In the 30 days before that, the queue lists it; after that, it dims and shows as stale until someone refreshes it. A refresh is a new change, so it gets its own second look.
4. Share the folder through git. Commit and push. The verified entries travel with the files, so everyone who pulls sees who checked what, in any editor.

A markdown company brain is shared the way code is shared: through the repository. Everyone clones it, agents and people edit files, and changes arrive through commits and pull requests. Git provides the history, branching and merge conflicts; your git host provides access control.

This is also where it's worth being precise about what Knowtarium does and doesn't do.

• Knowtarium has no team features. There's no shared server, no accounts, no user permissions and no real-time collaboration. It doesn't sync; you share the folder with git.
• A license is personal. It's for one person, on up to 2 computers. Each person on your team who reviews documents in Knowtarium needs their own license.
• What people share is the files. When someone approves a change in Knowtarium, the app writes their name and the time into that document's verified list. Commit and push, and everyone who pulls the repository sees the review, whatever tool they open the file with.
• Not everyone needs it. Teammates who never review can read the files in their editor, browse them on your git host, or let their agents read them.

If you need per-document permissions, an admin console or live co-editing, Knowtarium isn't built for that. It's for the person, or the several people, who check what agents write.

• Ingesting everything. Dumping every channel and inbox into the brain buries the settled answers under the discussion. Capture decisions and definitions, and link to the raw material as a source.
• No provenance. Once you can't tell which documents an agent wrote and nobody checked, you have to distrust all of them.
• Agents approving agents. A second agent confirming the first is useful, but it isn't a person's review. Keep the two separate.
• No expiry dates. Pricing, owners, limits and org charts go stale in months. Without stale_after, stale documents look exactly like current ones.
• Citing things that disappear. A link to a chat message or a meeting that nobody recorded isn't a source. Save the source into the repository (as a meeting note or export) and cite the file.
• No owner. Someone has to read the review queue. If reviewing is everyone's job, it becomes nobody's.