A 4-part series on building a company brain.
Part 1: What a company brain is and what it isn’t (you are reading this)
Part 2: The architecture (forthcoming)
Part 3: How to build a company brain without burning trust
Part 4: A product team worked example (forthcoming)
Everyone is building a company brain.
The phrase is everywhere. Every few weeks, another company announces some version of persistent memory, proactive context, AI coworkers, organizational intelligence or agentic execution. YC has put the idea into its RFS. Many companies are now converging on their own version of this idea: Glean’s Enterprise Graph, Edra.ai, Sentra.app, Zapier’s Shared Brain, Cloudflare’s Agent Memory and Anthropic’s Managed Agents and Orbit.
Naturally, this creates pressure inside companies.
A CEO sees a demo where an assistant appears to understand the business. A country head sees a tool that can answer questions across support tickets and internal docs. A product leader imagines never having to ask “why did we decide this?” again. Someone forwards a link into the leadership chat and asks the inevitable question:
“Should we build something like this?”
The usual answer is to jump straight into architecture. Which model? Which vector database? Which tools should we connect? Slack, Google Drive, Confluence, Jira, CRM, email, meeting transcripts, support tickets?
That would already be useful in most companies. In many organizations, just making internal knowledge searchable with citations would save thousands of hours a year.
But that is not a company brain. That is retrieval.
Most company-brain projects fail before the model, the vector database or the retrieval pipeline becomes the real problem. They fail because nobody defines what the brain is supposed to do.
A real company brain has to preserve three things (and they are not the same problem):
- What the company knows (memory)
- Why the company believes it (reasoning)
- What the company should do next (coordination)
Most projects start with the first, gesture vaguely at the second and prematurely promise the third.
This first piece is about getting the definition right before any architecture or scoping conversation.
A company brain is not a chatbot
- Not a vector database.
- Not semantic search over a knowledge base.
- Not workflow automation.
- Not even an agent runtime.
Those may be interfaces, components or execution layers. They are not the brain.
A company brain is a permissioned, versioned memory system that connects company facts, decisions, commitments, workflows, policies, people and actions, with provenance, ownership, access control and confidence metadata, so humans and agents can answer questions, reconstruct reasoning and coordinate work safely.
In short, a real company brain should know:
- what happened
- who was involved
- which source supports the answer
- which version of the policy was active at the time
- who owns the current policy
- whether the information is authoritative, contextual or inferred
- whether the answer is stale
- whether the user is allowed to see it
- whether the system should answer, refuse, escalate, draft or act
That is a very different thing from “chat with your docs.”
Most company-brain projects fail because they start with the visible layer: the assistant. The harder and more important layer is underneath it: the memory system that determines what the assistant can know, trust, explain and safely do.
The clearest test: search vs. ask
Search returns documents. It expects you to read, synthesize, decide what is current and apply judgment. Ask returns a synthesized answer with citations and tells you when it does not know.
A company brain is closer to the second thing.
In most companies, institutional knowledge looks like a library where every book has been ripped apart and the pages scattered across Confluence, Slack, email, Drive, Jira, Intercom, HubSpot, individual laptops and the heads of the most experienced employees.
A company brain is the librarian who has read every page, answers with citations and refuses to answer when it is not sure.
Three layers, in the order they have to be built
A useful way to think about the architecture is three layers: factual memory, context graph and action coordination. Each layer is valuable by itself. Only together do they become organizational infrastructure. You can’t skip ahead without paying for it later.
Layer 1: Factual memory (record of what happened)
The record of what happened. Meetings, messages, emails, documents, tickets, CRM notes, support calls, commits, incidents, dashboards, customer conversations, policy versions, approval logs.
This is where every company brain project starts because the problem is obvious: company knowledge is scattered everywhere. People waste hours searching. New hires ask the same questions. Support agents depend on senior people in Slack. Regulatory responses require archaeology across old folders, email chains and tribal memory.
So the first instinct is reasonable: connect the tools, index the documents, add retrieval, cite sources, give users a chat interface.
That is a good start. It is not enough.
Factual memory can tell you that a customer complained about a delayed payout. It can tell you when the complaint came in, who handled it and where the support ticket lives. It cannot tell you why the payout was delayed, whether this was an isolated issue or part of a pattern, what operational tradeoff was made, who accepted the risk or whether the fix still holds.
Companies do not run on facts alone. They run on interpreted facts.
Most “company brain” attempts stop at this layer and quietly become search products with better branding. Glean calls this layer the Knowledge Graph and explicitly says it’s not enough for agentic execution, which is why they layered the Enterprise Graph on top.
Layer 2: Context graph (the why)
This is where facts become a model of how the company actually works.
Example: The customer call connects to the opportunity. The opportunity connects to a product gap. The gap connects to an engineering tradeoff. The tradeoff connects to a roadmap decision. The decision connects to a policy, a launch plan, a risk acceptance or a future commitment.
Most enterprise tools store these as separate artifacts. A company brain preserves the relationships.
Metacognition also lives here, reasoning about reasoning. A real brain knows when evidence is weak, context is stale, teams have conflicting assumptions, a commitment has no owner, an agent should pause and ask.
Companies forget in strange ways. They don’t just forget facts. They forget why a fact mattered, the context that led to the decision, the counterfactuals, what was tried and rejected, who had the dissenting view that later turned out to be right.
Edra.ai’s whole thesis is built around this layer. Their Living Playbook ingests support tickets, emails, logs and chat histories and reverse-engineers how the business actually runs.
The context graph is the layer most teams underestimate, because it’s the hardest to build and the easiest to fake. Indexing documents is mechanical. Reconstructing reasoning is not.
Layer 3: Action coordination (the next right step)
A real brain doesn’t only remember and reason. It coordinates the next right step.
It drafts the follow-up when a customer commitment has no owner. It creates a ticket when the same complaint appears in multiple support conversations. It warns leadership when teams are making inconsistent assumptions about the same launch. It knows which refund can be processed automatically and which pricing exception needs human approval.
It is not simple automation. Automation executes a known workflow. Action coordination decides what should happen next from context, then answers, drafts, escalates, acts or refuses.
Action coordination is the layer most teams want too early. They start with “we want agents” before they have reliable memory, source hierarchy, permissions or evaluation. Then the agent has nothing solid to stand on. Layer 3 fails without strong Layers 1 and 2.
Remember first. Reason second. Act third.
If your project plan addresses Layer 1 only, you’re building enterprise search. Useful, but not a brain. If it addresses Layers 1 and 2, you have something genuinely valuable but mostly passive. Layer 3 is what separates “we built a knowledge product” from “we built organizational infrastructure.”
The right kind of memory for the company brain
A company brain should not treat every piece of information equally. There are three tiers of knowledge and a system should not flatten them.
Authoritative knowledge: curated, owned, reviewed, canonical. Approved policies, current SOPs, legal templates, regulatory submissions, signed-off architecture decisions, board-approved strategy. Has a named owner, review date, jurisdiction, version history, citation path.
Contextual knowledge: useful evidence, not truth by itself. Slack threads, email discussions, call transcripts, support tickets, draft documents, meeting notes, CRM entries. Explains how work happened. Should not automatically override authoritative sources.
Inferred knowledge: reconstructed from behavior. “Senior support agents usually resolve this type of ticket this way.” “Pricing exceptions above this threshold usually go to finance.” “This customer segment often asks for the same onboarding clarification.” Extremely valuable. Also dangerous if treated as fact. The system should label it clearly, attach confidence, show evidence and require human review before it becomes authoritative.
This is where many company brain efforts go wrong. They ingest everything and flatten it into “context.” But enterprise context is not flat. A policy is not a Slack opinion. A legal approval is not a product manager’s interpretation. A repeated behavior is not necessarily an approved process.
When you are building a company brain, be wary of any system claiming “we’ve connected all your tools” without distinguishing between them. That is a search engine, not a brain.
Where the things you’ve heard about actually fit
Once you define a company brain as memory, reasoning and coordination, the market becomes easier to read. A lot of things now get described as “company brain,” but they are not the same object. Some are personal assistants. Some are agent runtimes. Some are workflow platforms. Some are memory substrates. Some are trying to become all of the above.
I’ve grouped them into the following categories along with some vendor examples:
1. Personal proactive briefing assistants.
Products like ChatGPT Pulse and the emerging Orbit-style pattern from Anthropic.
These ingest one user’s chat history, memory and opt-in connectors and push morning briefing cards.
What is missing: no shared substrate, no organization-wide permission model, no concept of canonical truth across users. They are interface patterns, proactive instead of reactive, operating on individual context. They can sit on top of a company brain.
2. Personal autonomous agents with persistent memory.
OpenClaw, Hermes Agent from Nous Research, NemoClaw on NVIDIA.
These are persistent agents that can run outside a single chat session, use tools, remember across interactions and communicate through messaging channels.
Many teams that say “company brain” may actually want this: a durable agent for each engineer, operator, founder or executive. But structurally, this is still personal memory and personal execution. Their architectural patterns (markdown-based memory, append-only timelines, agent-curated skills) are also instructive for how to build the personal layer of a brain. gbrain inherits a lot from this lineage.
3. Hosted AI coworkers and digital twins.
This includes products like Dimension, Read AI’s Ada and some parts of Coworker.ai depending on how they are deployed.
These are closer to “AI chief of staff” than company brain. They are valuable interfaces and execution companions. But unless they build or consume a permissioned organizational memory layer, they are downstream users of company context, not the source of it.
Coworker.ai’s OM1 product explicitly claims organizational memory and permission-aware recall across the organization, which puts it closer to category 6 than to simple personal coworker tooling.
4. Agentic execution runtimes.
Example: Claude Cowork and Claude Managed Agents.
Cowork is not purely a runtime. It bundles skills, connectors and sub-agents into plugins for non-technical knowledge workers, with out-of-the-box plugins for finance, legal, sales, HR, engineering, plus MCP integration to dozens of external tools. So Cowork sits in two categories simultaneously: a runtime for organizations that want to wire their own context into it and an opinionated workflow library that a small team can use as their de facto operational layer without ever building a separate brain.
Managed Agents is the cleaner case: in Anthropic’s framing, “not a product. It’s infrastructure you build on”, the harness, long-running sessions, audit logs, credential vaults. Neither, by itself, is a company brain. But Cowork plus plugins plus connectors plus a thoughtfully wired knowledge base can become a small company’s brain without ever calling it that.
Runtime without brain context = powerful agent with goldfish memory of your organization. Brain context without runtime = inert knowledge that can answer but not act. Serious deployments will need both.
5. Workflow + agent platforms reaching toward memory.
Zapier (Agents + Shared Brain), n8n, ServiceNow Now Assist, Microsoft Copilot Studio, Salesforce Agentforce.
These coordinate multi-step actions across systems and increasingly include their own memory layers. They blur into the company brain category from a different direction: starting from workflow and reaching toward memory. For most organizations these will be components of a brain, not the whole thing.
6. Organizational memory substrates / actual company-brain attempts.
Glean (Enterprise Graph + Personal Graph), Edra.ai (Living Playbooks), Sentra.app (organizational memory substrate), 8090 Software Factory (knowledge graph absorbing tribal knowledge into PRDs), gbrain (open-source personal demonstration of the layered pattern), Coworker.ai’s OM1. These attempt all three layers, in different ways, to build the substrate: the system of memory and context that agents and humans can query or act against.
Takeaway
The simplest way to avoid confusion is to separate the layers.
The brain is the substrate, what your organization remembers, reasons about and acts on, who owns it and who is allowed to see it.
The runtimes are what executes against it.
The personal agents are what individuals deploy on top of, alongside or sometimes instead of it.
The briefing layers are interface patterns that consume from it.
The workflow platforms are the coordination rails between substrate and runtime, getting fuzzier by the month.
Most companies need a thoughtful combination, not a single product:
- a small governed substrate for the organizational layer
- a clear source hierarchy and permission model
- an opinionated runtime like Cowork to act safely on it
- permission for individuals to deploy personal agents for their own work
- and integration with workflow platforms the company already runs
Almost no company needs to build all of this from scratch.
Part 2 gets into the architecture: what has to exist inside that substrate, how factual memory becomes a context graph, how confidence and authority should be represented and what has to be true before any agent is allowed to act.