Building a context layer for enterprise AI is less an infrastructure problem than an architectural conviction problem. The infrastructure (storage, query engines, federation tooling, MCP servers, vector stores) is mature. What stalls context-layer programmes is the set of decisions teams make before any of that infrastructure becomes useful. Decisions about where the layer's meaning comes from. About who owns it. About what "done" looks like for the first use case, and whether the second use case can build on it without starting over.
This guide is for the CTOs, Heads of Data and AI, and enterprise architects who have read enough about the category to know they need one, and now want a sequence they can follow. We give you five principles that decide whether the layer survives production, four phases of building it, and the architectural decisions sitting inside each phase. If you’re new to the term itself, start with our comprehensive guide: What Is a Context Layer? A Definitive Guide for Enterprise AI. Then, come back here.
One number to set the stakes: MIT NANDA's State of AI in Business 2025 report found that 95% of enterprise generative AI pilots have failed to deliver measurable P&L impact, despite roughly $30 - 40 billion in spending. Technology isn’t the constraint. Context is.
Why context-layer builds stall before they ship
A context layer sounds like an infrastructure project when it’s not. What stalls the build is the set of architectural decisions a team has to make before the infrastructure becomes useful.
What the layer is supposed to do is unambiguous: deliver governed, current, connected meaning to AI agents at runtime. What it costs to do that well is not obvious from the outside. It costs deciding where the layer's meaning comes from, who owns it, what "done" looks like for the first use case, and what reuse looks like for the next one. Teams that skip these decisions don’t skip them; they make them implicitly. The catalog becomes the de-facto model. The first team that builds something becomes the de-facto owner. The first use case becomes a bespoke artefact that the second team cannot extend. By the time anyone notices, the layer has solidified around choices nobody made on purpose.
Three recurring failure modes
Three failure modes recur across enterprise context-layer programmes, and the five principles in the next section are designed to prevent each one.
Meaning by accident. Teams that begin with whatever model their source systems imply end up encoding the limitations of those systems into the layer. The resulting context is an aggregation of how individual systems happen to describe the world, not a coherent model of how the business works. As EY argues in its piece on ontologies as the missing layer in enterprise AI, the most expensive failures here get diagnosed as model problems when they are really meaning problems.
Freshness without an access strategy. Every context architecture pays a tax somewhere. If teams copy operational data into unmanaged stores, they pay in staleness and reconciliation effort. If they refuse to pre-organise or materialise context at all, they pay in latency, runtime extraction, compute, and token consumption. The failure mode is not copying itself. The failure mode is failing to define which context must be live, which can be cached, which should be streamed, and which should be materialised for repeated analytical or agentic access patterns.
The second use case that never compounds. The first use case ships. The second team starts and finds that the ontology, mappings, and governance from the first do not extend cleanly. They rebuild. The organisation now has two context layers, the architecture committee meets to discuss "convergence," and the executive sponsor has stopped returning calls.
Five principles for building a context layer that survives production
Each principle below is a decision the build will force the team to make, whether they make it consciously or not. Making them consciously is the difference between a context layer and another stalled initiative.
Principle 1: Start from meaning, not metadata
The single most consequential early decision is where the layer's spine comes from. The two options are an ontology, modelled top-down from how the business works, or an aggregation of what already exists in source systems i.e., catalog entries, glossary terms, lineage records. Both have a place. Only one belongs at the spine.
Every downstream capability inherits from whatever the spine encodes. Reasoning, explainability, cross-system queries, decision traces etc. A catalog spine encodes what data you have. An ontology spine encodes how your business works. We’ve argued at length, including in our piece on ontologies as the intentional core of a true knowledge graph, that this is the decision separating production-grade context layers from sophisticated documentation. The trap is treating ontology modelling as a phase-two improvement. By phase two, the catalog's implicit model has calcified into the layer and is expensive to undo.
Principle 2: Choose the right access pattern for context
70 to 80 percent of enterprise knowledge lives in operational systems such as SAP, Salesforce, PLM, MES, finance, and custom applications. Building a context layer that requires blindly copying operational data into another store creates freshness and governance risks. But avoiding copies altogether is not the goal.. By the time the copy is complete, the source has moved.
The architectural choice is federated query and in-place access, with the ontology providing the unifying model. Use federation where live access is valuable and affordable. Materialise, cache, or stream context where repeated access patterns, latency, cost, or governance make that the better architectural choice.. We’ve explored the trade-offs in our case for why semantics, not zero-ETL, wins in the enterprise. Stale context is worse than missing context, and unmanaged replication creates stale context at scale. Managed materialisation, streaming, and cache invalidation can be valid parts of a context-layer architecture.
Principle 3: Open standards, or you do not own your context layer
A context layer is a multi-decade enterprise asset, not a project deliverable. A layer trapped inside a proprietary platform isn’t really an asset; it’s a future migration with a friendly name. Practically, this means standards-based representation (RDF, OWL, SHACL) for the ontology, and open protocols for agent delivery.
Model Context Protocol is now the de-facto interface between context layers and agents, and it deserves its place. But MCP is plumbing, not the layer itself. Behind a useless context layer, MCP delivers useless context faster. We’ve written about this in our take on why simplicity alone is not an architecture. The protocol matters; what it carries matters more.
Principle 4: Govern from day one
Lineage, versioning, semantic access control, and audit trails are not phase-three concerns. The context layer is the system AI agents will increasingly act on, and ungoverned context is a regulatory and operational exposure. GDPR, HIPAA, the EU AI Act, and adjacent regulations all treat the meaning surrounding a decision as part of the decision itself.
The capabilities to plan for are concrete. Ontology versioning, so a definition that changed last quarter does not silently overwrite the rules that governed a decision made three quarters ago. Semantic lineage from business concept down to source column, so an answer can be defended. Semantic access control, so a role can see Employee without seeing Salary. An audit of which context was assembled for which decision. Retrofitting any of these is consistently more expensive than building them in. Anthropic's guidance on effective context engineering makes a related point from the AI side: what gets delivered to an agent matters as much as how the agent reasons over it, and governance is what makes that delivery defensible.
Principle 5: Build for the second use case from the first one
The economics of a context layer flip on the second use case, not the first. If the second team has to redo the ontology work, the integration work, and the governance work, the organisation doesn’t have a layer. It has a project that’s happened twice, and those two projects now compete for the same architecture budget and the same executive sponsor.
The way to avoid this is to design every artefact of the first build (ontology, mappings, governance patterns, sample queries) for reuse from the start. Document the interaction patterns. Extend the ontology rather than rebuild it. The process is compounding: the same four phases repeat per use case, but the ontology and infrastructure carry forward. Each cycle is faster and broader than the last. That compounding is where the layer pays for itself.
Reuse is not a documentation exercise. It is an architectural constraint: modelling conventions, compatibility rules, semantic versioning, mapping patterns, and access patterns must be designed so that the second use case extends the first rather than competing with it.
The four phases of building a context layer
The work splits cleanly into four phases. Within each, the team faces a small number of decisions that matter more than the rest. Treat the phases as a sequence; do not skip Phase 0.
Phase 0: Preparation: scope and validate before you model
The goal of preparation is a high-value, multi-system use case with clear ownership and a validated technical basis. This is the phase organisations consistently skip and consistently regret skipping.
The decisions that matter here: which workflow has frequent exceptions, cross-system context, and real risk if the agent is wrong; who owns the build end-to-end; which technology baseline you will use. The right first use case is not the most strategically attractive one. It’s the most tractable one, as ambiguity is expensive, the data needed exists in two or three connected systems, and the workflow can carry a working agent within a sensible timeframe. The trap is starting with the workflow that will impress the board, rather than the one that will produce a reusable artefact. The done-state is a named owner, a scoped use case, an agreed technology baseline, and executive sponsorship for the modelling work to come.
Validation is not a gate that closes after Phase 0. Treat it like continuous integration: every ontology change, mapping, and retrieval pattern should be tested against example questions and expected business answers.
Phase 1: Build the first ontology
The goal of Phase 1 is a validated, business-language ontology that captures the entities, relationships, rules, and constraints relevant to the scoped use case. This is the spine the rest of the build inherits.
Three decisions sit at the centre.
- How much to reuse versus model from scratch: start from established upper ontologies and extend per domain.
- How prescriptive to be: enough to support reasoning, not so much that the modelling itself becomes the project.
- Who participates: business subject-matter experts and IT together, never IT alone.
For a first use case, a useful sizing guideline drawn from practitioner writing on context graphs is 8 to 15 entity types and 15 to 25 relationship types, in business language. We have written more about this discipline in our piece on ontologies as the stable foundation of a knowledge graph.
The trap is not quality. The trap is scope. A first ontology should not try to model the whole enterprise, but the part it does model must be stable, precise, and designed with compatibility in mind. As with APIs, semantic schemas become hard to change once applications and agents depend on them. The right target is a narrow, high-quality partial ontology and not a sprawling enterprise model and not a disposable prototype.
Phase 2: Integrate operational data through the ontology
The goal of Phase 2 is a knowledge graph that links the ontology’s concepts to operational reality across CRM, ERP, PLM, MES, finance, and other systems. This does not mean forcing every source into a single physical store, nor does it mean pretending that live federation is always the answer. It means mapping operational data to the ontology and choosing the right access pattern (federation, streaming, caching, or materialisation) based on freshness requirements, query patterns, latency, cost, and governance.
Three decisions dominate. Federated query versus replication - federate where technically possible. Entity resolution - the same Customer across SAP, Salesforce, and finance has to resolve to the same node. Data quality minima - what level of cleanliness is acceptable as a starting point and what gets cleaned later. The case for treating the knowledge graph as foundational rather than supplemental is laid out in our argument for knowledge graphs as the foundation of modern data architecture.
The trap is treating this phase as conventional ETL without semantic intent. Data movement may be necessary, but the organising principle must be the ontology and the access pattern, not another warehouse schema.. The done-state is an ontology connected to live data, with the example queries from Phase 1 returning real answers and entity resolution conflicts resolved.
Phase 3: Connect applications, AI, and agents
The goal of Phase 3 is to expose the layer to the systems that will consume it (BI tools, LLM-based assistants, agents, custom applications) through governed, standards-based interfaces. This is the phase where the investment becomes visible to the business.
The decisions: what to expose through MCP versus custom APIs; where to enforce access control (at the context layer, not at each agent as the latter is fragile); how to capture decision traces back into the layer so it learns. Retrieval patterns matter as much as the interfaces themselves; we’ve walked through the design choices in five decisions that shape your schema-RAG agent. The trap is exposing the raw graph to agents without governed retrieval patterns. An agent throwing SPARQL at a hundred-thousand-triple graph performs badly. Agents need curated interaction patterns mapped to the ontology. The done-state is the original use case running in production, at least one agent or application drawing on the layer reliably, and integration patterns documented for the next use case to reuse.
The phases compound
The process isn’t a one-shot pipeline. After Phase 3 closes on the first use case, the team begins Phase 0 again for the next one, but now with most of the ontology and infrastructure already in place. Each cycle is faster, broader, and produces less marginal work than the last. The economics of the context layer come from this compounding, not from any single project. If the second cycle is the same size as the first, something has gone wrong with one of the principles in the previous section, almost always Principle 5.
How d.AP operationalises these principles
d.AP is built around a delivery model that mirrors the four phases. Phase 0 runs as scoping workshops with business sponsors and IT to identify a high-value, cross-system use case.
In Phase 1, we bring foundational ontology patterns and tailor every model per enterprise i.e., top-down, business-driven, not data-driven.
In Phase 2, we connect semantic mappings across SAP, Salesforce, PLM, MES, finance, and custom systems using the access pattern that fits each source and use case: federation where live access is valuable, governed materialisation where context must be reorganised for performance or reuse, and caching or streaming where repeated access patterns require it. The ontology remains the stable spine across all of these choices.
In Phase 3, we expose the layer through standardised interfaces (MCP, A2A) alongside our own Aluna assistant and Graph Explorer for direct human use, with reusable dashboards composed against the ontology.
Three properties make the approach durable.
- Ontology-first by design: the ontology is the spine, not documentation added later. This connects to Principle 1.
- Open, portable, and access-pattern aware (RDF, OWL, MCP, A2A) so context remains the customer's asset and is portable across vendors. This connects to Principles 2 and 3.
- Governed and compounding: versioning, semantic lineage, semantic access control, and a process that compounds with each use case. This connects to Principles 4 and 5.
For readers comparing options, we maintain a more direct view of where we sit alongside other vendors in our comparison of enterprise knowledge graph platforms.
What a successful first build looks like
The hardest part of a context-layer programme is not the technical work. It’s convincing yourself, and your steering committee, that the first build is actually working. Three signals separate a working layer from another impressive demo.
The first: the same business question, answered the same way, by an agent and by a human analyst. If two paths to the same question return different answers, the layer has not unified meaning yet.
The second: the second use case takes meaningfully less effort than the first. If the second team has to redo the ontology, the mappings, or the governance, you have a project, not a layer.
The third: you can answer a previously-impossible cross-system question. Something like "list all active contracts for strategic customers affected by a specific supply chain disruption". This is a question that requires reaching across CRM, ERP, contract management, and operational data, governed by current rules. The new answerability is the proof. The same pattern shows up in our supply chain risk management use case, where the value of the layer is exactly the ability to ask questions the existing systems could not answer.
Where to start
The most important first decision is not which platform you will use. It’s which workflow you’ll scope. Pick one where the cost of ambiguity is high, the data genuinely lives across multiple systems, and the team owning it has the authority to act on what the layer tells them. Everything else follows from a well-chosen first use case.
If you want help making that decision, talk to the d.AP team about scoping your first ontology-driven context layer. The scoping workshops are deliberately short and concrete: a working session with your business and IT leads to identify the workflow, validate the ontology approach, and outline what the first build looks like.
