What Is a Company Brain? What It Has to Remember, Who Keeps It Current, and Where AI Memory Fits (2026)

YC's Summer 2026 Requests for Startups includes an entry titled Company Brain. It starts from a claim about what's holding AI back: "The biggest blocker to AI automation of companies is no longer the models, they just got so good so quickly. Now the blocker is the domain knowledge."

The entry describes the problem in ordinary terms. "Every company has critical know-how scattered everywhere. Some of it lives in people's heads. Some of it is buried in old email accounts, Slack threads, support tickets, and databases." And it explains why that works for people but not for agents: "The company works because humans vaguely remember where that knowledge is and how to apply it."

Its conclusion: "But AI agents can't operate like that. If we want every company to run on AI automation, we need a new primitive: a company brain."

The YC entry defines it as "A system that pulls knowledge out of all these fragmented sources, structures it, keeps it current, and turns it into an executable skills file for AI."

That sentence has four verbs, and each is a separate job:

• Pull knowledge out. Find it in email, chat, tickets, documents, and databases.
• Structure it. Turn scattered mentions into something organized.
• Keep it current. Update it as the company changes.
• Make it usable by AI. In the entry's words, an executable skills file.

The point of the last step is action, not lookup. "Then AI systems can use that skills file to actually do the work safely and consistently."

What it isn't

The entry is explicit about the difference from tools that already exist: "This isn't a company-wide search or a chatbot over documents. It's a living map of how a company works: how refunds get handled, how pricing exceptions are decided or how engineers respond to incidents."

Search finds documents. A company brain is supposed to capture how things are done, including the parts nobody wrote down.

The YC entry's three examples point to three kinds of knowledge that are hard to find in documents.

How things get done

How refunds get handled is a procedure. Some of it is in a policy page. Much of it is in practice: which cases go to which person, what gets checked first, what counts as an exception.

How decisions get made

How pricing exceptions are decided is judgment. It depends on precedents, on who has authority, and on reasons that may only exist in old threads. A company brain has to capture the decision and why it was made, or an agent can't apply it to the next case.

How people respond

How engineers respond to incidents is practice under pressure. Runbooks help, but the real response can also depend on knowing which system tends to fail and who to page.

Where it came from

Underneath all three is provenance. A fact without a source is hard to trust and hard to correct. Open-source projects in this space make this explicit. GBrain, an open-source brain project that the YC entry points to as a model, says it stores "explicit facts with their sources", supports "corrections and withdrawal", and makes "the same memory available across your agents".

Keeping it current is the shortest part of the definition and the hardest to deliver. Companies change constantly: prices, owners, policies, systems. A company brain that was accurate in March can mislead an agent in October.

Three things make currency work:

• Corrections. When a fact is wrong, there has to be a way to fix it, and the fix has to win over the old version.
• Withdrawal. When a fact no longer applies, there has to be a way to retire it, not just add a newer one on top.
• Dates. Knowing when a fact was recorded tells an agent, and a person, how much to trust it.

Someone has to own this. Extraction can find knowledge, but deciding which version is current is a judgment call, and it belongs to the people who run the process. Our look at how agent memory got more accurate by keeping less covers why pruning matters as much as adding.

If your team uses assistants with memory, it helps to see what each kind holds, because none of them is a company brain on its own.

Personal memory in each assistant

ChatGPT and Claude both remember things about the person using them. That memory is per account. On Claude's Team plans, Anthropic says "Individual Team plan members manage their own memory settings directly." What one person's assistant learned isn't automatically available to a colleague's.

Coding agents keep memory too. Claude Code's auto memory is machine-local; Anthropic says its files "are not shared across machines or cloud environments". Codex stores local memories in its home directory, and OpenAI's advice is direct: "Treat memories as a helpful recall layer, not as the only source for rules that must always apply."

Instruction files in repositories

For engineering knowledge, teams already have a shared layer: files checked into the repository, such as AGENTS.md and CLAUDE.md. OpenAI's guidance is to "Keep required team guidance in AGENTS.md or checked-in documentation." These files are shared, versioned, and reviewable, which is most of what a company brain needs, for one repository. For the decisions that sit outside any one repository, our guide to why ChatGPT forgets architectural decisions covers what can get lost.

A shared layer across people and agents

The missing piece is a layer that sits across people, tools, and projects. GBrain's README draws a useful line here: "Durable preferences and facts can be shared across agents; transient task and harness configuration state stay local." A company brain is the durable, shared part. Our list of shared memory solutions for multi-agent systems compares approaches to that layer.

If agents act on a company brain, its mistakes become their mistakes. Four properties decide whether that's acceptable:

• Provenance. Every fact traces back to where it came from.
• Scope. People and agents see what they're allowed to see. GBrain's README, for example, says "Authenticated remote clients are constrained by source and operation grants plus visibility filters."
• Currency. Facts carry dates, and stale ones are corrected or withdrawn.
• Reviewability. People can read what's stored and change it.

These are the same properties that make any shared memory useful. Our guide to context engineering covers why the context an agent gets matters as much as the model.

Indexing everything and calling it a brain. That's company-wide search. The YC entry rules it out explicitly.

Relying on each person's assistant memory. Personal memory is per account or per machine. It doesn't add up to shared knowledge.

Treating extraction as the whole job. Pulling knowledge out is the first step. Keeping it current is the ongoing one.

Skipping provenance. Facts without sources are hard to trust and harder to correct.

Starting with the whole company. A brain built for everything at once is hard to keep specific. One process, done well, shows what works.

Step 1: Pick one process and write down how it really works

Choose a process that agents or new people keep getting wrong: refunds, a type of exception, an incident response. Write down how it actually works, including the parts that live in people's heads. Ask the people who run it.

Step 2: Record decisions with their reasons and dates

For the judgment calls in that process, record each decision, why it was made, who made it, and when. These are the facts an agent can't infer. Our guide to giving Claude permanent domain knowledge covers how to structure this kind of knowledge for an assistant.

Step 3: Assign an owner and a review rhythm

Make one person responsible for keeping that process current. Correct facts that change, withdraw ones that no longer apply, and date every update. If the knowledge starts in a group chat, our guide to moving a ChatGPT group chat to a shared project shows one way to give it a home.

A company brain, in the YC sense, is a large system. The part teams can start on today is smaller: a shared, maintained list of the facts and decisions that people and agents keep needing, with sources and dates, that isn't tied to one person's account or one tool.

MemoryLake is a memory layer for keeping that list in one place you maintain, available to the assistants you connect, such as ChatGPT, Claude Code, and Codex.

You write the entries yourself, in your own words. Nothing is read out of, written to, or deleted from your email, your chat tools, your tickets, your assistants' memory, or any vendor's store. MemoryLake holds what you choose to record; it doesn't extract knowledge from your systems.

Step 1: Create an API key

Sign in and generate a key from the dashboard. The key belongs to your MemoryLake workspace and is separate from your other accounts.

Step 2: Upload your first memories

Start with the process from Step 1 of the fix and the decisions from Step 2. One point per entry, with its source and date, and only what your organization's policy allows you to store.

Step 3: Connect your AI & agents

Connect the assistants your team uses. The same maintained facts are available in each of them, and the owner from Step 3 keeps them current in one place.

The first difference is clarity about the term. A company brain isn't search and isn't a chatbot over documents. It's maintained knowledge about how the company works.

The second is a realistic starting point. One process, written down with decisions, sources, and dates, beats a vague plan to capture everything.

The third is that currency gets an owner. The hardest part of the definition, keeping it current, becomes someone's job instead of nobody's.

Start with one process. Prove it works before expanding.

Capture decisions, not just documents. The reasons are what agents can't infer.

Keep sources on every fact. Provenance makes correction possible.

Date every entry. Currency depends on knowing when something was true.

Withdraw what's stale. Don't just add newer facts on top.

Respect scope. Not every fact belongs in front of every person or agent.

Keep repository rules in the repository. Shared instruction files already work for code.

A company brain is a system that captures how a company actually works, keeps that knowledge current, and makes it usable by AI. YC's Summer 2026 Requests for Startups popularized the term, defining it against company-wide search and chatbots over documents, and pointing to procedures, decisions, and responses as what it has to hold.

The memory in today's assistants covers parts of this: personal memory per account, local memory per machine, and instruction files per repository. The missing layer is shared, maintained, and sourced. Start with one process, record its decisions with reasons and dates, and give someone the job of keeping it current.