What Is a Company Brain? Types and How It Works

Can we ask an assistant why we rejected an integration months ago and find out whether that decision still holds? The documentation is in Notion, the discussion in Slack, and the later change in Jira. A company brain tries to make that knowledge accessible without making us rebuild the context in every conversation.

I’d start with that question before choosing a vector database. Finding “we’re not doing this” tells us little without the reason and what happened afterward.

What is a company brain?

A company brain is an organizational knowledge layer that brings together information from different sources and makes it available to people and AI assistants. A useful design preserves where that information came from, supports updates, and controls who can access it.

The name doesn’t describe a single architecture. OrgLogic uses it for a shared layer that retrieves knowledge with references and access controls; the product Company Brain emphasizes extracting facts, reviewing them, and delivering that knowledge to AI clients. They cover different ground under a similar label. ^{[1] [2]}

I want to separate interface from infrastructure: the knowledge should remain available even if we change the chat interface or the model that writes the answers.

A wiki can be an excellent source, a search engine can handle retrieval, and a chat with PDFs can cover a small collection of documents. We need to look at what the company brain adds in synchronization, shared context, and knowledge governance.

Storing conversations isn’t enough either. The history preserves what was said, including provisional information and mistakes. Turning it into shared memory requires deciding what deserves to be kept and who should be able to access it.

Types of company brain: approaches we can combine

We can compare company brains by how they represent and use knowledge. This classification is a guide, not an official taxonomy.

Document-centered knowledge

The system searches manuals, tickets, or conversations and gives the model the relevant passages. If we ask how to deploy a service, it retrieves the procedure and writes an answer with a reference.

This lets us start without modeling every business fact, but retrieving text similar to the question can miss the message that changed a decision.

Structured memory of facts and decisions

Here we store explicit statements: what was decided, who approved it, which project it affects, and what source supports it. A decision can be current or superseded by another.

Company Brain documents a flow of extracted proposals, review, and versioned facts with evidence. ^[2] The advantage is being able to query a decision directly; the cost is maintaining it. If an LLM extracts the wrong reason for a change and we store it without checking, we’ve turned an incorrect interpretation into persistent knowledge.

Knowledge connected to tools

The assistant can query live systems and, when authorized, take actions. A tool is a function the application offers the model: read an issue, look up an order, or create a task.

This lets us combine the historical explanation with the system’s current state. It also introduces another boundary: knowing that a task should be created doesn’t mean having permission to create it. Authorization for each action belongs in the backend.

Approach	What we retrieve	When it helps	Additional work
Document-centered	Source passages	Questions about procedures and documentation	Reliable synchronization and indexing
Structured memory	Facts and decisions with provenance	Questions about agreements, owners, or whether a decision still applies	Validating extractions and managing changes
With tools	Current data and function results	Tasks that require querying or modifying other systems	Execution permissions, validation, and logging

We can combine these approaches. Scope is another dimension: company, department, or project. Being industry-specific describes the domain, not the technology.

How it works: from sources to an answer

A company brain connects sources, prepares knowledge, and retrieves an authorized selection for each query. It doesn’t require retraining the model or dumping all the data into the prompt.

Back to the rejected integration: we need to retrieve the original decision and any later changes.

Ingestion and synchronization

Connectors read the source systems. Ingestion turns their content into searchable records while preserving identifiers, dates, and permissions. An edited document must be updated; a deleted one needs to stop appearing wherever appropriate.

We can maintain a local index, query some sources live, or combine both options. Indexing reduces dependency on the source API during a query, but adds maintenance and potential synchronization lag. Reading live avoids using an outdated copy for that operation, although we depend on the API’s availability and limits.

Organization and indexing

Text can be split into passages and searched by keywords or meaning. Embeddings are numerical representations that let us compare semantic similarity, for example between “we rejected this integration” and “reasons for not connecting the vendor.”

We also need metadata. The project, date, and document type help distinguish an approved decision from a proposal. A result that closely matches the question can still belong to the wrong customer.

Authorized retrieval

The query must run with the user’s identity and access scope. Glean, for example, documents that results depend on access permissions in the connected applications. ^[3]

Unauthorized information must stay out before it reaches the model. Asking the model afterward to hide a private passage means we’ve already provided it. This rule also applies to summaries: deriving knowledge from a restricted document doesn’t make it public.

In our example, we retrieve the decision from the correct project and look for evidence that it has been superseded. If we find conflicting sources without an explicit resolution, the answer should reflect that.

Context and response

The application gives the LLM the question and the evidence. That context is the information it receives to answer; persistent memory lives outside it.

This selection is context engineering: deciding what the model needs to see in the next step. More documents mean more tokens, cost, and material to sort through, so including everything as a precaution has consequences.

The answer should let us open the source and check its date. Citing a document helps verify the answer, but doesn’t guarantee that the model interpreted it correctly. And if we can’t find the decision, “there isn’t enough evidence” is a valid outcome.

Where RAG, graphs, and MCP fit

RAG, knowledge graphs, and MCP solve different problems within a company brain; they aren’t requirements we need to pile up to use the name.

RAG, retrieval-augmented generation, combines information retrieval and text generation. The original work by Lewis and his coauthors combines a model with retrievable external memory. ^[4] In an enterprise application, we can use that idea to look for evidence before answering; the enterprise RAG pipeline covers its components.

A graph represents entities and relationships: which service a decision affects or which vendor it depends on. It helps when we need to query those connections; if documents and filters are enough, it adds extraction and maintenance we’ll need to justify.

MCP, Model Context Protocol, lets AI applications access resources and tools through a common interface. Its documentation separates context exchange from how the application uses the LLM. ^[5] We can expose a knowledge query through MCP or a conventional API; the protocol doesn’t decide which source is reliable or replace our permission checks.

How company brains are being applied

In engineering, we can query the reason for an architecture decision alongside its issues. In support, retrieve the approved procedure and check an account’s current status. In project management, reconstruct agreements and scope changes with their sources. These are different use cases, so the same retrieval configuration won’t necessarily work for all of them.

Industry-specific applications are also emerging. EVA Brain, by Sinapser, is an example of a company brain for event management: its public offering brings together project knowledge and decisions, with source references and permissions by project and person. It illustrates how to specialize this layer around an industry’s vocabulary and work, without making the general concept depend on that industry.

Where organizational memory fails

Organizational memory fails when it returns incorrect or outdated information, or information outside the requester’s permissions. The model can write well in any of those cases.

Confusing recent with current

The newest message might be a suggestion, while the earlier document contains the approved agreement. Dates help us sort, but we need to distinguish proposals from decisions. To test this, I’d use one query where a later discussion doesn’t change the agreement and another where it does supersede it.

Storing conclusions without provenance

A summary stating “the vendor was rejected because of cost” must let us return to the supporting passage. Without that connection, correcting it is difficult and we know less than it seems: cost might have been an inference in the summary, not the agreed reason.

Turning documents into instructions

A source can contain text that tries to change the assistant’s behavior. OWASP describes this indirect prompt injection in files and other external sources. ^[6] Separating content from instructions helps, but doesn’t provide a complete guarantee. Access controls and tool restrictions must still work even if the model misinterprets that text.

Evaluating only easy answers

Asking for a product name proves little. Before expanding the system, I’d test superseded decisions, conflicting sources, unanswered queries, and revoked access. Alongside the answer, I’d log what was retrieved, under which permissions, and how many tokens were sent. That lets us distinguish a retrieval failure from an interpretation failure.

Where I’d start building

I’d start with a narrowly scoped project, identified sources, and real queries that currently require manual searching. I’d handle retrieval, updates, and permissions first, then introduce structured memory when we needed to query explicit decisions.

Actions can wait until reading works well. The enterprise agent architecture adds the components needed to move from answering to executing, with boundaries worth keeping clear.

My criterion for choosing complexity would be concrete: can we retrieve that decision, check why it was made, and detect that it no longer applies? If we still can’t, adding more connectors just gives us more places to get things wrong.

Sources

1. OrgLogic’s Company Brain: use of the term for a shared knowledge layer with sources and access controls.
2. Company Brain documentation: proposal extraction, review, and versioned facts with evidence.
3. How Glean accesses information: retrieval governed by permissions in connected sources.
4. Retrieval-Augmented Generation, Lewis et al.: combining generation and retrieval from external memory.
5. MCP architecture: context exchange through resources and tools, independent of how the LLM is managed.
6. Prompt Injection, OWASP: indirect injection and measures to limit its effects.

Frequently Asked Questions

Does a company brain need a custom-trained model?

No. We can keep knowledge outside the model and retrieve the information needed for each query. Retraining is a separate decision and doesn’t solve source updates or permissions on its own.

What’s the difference between a company brain and RAG?

RAG is a technique that combines retrieval and generation. Company brain is a broader label for an organizational knowledge system, which can use RAG and add synchronization, structured memory, or tool integration.

Can it access all company data?

It should only access connected sources authorized for that person or agent. Having a shared index doesn’t justify returning the same content to everyone.

Do we need a knowledge graph?

No. It makes sense when we need to represent and traverse relationships that document retrieval doesn’t handle well. For an initial set of documentation questions, search and metadata may be enough.