Blog
What is a company brain?
Published: September 23, 2026
A company brain is a shared system that captures what a company has decided, from the places it actually decides (chat threads, code review, meetings, docs), keeps those decisions current, and hands the relevant ones to people and AI agents at the moment they need them. For an engineering team, its busiest reader is now the coding agent.
What does company brain mean?
The phrase describes a job, not a file format. A wiki is where someone writes down what they remember to write down. A company brain starts from the other end: it reads the conversations where the decision was made, turns them into short statements, and keeps a record of where each one came from and whether it still holds.
The term has become a startup category in 2026. Hyper launched on Hacker News as “Company brain to power agentic development” (YC P26). Memory Store's YC company page opens with “Company Brain. One memory for your team's agents.” Almanac (YC S26) launched as “AI that knows your company”. The comment threads under those launches are worth reading for the objections, which are the real specification. One commenter on the Hyper thread put the central one plainly: context that is right on Monday is quietly wrong by Friday, and nobody notices until a decision gets made on it.
Why does an engineering team need a company brain?
Because agents start every session knowing nothing about the team. The Claude Code docs say it directly: “Each Claude Code session begins with a fresh context window.” What carries over is what you put in an instruction file and what the agent wrote into its own memory. Both are narrow. Claude Code's auto memory is machine-local, not shared across machines (checked 2026-09-23). GitHub's Copilot Memory keeps repository facts per repository and deletes any that go unused for 28 days.
Meanwhile the decisions that shape the code are made somewhere else. Take a thread in #eng-payments: after an incident, the team agrees to retry provider webhooks on 5xx and timeouts only, never on 4xx, at most three attempts, with the same idempotency key on every attempt. That sentence is the most useful fact in the company for the next agent that touches the webhook handler. It lives in a Slack thread nobody will reread.
A human engineer picks this up by being in the room. An agent cannot. It either gets the fact in its context before it writes the retry loop, or it writes the obvious retry loop, which retries everything.
What should a company brain do?
Five jobs. A system that skips one of them turns into a wiki, a search box, or a pile of notes.
- Capture where decisions happen. Slack threads, PR review comments, meeting transcripts, design docs, ADRs. Not only the pages someone remembered to update.
- Let a person approve what becomes a fact. A captured sentence is a claim. Some claims are routine and can pass on policy; a claim that contradicts an existing fact needs a human. Without this step the brain learns every half-finished opinion.
- Serve the relevant facts, not all of them. An agent editing the webhook handler needs the retry decision, not the onboarding checklist. More context is not the goal. The right two lines at the start of the task are.
- Stay true. When the code that a fact describes is deleted, or a newer decision reverses it, the old fact has to stop being served. Retired facts should be archived, not silently deleted, so you can see what changed.
- Measure use. Count how often each fact was served and how often an answer cited it. A fact served a thousand times and never cited is a candidate for rewording or retirement. A cite is evidence, not proof; the count is still better than guessing.
Company brain vs wiki vs enterprise search vs agent memory
These four get confused because they all hold company knowledge. They differ on who writes, who reads, and what keeps them true.
| Wiki | Enterprise search | Agent memory | Company brain | |
|---|---|---|---|---|
| Who writes it | People, by hand | Nobody; it indexes what exists | The agent, from one person’s sessions | Captured from where the team decides, then approved |
| Unit | Page | Document or message | Note | One decision, with its source |
| Scope | Whole company | Whatever the searcher can see | One person, one machine, or one repo | The team, across repos and agents |
| Reaches the agent | Only if pasted or imported | Only if the agent thinks to search | Yes, for that agent only | Served at the start of the task, to every agent |
| Review before use | Implicit, by the author | None | Usually none | Yes; you set the gate |
| Handles reversals | Someone edits the page | Returns old and new side by side | Old note stays until deleted | Newer decision supersedes the old one |
| Measures use | Page views | Queries | Rarely | Served vs cited, per fact |
Enterprise search is the closest neighbour, and the difference is worth stating. Search returns the thread. The thread contains the proposal, the objection, the reversal and a joke. A company brain returns the one sentence the thread settled on, with a link back to it.
Agent memory is the other neighbour. The memories built into Claude Code, Codex, Cursor and Copilot are useful and personal or per repo by design. The comparison is in Claude Code memory vs Codex, Cursor and Copilot.
What does a company brain look like day to day?
Follow the webhook decision through one. The thread in #eng-payments ends with the lead saying “agreed, 4xx never retries”. The brain reads the channel, which the team opted in, and proposes one fact: the rule, the reason, a link to the thread. Someone on the payments team approves it, or a policy does because it is a routine convention that contradicts nothing.
A week later an engineer asks an agent to add a consumer for a new provider event. The engineer does not mention retries. The agent starts the task already holding the retry rule, because the task touches webhook code, and it does not hold the forty other facts about billing, onboarding and the deploy freeze. It writes the loop the team agreed on. The rule is counted as served, and cited if the answer relied on it.
In March the team moves to a queue with its own retry policy and deletes the old handler. The fact now describes code that no longer exists, so it is retired and archived. Nobody had to remember that it was written down somewhere.
What are the risks of a company brain?
The launch threads name them, and a buyer should ask about each one.
- Stale facts. Ask what retires a fact, and whether anything does it without a person remembering to.
- Contradictions. Ask what happens when two sources disagree. If the answer is “the newest wins”, a stray message can overwrite a decision.
- Temporary vs durable. A spike's architecture notes should not be served in everyday work. Capture needs a human gate or a policy strict enough to hold that back.
- Access. Ask which sources are read, and whether that is opt in per channel or page.
Where Harbor fits
Harbor is a company brain for teams running AI coding agents. It reads where the team already decides: opted-in public Slack channels, merged PRs and their review threads, repo markdown such as ADRs and RFCs, Notion, Linear, and more (the list is in the sources docs). What it captures goes to a review queue, where you set the gate: Manual, Hybrid or Auto. A contradiction is always held for a person.
Claude Code, Cursor and Codex get the facts that apply to the task on turn one, through hooks that harbor init installs. Any MCP client can ask for more. Each fact is counted served and cited, and a fact whose code is gone can be retired, archived rather than deleted. The quickstart takes a few minutes.
The webhook decision from #eng-payments is traced end to end in Slack decisions for AI coding agents, and the same idea applied to review threads is turning PR review comments into agent rules.
Questions
What is a company brain in AI?
It is a shared system that reads where a company makes decisions, such as chat threads, code review, meetings and docs, turns them into short approved facts, and serves the relevant ones to people and AI agents when they need them.
How is a company brain different from a wiki?
A wiki holds what someone remembered to write down, and it only changes when someone edits it. A company brain captures decisions from the conversations where they were made, puts them through review, and retires or supersedes them when the code or the decision changes.
Is a company brain the same as enterprise search?
No. Enterprise search returns the documents and messages that match a query, including proposals that were later reversed. A company brain returns the decision the thread settled on, with a link to its source, and serves it without anyone having to search.
How is a company brain different from Claude Code or Copilot memory?
Agent memory is personal or per repository by design: Claude Code auto memory is machine-local and Copilot Memory is per repository. A company brain is shared by the whole team and every agent they use, with review before a fact is served.
What should a company brain for engineering teams do?
Capture decisions from where engineers make them, let a person approve what becomes a fact, serve only the facts that apply to the current task, retire facts that stop being true, and count how often each fact was served and cited.