# The Enterprise Knowledge Layer > Source: > Published: 2026-07-20 15:32:41+00:00 ## A manifesto for context-rich enterprise AI When enterprise AI fails, it’s not because of the model. Frontier LLMs arrive every few months, cheaper, better, and in everyone’s hands. Enterprise AI doesn’t fail because of the scaffolding either. The harness has matured: tools, orchestration, evaluation, guardrails. Teams know how to build agents now. And yet, with the same models and the same harness, different companies get wildly different results. The difference is somewhere else: the AI that fails is the AI that doesn’t understand the business it’s acting in. We’ve spent years helping organisations deploy agents, and we’ve learned that the only way to solve that problem is a shared, governed substrate where enterprise knowledge lives. We call that substrate the [Enterprise Knowledge Layer (EKL).](https://neo4j.com/product/knowledge-layer/) Why doesn’t the AI understand the business? Because the meaning and institutional knowledge were never written down. Enterprise data was built for applications and for people, and applications and people supplied the meaning themselves. The app knows that *status = 2* means *“suspended pending review”*. The analyst knows it too. It’s in the application code, it’s in the analyst’s head. But it’s nowhere the agent can read. Your agent can have access to the best LLM intelligence, but it’s missing the meaning of your enterprise data; what makes your organisation different from the rest, including your organisation’s relationships, history, and decisions. This is implicit semantics, and it’s where every enterprise AI failure begins. The natural response, and the one most teams are building right now, is to give each agent the knowledge it needs, built right into the agent itself. A definition in the prompt. A custom tool in an MCP server that captures what the statuses mean. A retrieval pipeline that fetches the right context. And it works: the demo is great. But notice what just happened: portions of meaning now live inside each agent. Do that across ten agents, and the enterprise has made ten private copies of itself. This is semantic duplication, and duplicates will inevitably drift. *“Active customer”* gets redefined in one team’s MCP server this quarter, in another team’s agent prompt next quarter, and maybe never in a third team’s agent. Nothing breaks loudly. No alarm goes off. The enterprise just stops having one consistent understanding of itself. This is why agents are cheap to create but expensive to get to a state that delivers consistent value. And it’s why the instinct to fix them by piling more logic and more context into each agent is exactly backward: every addition is one more copy to keep in sync. The fix is the opposite: **lighter agents over a smarter shared substrate**. Take the meaning out of the agents and put it into a single governed place that they all read from. Defined once, agreed across teams, versioned, drawn upon from everywhere. Agents shrink to what they’re good at: interpreting intent, planning, acting.** Enterprise AI scales when agents get thinner, and the substrate gets smarter. ** ## What is the Enterprise Knowledge Layer? The Enterprise [Knowledge Layer](https://neo4j.com/blog/agentic-ai/knowledge-layer/) is a shared, governed substrate where an enterprise’s knowledge lives. It’s accessible to agents, tools, and applications, and operates on three main components, each mapping to one thing every consumer needs: the **EKL ontology** provides a live map of the enterprise from the raw data assets to the business concepts they represent and the processes that are built on them. The **enterprise data **for grounding, and the **memory** for learning and traceability. These three parts are connected and become actionable in the EKL, effectively making **organizational knowledge as queryable as data and as actionable as code**. You can think of the EKL as a service that helps agents interpret what’s being asked, find the trustworthy data, bring the right knowledge to bear at the right moment, and act within policy, all from one governed model of the business (the EKL Ontology) rather than each agent rebuilding that understanding from scratch. One clarification before going further, since the space is full of similar-sounding terms: the Enterprise Knowledge Layer is not a business intelligence (BI) semantic layer, or a generic context layer bolted onto retrieval. We’ll come back to how they relate to the EKL and why both are valuable, but neither one is sufficient for agents at enterprise scale. The **EKL ontology** captures the enterprise’s model of itself: A live, formally defined, connected map of how the business actually runs. It includes the business-facing terms and the domain model behind them, the people behind the work (roles, responsibilities, hand-offs), the processes that work moves through (credit review or AML screening in a bank; provisioning a service in telco; the monthly close or a support escalation almost anywhere), and the systems and data assets supporting them. It also holds the logic that describes and constrains all this (a refund can’t exceed the original charge; a subscription belongs to an account; a data product must be backed by an accessible data asset), as well as the mappings that tie business-facing elements back to technical assets. **Enterprise data** is the grounding that instantiates the domain model described in the ontology. The EKL relates to each of the three traditional categories of data (reference, master, and transactional) differently: Reference data is often managed as an extension to the ontology and represents the controlled set of values a concept is allowed to take. If your business-facing ontology defines a category like “country,” you’ll want its instances restricted to a governed, unambiguous list of countries rather than whatever strings happen to appear in a column. Master data and transactional data can remain external, be queried in place, or be drawn into the EKL as materialized or virtualized domain graphs. Which of those two modes applies, and when you’d choose one over the other, is a design question that deserves its own treatment. Finally, **memory** is the part that compounds. Every agent interaction with the EKL leaves a decision trace. Take the “check compliance” activity in an account opening agent. It requires verifying a government-issued ID. The ontology knows two systems can satisfy this: motor vehicle records and passport verification. But it’s memory that knows which one to use: for this customer segment, motor vehicle records resolved faster and cleaner in every past run, while passport verification was the path that worked when the applicant was foreign-born. The ontology holds what’s possible; memory holds what’s proven. That “why” used to live in an analyst’s head or a closed ticket, re-derived from scratch every time. Memory enables capturing it as a by-product of the work itself, and it means the next account-opening agent execution starts from everything the last thousand already learned. ## How does the EKL work? The Enterprise Knowledge Layer isn’t just definitional like a data catalog; it’s executable. Architecturally, it’s software that sits between your data assets and the agents and applications that access them. Agents can’t simply read it once and carry it along: it is far larger than any context window to begin with, and more importantly, enterprise knowledge is dynamic. This means definitions change, sources shift, and memory accrues, so a static version or a cached copy would be both incomplete and stale. Agents query the EKL continuously as they work, pulling exactly the meaning, data, and policy each request needs. Here’s what that means concretely. An agent gets a request: *“What’s our exposure to this customer?”* and on its own, it has to guess what every word means, which systems to hit, what it’s allowed to see, and whether the numbers it gets back can be trusted. The EKL takes that work off the agent. Given the request, it: **interprets the intent** against the business model: what*“exposure”*and*“this customer”*actually refer to here;**assembles the context** the request needs and**selects the sources** that can answer it authoritatively;- If the data is external to the EKL, it **generates the queries** and**routes the tools**, translating business concepts into concrete calls against real systems; If the data is accessible in the EKL, it queries it and returns the results to the calling agent. **enforces policy and access control** in the same step, not as an afterthought, but as part of resolving the request, so the agent only ever sees what it’s permitted to;**explains and captures the trace** of how it got there, and**updates memory** so the next request starts further along. The agent still does the execution. The EKL does the grounding, turning intent into a governed, sourced, trustworthy action plan. ## You don’t buy a knowledge layer. You engineer it. Mostly bottom-up. The knowledge layer encodes your specific business, so unlike the infrastructure it runs on, there’s no version of it to buy. A vendor can sell you every ingredient: a graph platform, a catalog, a policy engine, and you’d still have none of your business in it. The contents are your meaning: your definition of revenue, your data estate, your governance model, and the way your agents are allowed to behave. A graph is the natural substrate, since what you’re encoding is naturally connected: concepts related to concepts, mapped to systems, wrapped in policy, threaded with lineage and memory. That’s why a platform like Neo4j gives the EKL a foundation and a framework to build and reason over, but the knowledge acquisition effort is still yours. What makes it tractable is the method: repeatable best practices refined across many customer engagements, paired with LLMs that accelerate the whole process, which is what finally makes knowledge acquisition viable at enterprise scale. Because that used to be the hard part. The old way meant a committee writing definitions, analysts hand-drawing mappings, and a multi-year project to document the business before any agent could touch it. Concepts have to be sourced from processes, mapped to systems, and their contradictions reconciled, by hand that never finishes, but it’s exactly what LLMs are good at. And they work bottom-up, from ground truth: reading the actual schemas, proposing what each table means, suggesting mappings, flagging where two teams define the same word differently. But the LLM proposes; humans ratify. It can suggest the authoritative revenue column, but someone owns that decision. It can surface that sales and support define *“active customer”* differently, but which one is the canonical one is a business call. So the approach is effectively hybrid: bottom-up discovery, where LLMs accelerate acquisition, meets top-down governance, where the organization defines what’s authoritative. This hybrid model is reinforced by reuse: industry-specific models, formal standards, and patterns learned from hundreds of deployments provide a strong starting point rather than a blank sheet. Every organisation is unique, but much of the conceptual backbone of a domain is shared. Reusing those core elements becomes an important accelerator in populating the EKL, while still leaving room for each organisation to define the distinctions that matter to its business. And the layer keeps improving itself every time it’s used. Every query resolved, every definition that proves ambiguous, every mapping that returns something surprising signals where the layer is thin or wrong. All decisions get traced and fed back, so it improves as a byproduct of the work it’s already doing, instead of decaying from the day it ships. Remember, the EKL makes knowledge as queryable as data and as actionable as code, and by doing that, it enables software development practices on it. Not the slow, boil-the-ocean governance of the past. Bottom-up, highly automated, continuous, and governed, but with experts always in the loop. ## The ontology-based semantic layer When implementing the EKL, customers often start with what we call the **ontology-based semantic layer (OBSL)**. It’s the core of the EKL: the ontology and its reference data, plus the tools that operate on them. Data is kept external and queried in place. Given a request, the OBSL interprets intent against the business model, determines which data assets hold relevant information and which platform hosts them (Snowflake, Oracle, Salesforce, S3), applies policy, and points the agent there to query in place. Nothing is moved or copied: the knowledge lives in the layer, and the data stays where it is. The OBSL is the map and the compass: it decides what context matters, where it comes from, and how it may be used; the agent does the rest. ### What is in the EKL ontology? The ontology captures a connected representation of the enterprise across several layers: - The **technical ontology** captures all the details about the systems, data sources and data assets. It’s built from metadata catalogs, from inspecting the data sources directly, or from parsing the query logs. - The **domain (or business) ontology** captures the key entities to the business and the relationships between them. Customers will often align with industry standards like FIBO in financial services, or SNOMED in life sciences, but most of the time will use their own, sometimes partially aligned with those standards. Where a customer already manages their domain ontologies in specialised tools like TopQuadrant or Protege built on W3C standards such as OWL, RDFS, or SKOS, the EKL is populated via direct import. Where no such practice exists, LLM-assisted tooling can bootstrap them from the enterprise’s own material: competency questions the business needs answered, sample data and/or schema information from the systems in the technical ontology, existing glossaries and models, grounded in ontology engineering best practices. The technical and business ontologies are linked through data product definitions.** **Where these are already managed (for example, in MS Purview, Databricks Unity Catalog or as DPROD descriptions), the mappings import directly. Otherwise, the same LLM-assisted, human-curated approach applies: proposing the linkage for a person to ratify. - The **business process ontology** captures a detailed description of the enterprise’s key processes: tasks, activities, decision points, and the flow between them. Where organisations run process platforms like Celonis, Camunda, SAP Signavio, or even their own in-house developed ones, this layer is built by importing from them. Otherwise, the same approach applies, reconstructing the flows by applying process-formalisation techniques and methodologies for knowledge acquisition. - Finally, the **policy ontology** and the**organization ontology** complete the picture. The policy ontology captures the rules that govern access and use: who may see what, under which conditions, and what an agent is permitted to do with it, so governance is expressed in the model rather than bolted on to it. The organization ontology captures the enterprise’s structure: units, roles, ownership, responsibilities, giving every concept, asset, and policy a place in the org and a party accountable for it. The approach is modular, so organisations gain value from the first layer alone and add the others as they are available, and this is often driven by the organization’s data maturity. The framework itself: the layered structure that organizes the ontology and the way its parts connect, is distilled from years of work across many customers and verticals. That’s what accelerates construction: you’re not designing the shape of your knowledge from scratch, you’re populating a proven one. The full EKL extends the OBSL in two directions. It can bring data into the layer so it can serve answers directly rather than just point to them. A credit-risk agent that repeatedly needs exposure across loans, collateral, and counterparty data (and some graph analysis over the result) shouldn’t re-federate three systems on every call. Materialising that slice as a domain data product inside the layer turns a slow multi-source query into a fast local one. And it can add memory: the reasoning traces, history, and accumulated context that let each request start further along than the last. The first time an agent works through an AML escalation, it reasons the path out step by step: when we capture that trace and the EKL distills the recurring pattern into a reusable process, the next escalation starts from a known playbook instead of first principles. Meaning, grounding, experience compounding over time. The EKL ontology is governed, kept in sync, and versioned. How that works, and the main access patterns, etc., will follow in later posts. ## What the Enterprise Knowledge Layer is not Two things sit close enough to be mistaken for it. The first is the **BI semantic layer**: the metrics layer in tools like Looker, dbt, or PowerBI. It pins down how a metric is computed, so*“revenue” *is the same number in a finance dashboard and a board deck. Useful, but a metric is an atom, a single value, standing alone. Consider what happens when an agent is asked a question a metric can’t answer on its own: *“Which of our at-risk enterprise customers have an open renewal in the next quarter, and who owns them?”* A BI semantic layer can define *“at-risk”* and *“renewal value”* as clean, agreed metrics, but it has no idea that a *customer* connects to a *subscription*, that a subscription has a *renewal date* and an *account owner*, that *“enterprise”* is a segment defined (one way in sales and another in finance), or that whether a churned-but-reactivated account counts as *“at-risk”* is a governed business rule. The metrics are just numbers floating free of the entities they describe. The ontology is the model that those atoms live inside: what a customer is, how it connects to a subscription, which processes produce it, which rules constrain a refund, and who owns each definition. The metric layer gives you the number; the ontology tells you what it means in the business around it, and the real answer to that question needs both. **BI was built for reports, not agents.** The second is the **context layer**: a semantic layer extended with unstructured data, so an agent can pull in documents alongside metrics. Closer, and an improvement, but still aimed at the wrong target: it enriches what the model sees, it doesn’t govern what the enterprise *means*. Both lack the same thing: authoritative sources, lineage, policy enforced in the moment, and mappings to real systems. You won’t find these things in either layer. A context layer feeds the model better material; a BI semantic layer harmonizes metrics for reporting; an Enterprise Knowledge Layer decides, and stands behind, what that material means and how it may be used. ## Operating the knowledge layer as shared infrastructure A knowledge layer fails the moment it becomes one team’s project. Built by the data team alone, it encodes their view, and no one else trusts it; owned by a central modeling group, it can’t keep pace with domains it doesn’t live in. It only works as shared infrastructure: the same lesson data mesh learned about data, now applied to meaning itself: ownership belongs with the people closest to it, not in a central bottleneck. So the division of labor maps cleanly onto the data mesh’s principles. Domain teams own their corner end to end: the meaning, and the data products and mappings that realize it, because only they can say what “active customer” means in their world and live with the consequences of getting it wrong. Platform teams own the shared substrate, keeping it reliable, queryable, and versioned. Governance is federated, not centralized: a cross-domain function sets the global rules that keep the layer coherent. Authoritative sources, access, risk boundaries, while domains keep local control of their own definitions, and that policy is computational, enforced in the layer at query time rather than in a monthly review. The AI engineers building agents consume all of it rather than rebuilding it in every application. Where the knowledge layer goes beyond data mesh is what gets federated: not data products, but the meaning, mappings, and policy that say what those products mean and how they may be used. The same bet, one level up. That makes the layer the contract between groups that usually talk past each other: business, data, and AI, who have always drifted apart. When meaning lives in one governed place, each group owns its share, and it becomes the agreement itself: explicit, versioned, shared, instead of renegotiated for every project. Build it once, and every agent that follows inherits the alignment instead of reconstructing it. ## Intelligence is a commodity Intelligence is a commodity. Knowledge is the moat. When every enterprise can rent the same frontier model by the token, the only durable advantage left is the one thing that was always yours and never for sale: a faithful, governed understanding of your own business. The organisations that win the next decade of AI are the ones whose agents actually understand the business they’re acting in, because those companies did the unglamorous work of formalising their enterprise knowledge once, in a place every agent can stand on. So the question isn’t whether to build an Enterprise Knowledge Layer. It’s whether you start now, while it’s still an advantage, or later, when it’s just the cost of staying in the game.