What exactly is a Company Brain? Four layers of infrastructure for organizational context

Company Brain's first job is keeping enterprise knowledge accurate

Company Brain is still in a phase of rapid definitional change. When Slite asked respondents how they understood it, 53% chose "a continuously updated knowledge base," 18% chose "a wiki automatically maintained by team activity," 13% chose "AI search across tools," 12% chose "an agent memory layer," and 4% said they did not know.

Source image: Slite Company Brain Survey 2026Sample: 149 respondents; the public page doesn't disclose methodology

Slite pools the first two categories to arrive at "71% of teams expect knowledge to stay accurate first." That grouping involves editorial judgment, but it captures the core of the material: Company Brain's first job is making organizational knowledge trustworthy, and agents simply push that requirement into higher-stakes execution environments. If a system can only retrieve answers from multiple sources but cannot explain where those sources came from, when they were last updated, and who has the right to modify them, it is still just a search layer.

The book traces several adjacent concepts: the personal "second brain," the Context Graph that organizes business context through entity relationships, a wiki generated and updated by models, the open-source GBrain, and the Company Brain that YC has proposed as a startup direction. YC's public definition is especially clear: it sits between raw enterprise data and reliable AI automation, responsible for extracting, organizing, and updating knowledge, and for letting agents call on that context.

Pulling all this together yields a vendor-neutral working definition:

Company Brain is organizational context infrastructure. It continuously absorbs work signals, organizes them into traceable shared memory, handles staleness, conflicts, and permissions, and then provides answers and actionable context to humans or agents.

This definition is stricter than an "AI knowledge base" in two ways: it requires a maintenance loop and machine invocation. It is also broader than "agent memory," because it stores organizational truth rather than the conversation history of a single agent.

Knowledge fragmentation won't disappear; agents amplify the cost of stale docs

Traditional knowledge management loves to promise a "single source of truth," but reality is that the more vertical SaaS tools a company adopts, the more fragmented its knowledge becomes. In Slite's sample, 83% use a dedicated knowledge base, 79% use two or more systems simultaneously, 64% use shared drives, 56% rely on Slack or Teams, and 30% still depend on email. These figures likely allow multiple answers, but the book does not publish the original question wording.

Source image: Slite Company Brain Survey 2026Sample: 149 respondents; the public page doesn't disclose methodology

Fragmentation is not failure by itself. CRMs are good for customer status, ticketing systems for issue history, chat for quick coordination, and design tools for creative process. The real problem is when the same fact lives across systems with different speeds, permissions, and lifecycles, and the organization typically has no mechanism continuously reconciling those relationships.

Documents go through a familiar cycle: someone writes down a rule, the team starts using it; reality changes, but the page does not keep up; readers lose trust, and re-explain things in chat or in new documents. The knowledge base gets thicker and thicker, while trustworthy knowledge gets harder to identify.

Humans cope with this mess by relying on tacit judgment. We check dates, recognize authors, notice when the tone is off, or just ask a colleague. Agents have none of that default organizational common sense. An agent may treat a top-ranked but outdated page as authoritative, then use a rule missing its region, customer tier, or effective date to generate a quote, reply to a customer, or execute a backend action.

Source image: Slite Company Brain Survey 2026Sample: 149 respondents; the public page doesn't disclose methodology

The same bad knowledge costs a human maybe ten extra minutes of fact-checking. For an automated system, it can mean doing the wrong thing for hundreds of customers at once. Company Brain therefore carries the risk-control duty of automation: source, time, permissions, and confidence boundaries must enter the execution chain along with the answer.

Humans tighten the context gap first; then agents can safely touch the backend

Slite's survey does not show companies wanting to serve only agents. 4% of respondents want answers just for themselves, 34% want to serve themselves and their team, 54% want to serve both humans and agents, and only 7% target agents exclusively. The book sums the earlier categories to emphasize that roughly nine in ten needs still include human use cases.

Source image: Slite Company Brain Survey 2026Sample: 149 respondents; the public page doesn't disclose methodology

For humans, Company Brain reduces the "context assembly tax" at the start of every task: new hires do not have to rebuild project history across five tools; sales does not have to chase down product rules; engineers can find the rationale behind an architecture decision; cross-team collaboration relies less on "who still remembers." These benefits are not flashy, but they are the foundation for any agent automation.

For agents, risk rises with autonomy. A chat assistant that gets an answer wrong still leaves a human in the loop. Coding, customer support, sales, and content agents start producing deliverable results. Operations, HR, and knowledge-maintenance agents modify system state. Background environment agents act continuously without supervision, putting the highest demands on complete context, permission boundaries, and escalation mechanisms.

Different agents do not all need the same "company profile." A coding agent needs architecture decisions, incident records, internal conventions, and the reasoning behind why things were done a certain way; otherwise it may write code that is technically sound but violates every implicit rule the team operates under. A customer support agent needs known issues, policy boundaries, and tone guidelines; otherwise wrong answers get scaled out to customers. A sales agent needs pricing rules, historical deals, and current positioning; otherwise it may hand out discounts based on a pitch that is two quarters old. A content agent must distinguish between shipped features and roadmap items. A knowledge-maintenance agent needs to know which facts are aging out.

Background agents stack all these requirements on top of each other, and no human is there to notice when something goes wrong. Company Brain therefore cannot just return "relevant text." It has to deliver the right slice of knowledge for the task, with provenance, permissions, timestamps, and conflict status intact.

Source image: Slite Company Brain Survey 2026Sample: 149 respondents; the public page doesn't disclose methodology

But beware of sample bias here. Among Slite's respondents, 57% have already deployed their own agents or skill files, and 25% of those call themselves "agent-native." Another 23% mainly use AI as a chat tool. That sample is clearly closer to the agent frontier than the average company, which inflates demand for machine-invokable knowledge. It tells us what early adopters are worried about; it does not prove every company is at the same stage.

Four-layer architecture: signals, memory, pruning, invocation

The most useful part of the book strips away product names and leaves four systemic problems. Any Company Brain, whether built on Markdown, a knowledge base, a vector database, or a knowledge graph, has to follow this path.

Layer one: capture signals. Information can be pulled from business systems on a schedule, pushed when events happen, written by an agent after a work session, or read in real time at query time. Scheduled syncs give broad coverage but lag behind; event capture is fresh but noisy; query-time reads are the most current but are constrained by external API speed, permissions, and rate limits.

Layer two: form memory. Plain files are transparent and version-controlled. Document knowledge bases are human-friendly. Vector indexes excel at semantic similarity. Knowledge graphs handle entity relationships and changes over time. No single storage type is inherently "company truth." The choice determines what kinds of questions the system can answer, as well as how hard permission inheritance, migration, and maintenance will be.

Layer three: curate and prune. This is the layer most "just hook up RAG and you're done" approaches skip. Common mechanisms include scheduled merging, time decay, drift detection, conflict flags, and human review queues. It continuously decides what is still valid, what has been superseded, and what needs a responsible owner to confirm.

Layer four: invoke. Humans need chat, search, citations, and readable explanations. Agents need stable APIs, MCP, or purpose-built tools, plus the ability to halt when permissions fail, sources conflict, or confidence is low. An answer being findable does not mean it is fit for execution.

There is no "done once, done forever" arrow between the four layers. Invocation results expose knowledge gaps; those gaps should feed back into capture and maintenance queues; maintenance quality determines the next invocation. Only by seeing Company Brain as a closed loop do the true cost centers emerge.

{{related:related-context-engineering}}

Ten sample implementations: there is no single technical path

The ebook's sample implementations span open-source projects, memory SDKs, vertical products, internal enterprise systems, and minimalist DIY setups. They share very little in common, which is exactly the point: Company Brain cannot be monopolized by any one database or interface.

GBrain uses Markdown/Git as its record layer, indexes with PGLite or Postgres/pgvector, and runs a nightly "dream cycle" to maintain relationships and references. mem0 extracts facts worth saving from application-submitted conversations and uses both vector and entity signals for retrieval. Letta lets agents manage in-context memory, external archives, and full message history, with background agents organizing shared memory. Zep/Graphiti emphasizes a temporal knowledge graph: new facts expire old relationships rather than simply deleting them.

Other approaches put more weight on human approval. Sylph treats the Git tree directly as the brain: agent changes land in drafts first, and are only merged after review. The Claude Code + Git DIY route builds a knowledge layer out of CLAUDE.md, rules, skill files, and runbooks, with compaction and updates flowing through engineers and pull requests. Carrara copies shared memory from Postgres into local applications, with every single memory approved by a human.

Vertical systems shrink "the company" to a specific work domain. Pletor organizes brand rules, creative references, and performance data. Gorgias Cortex connects customer support knowledge through large numbers of typed Markdown nodes and discovers gaps from conversation trajectories. Slite Agent uses existing documents as its foundation, adding owners, verification labels, expiry windows, cited answers, and MCP. That last one is vendor self-description; this round did not independently test the current behavior of any of these products.

When comparing the ten samples, look at four things first: what can enter the system, what counts as memory, who approves updates, and how answers make their way into work. The differences ultimately converge on accountability allocation, with technical jargon taking a back seat.

The real build-or-buy line is who permanently maintains this context layer

Slite says only 17% of the sample already has a "working" Company Brain. Respondents' main concerns are answer accuracy at 77%, permissions and privacy at 63%, maintenance burden at 58%, daily ingestion and upkeep costs at 58%, and setup effort at 33%. These figures are useful for comparing priorities within this sample, not for estimating market size or prevalence rates.

Among those who have already tried building one, Slite says roughly half use a custom setup that connects Claude or Codex to a knowledge base, and about another fifth use GBrain. The ebook does not disclose the exact denominator or survey methodology for these proportions, so they only show that surveyed early adopters prefer self-controllable technical paths; they do not prove self-built solutions dominate the market.

The book maps the market along two dimensions: whether Company Brain is a layer independent of business applications or a capability embedded in a single product; and whether the enterprise maintains it in-house or hands maintenance to a vendor. That yields four categories: self-hosted independent layer, vendor-maintained dedicated product, enterprise-maintained memory SDK, and large-suite built-in features maintained by the vendor.

Source image: Slite Company Brain Survey 2026Vendor market taxonomy, not an independent benchmark

This four-quadrant framing clearly reflects Slite's own position, but it raises a genuinely hard question: are you buying software, or permanently outsourcing the maintenance of your organization's context? Building in-house goes far beyond "getting a vector database running." It means taking on long-term responsibility for connectors, permission mapping, retrieval evaluation, conflict handling, human review, and cost optimization. Buying does not eliminate any of that work either; it just changes who does it, how much of the process the enterprise can see, and what it can take away when leaving.

The selector on the original page compresses the decision into three variables: team size, which concern matters most (wrong answers, permissions, maintenance, or cost), and whether the internal lead has technical capability. That framework is more useful than a list of products. A small team with engineering chops and a tight cost constraint will find self-hosting more viable. As scale grows, permissions get complex, and nobody owns maintenance, a dedicated product gains practical advantage. Memory SDKs suit adding memory to a specific product or agent, but do not automatically add up to company-wide shared context. The page also computes a match percentage for each answer, but it does not disclose its validation method. Those figures are Slite's own selection heuristics, not probabilities of success.

Slite calls the second set of questions "context sovereignty." If Company Brain genuinely spans multiple business systems, it will gradually form a more complete company profile than any single SaaS tool. Enterprises should at least run three due diligence checks:

1. Can the raw memory be fully exported? Not just answers, but also the source, versions, relationships, and permission metadata.
2. Can the model and invocation layer be swapped? If the knowledge structure is only accessible to one model or suite, switching costs will keep rising.
3. What happens when upstream platforms tighten their APIs? Slack in 2025 limited historical message access for some non-Marketplace apps to one call per minute with a maximum of 15 messages per call, and explicitly discouraged unbounded batch extraction of conversations for external indexing. Any approach that relies on scraping at query time has to confront such platform boundaries.

That makes a standalone layer strategically appealing, but it shouldn't be framed as the only correct answer. Smaller teams may be better served by built-in suite capabilities; regulated or heavily customized environments might require a self-built approach; specialized vendors could offer more mature maintenance and permissioning. The ebook doesn't provide accuracy rates, total cost of ownership, ROI, or cross-solution benchmarks, so there's no evidence that any single category is universally superior.

Builders agree on four points, but four questions remain open

Slite's synthesis of recent consensus is restrained: Company Brain requires ongoing maintenance; AI shouldn't rewrite enterprise knowledge without human review at this stage; capture should ideally be a byproduct of work processes; and Agent-generated queries will vastly outnumber human ones, so permissions, costs, and observability must all be designed at machine scale.

The "ongoing maintenance" point stems from the fact that the technical landscape is still shifting rapidly. The systems studied in the book use five different rerankers and three retrieval strategies, yet share no common benchmark; they don't even agree on whether knowledge graphs are necessary. Zep puts a temporal graph at its core, Gorgias has built roughly 12,000 typed nodes, while Slite and Letta have skipped graphs entirely. Gorgias's architecture write-up was already outdated between publication and the book interview. So self-built teams are signing up for a continuous product effort: collection, retrieval, permissions, evaluation, debugging, and governance all need dedicated long-term ownership.

Several operational patterns for human-in-the-loop knowledge write-back have emerged. Pletor routes revision suggestions into an amendment inbox; Gorgias requires PR review for graph fixes; Sylph's Agent can only submit drafts and can't promote them to official knowledge on its own; Slite uses Agent Triage to surface proposed updates. They all address the same risk: an Agent has a hard time distinguishing between a local plan, a tentative idea under discussion, and a decision that's actually in effect for the company. If errors flow directly into shared memory, subsequent retrievals will keep pulling them up and amplifying them.

Capture also can't depend on employees remembering to write documentation. nao Labs adds a logging step at the end of each Agent skill so knowledge accumulation becomes part of completing the task; Gorgias analyzes conversation traces nightly to identify gaps in the knowledge graph; Slite monitors activity in connected tools and then suggests updates. These three approaches correspond to post-task logging, deriving gaps from failure trajectories, and capturing signals from work events—but the goal is the same: make maintenance follow the work that's actually happening.

Access points are changing too. mem0, Guru, and Slite already offer MCP services, and Gorgias is exposing its internal Brain to code-first teams. Agents no longer need to open a knowledge base and search the way a human would; they automatically query for context before every task. Once queries shift from occasional human actions to routine machine steps, caching, permission checks, call costs, failure logs, and exception handling all have to be designed for much higher frequency.

The hard questions are about how an organization defines knowledge, not whether models can retrieve a few more documents. Employee conversations with Claude or ChatGPT often contain the most condensed reasoning—and also the most sensitive explorations, disagreements, and personal judgments. Exclude all of that and the organization loses a huge amount of decision context; feed it all into a shared Brain by default and you cross privacy and authorization boundaries.

Conflicting versions can't simply be merged either. Marketing and sales teams may each hold a view of positioning that works in their own context; if a model automatically keeps whichever version is louder or more recently edited, it's effectively making a strategic choice on the organization's behalf. Current approaches usually end up relying on a trusted individual to adjudicate—and that person becomes both a maintenance bottleneck and a single point of failure. Company Brain needs to represent who considers something true and within what scope, not just leave behind a seemingly definitive answer.

One builder in the book estimates that roughly 80% of operational knowledge still lives in people's heads. That figure doesn't come from any independent methodology—it's an interviewee's perspective. But it points to a hard ceiling for Company Brain: a system can only govern knowledge it can observe, authorize, and review.

There's already an attempt to address what remains unwritten: Ontora uses structured, AI-led interviews to probe employees and capture the reasoning behind their experience into the Brain. It moves the question from "which systems to connect" to "how to obtain knowledge that never entered a system," though the source acknowledges the approach hasn't solved scale, review burden, or employee adoption.

So the most sensible starting point for Company Brain is a work domain where error costs are controllable and source boundaries are clear. Work through the four questions one by one: where signals come from, who's responsible for confirmation, how permissions are inherited, and whether memory can migrate. If the system can't answer those, smarter search just delivers old knowledge faster to people and Agents alike.