In short
A purchasing manager is about to renegotiate a packaging supplier's contract and wants to know who in the company has negotiated with them before and what the last agreed terms were. The terms are in an amendment, the negotiation happened over an email thread, the buyer who ran the process moved to another department and the delivery history is in the ERP. An AI assistant that only reads documents finds the original contract and stops there. The enterprise knowledge graph, or corporate knowledge graph, is the model that links these pieces: content, people, systems, records and activity across the whole company. It is the central structure of the Company Brain, the layer that knows the company: which data exists, where it lives, how it connects and who can see what.
An enterprise knowledge graph is a knowledge graph built on an organisation's private data, with a practical goal: letting AI models and agents find and use the right context for each question. It represents the content the company produces, the people who work there, the systems where the data lives, the transactional records in those systems, the activity around all of it and the relationships between these elements.
The mechanics of nodes and edges are covered in this series' article on knowledge graphs. Here the focus is on what goes into the graph, how it is built and maintained, and which rules it follows to serve AI in production.
The academic literature uses the term in the same sense. The survey of knowledge graphs published by Hogan and co-authors in ACM Computing Surveys in 2021 describes enterprise graphs as structures internal to a company, applied to commercial use cases such as search, recommendation, business analytics, risk assessment and automation.
The layers live in the same graph. A query starts from a supplier, passes through a document, reaches a person and is filtered by the permissions of the person who asked.
Client, contract, product, order, supplier and project are the entities that transactional systems already record, with an identifier, attributes and state. They form the skeleton of the graph, because almost every business question starts from one of them.
Documents, emails, conversations, tickets and meeting transcripts come in as nodes linked to the entities they mention. The proposal links to the client, the minutes link to the project, the ticket links to the product.
This layer records who owns each account, who approved each contract and who works with whom. It also reveals subject-matter experts, such as the person who has resolved the most cases involving a given supplier. This is where the answer about who has negotiated with the packaging supplier lives.
What is consulted, by whom, how often and when it was last changed. These signals separate the document in use from the abandoned one. A policy that the legal team reads every week and revised last month carries more authority than an old copy kept in a personal folder.
The last layer records who can see each node and each relationship, and it runs alongside all the others. A contract visible to the controller's office may be closed to the marketing team. The relationship between a client and the negotiated margin may be more restricted than the client record itself.
Building it is continuous. The steps run again whenever the sources change:
With the ontology, the approved relationship and the commented relationship reach the model with different meanings, and the context shows who decided and who only took part.
A language model answers based on what it receives in context. The graph improves the choice of that context in five ways.
A corporate search for the travel reimbursement policy returns six versions of the same document. The graph knows which one the finance team published, which one is in force, which one is accessed most and which ones were replaced. The model receives the version in force, with its source shown.
Two analysts with the same name, a product with a commercial name and an internal code, an acronym that means different things in sales and in engineering. The graph resolves the reference from its surroundings, such as the project and team mentioned in the question.
Putting together the context for an implementation project means following a chain. The contract defines the scope, the emails record agreed changes, the tickets show open problems and the people linked to each item show whom to ask. Each step is a relationship in the graph, and walking the chain in one query spares the agent dozens of trial-and-error searches.
The same question about a client calls for opportunities and contacts for the account executive, and for SLA and incidents for the support analyst. The graph knows the department and the accounts of the person asking and prioritises the relationships closest to that role.
An agent that opens a purchase order, updates a record or replies to a client needs to know which entity it is acting on. The graph provides the correct identifier, the record owner and the applicable restrictions before the action, which reduces the risk of the agent writing to the wrong record.
Corporate search and RAG handle location questions well, such as where the travel policy is or which documents mention a project. Agents get other questions: why a client's credit release is stuck, who needs to approve the next step and whether the agent can carry it out without that approval. These are questions about relationships and state.
The knowledge layer that enterprise agents need beyond RAG is the piece between systems and agents that turns scattered artefacts into canonical, traceable concepts subject to permissions. A project shows up as an epic in the task tracker, a code repository, a chat channel and an incident record. Search returns each artefact separately, and the knowledge layer recognises that they all describe the same project.
In the stuck credit case, the client has a request, which follows a policy, which requires an approval, which is waiting on a specific role. With RAG, the model receives passages similar to the question and has to deduce those links. With the enterprise knowledge graph, the system walks the path and delivers the assembled chain, and the model only explains it and writes on top of it.
For the agent to know whether it can use or expose a piece of information, every node and every relationship carries metadata:
Without this metadata, a relationship extracted from an old email reaches the agent with the same weight as a current ERP record.
Each source has its own rules: the CRM restricts accounts by portfolio, the drive shares folders by group and the ERP limits financial data by profile. The graph has to apply these rules at query time, with the current state of each person's permissions.
The most serious risk of an enterprise graph is flattening permissions. When ingestion reads the sources with a broad-access service account and the graph answers everyone with the same slice, anyone can see through AI what they would not see in the source system. Relationships expose information too: knowing that there is a contract with a supplier under confidential negotiation is already sensitive data.
The right approach is inherited permissions. Every node and every relationship carries the source's access rule, and the query filters the result by the identity of the person asking. When a permission changes in the source system, the graph follows at the next sync.
Inherited permissions define what each person can read. When an agent prepares or carries out actions, authorisation extends across four points:
The output control deals with leakage through inference. An agent can combine permitted facts, such as a change of account owner, suspended orders and a meeting with legal, and reach a sensitive conclusion that no source records.
With agents in the processes, the graph keeps the operational chain: case, decision, evidence, approval, execution and outcome. This history makes it possible to reconstruct an earlier decision.
Validated facts, approved decisions and confirmed outcomes go into the graph. The agent's intermediate reasoning and tool calls stay in the audit log, so that an unverified output does not become a fact in later queries.
Public search graphs describe cities, companies and works, with stable facts visible to anyone. The enterprise knowledge graph describes a single organisation, with private data and access defined person by person.
Acronyms, project names and product codes exist only inside the company, and the ontology has to record them. Change is daily: contracts get amendments, people move departments, tickets open and close. That is why the enterprise graph works with continuous updates and a date on every fact.
There are two common ways to build the graph. The first starts from documents and collaboration tools (drive, wiki, email, chat) and organises written knowledge well.
The second includes live data from transactional systems, such as CRM, ERP, helpdesk and contract management. Those systems hold the invoiced amount, the order status, the contracted SLA and the outstanding balance. A graph made of documents answers what the company wrote about a client. With transactional systems, it also answers where the client stands today.
The Company Brain models both. The contract PDF and the contract record in the management system become linked nodes, the conversation about a price adjustment links to the invoice it produced, and the model receives over MCP the slice the question requires, with documents and records in the same context.
In the Company Brain, the enterprise knowledge graph shows up as three components that work together. The knowledge graph holds entities, content, people and relationships. The business ontology defines what each type means in that company. The semantic layer translates a natural language question into the right path through the graph and the sources.
Four properties come with this design:
In the purchasing case, the query starts from the supplier, follows through to the contract and the amendment, reaches the person who negotiated, finds the latest email about price and returns the current terms with the source of each item. The decision about the proposal stays with the manager.
The graph inherits the quality of its sources. The most frequent limits:
Modelling every layer before the first use tends to stall the project. The shortest path is to pick a question that today requires opening several systems and chasing people, such as who has negotiated with a given supplier or which version of a policy is in force.
That question defines the first entities, sources, activity signals and permission rules to inherit. The ontology also grows out of this flow. Responsible can mean the person who changed the record, the person accountable for the outcome or the person with authority to approve, and the right meaning is pinned down before expanding to other departments.
A set of test questions evaluates this case: whether the system identifies the same object across different sources, shows the path of evidence, respects permissions on inferred relationships and detects the missing approval before acting. Running the same questions with RAG and with a graph query shows where each approach fails.
With the answer working and traceable, the next use case reuses connectors, entities and ontology, and the graph grows in the direction of the questions the company asks every day.
