What Is a Context Layer for Unstructured Enterprise Content?

A context layer is the governed tier between an organization’s own information and the AI agents that query it. It is responsible for three things: assembling the right content for a given request, enforcing who is allowed to see that content at the moment of the request, and returning it in a form a model can actually use. Put differently, it is where retrieval, permission enforcement, and provenance become architecture instead of being improvised inside each application.

Almost every definition published so far describes that tier over structured data: metrics, tables, joins, and semantic models on top of a warehouse. That is a real half of the problem, and the easier half. The harder half is unstructured content: the documents, tickets, wikis, contracts, PDFs, policy manuals, and email threads where most enterprise knowledge lives and where nearly every access-control problem originates. This article defines the category as it stands at the end of 2026 and sets out what it has to do when content has no schema.

Why the category exists now

“Context layer” stopped being a blog-post coinage in 2026 and became a named analyst category. In August 2026, Gartner published a Market Overview for AI Context Platforms, defining AI context platforms as software that constructs, governs, and delivers reusable context to AI agents at runtime. The three verbs matter: constructing is retrieval and assembly, governing is access and policy, and delivering at runtime concedes that this is an online serving problem, not a batch modeling exercise.

Forrester frames the same tier by its lineage, defining the context layer as the next evolution of semantic layers and knowledge graphs, with a Landscape report due at the end of Q4 2026; you can read that framing in Forrester’s blog post on context layers. The two definitions are compatible. Both say the tier enterprises built for BI is now being asked to serve a different consumer with different demands.

Vendor movement in 2026 was fast and almost entirely on the structured side. Atlan extended its catalog toward agent-facing context. Snowflake shipped Horizon Context and Cortex Sense, Databricks shipped Genie Ontology, Microsoft shipped Fabric IQ, Glean shipped its Enterprise Graph, ServiceNow shipped a Context Engine, Pinecone shipped Nexus, and Redis shipped Iris. All are making the same bet from different starting positions: that agents need a governed, reusable description of enterprise information rather than a raw connection to it.

One caution, which analysts and trade press have been blunt about: a context layer is not a product you buy and switch on. It is a set of responsibilities something in your architecture has to own, and deciding what content is authoritative, what the retention rules are, and whose identity an agent acts under does not come in the box. For how this tier relates to what you already run, see our view of search as AI infrastructure.

Context layer, semantic layer, knowledge graph, ontology, and context engineering: what each one means

This is the question the category gets asked most, and the answers in circulation are mostly vendor-shaped. Here is a neutral version.

Term	What it actually is	What it is good at	Where it stops
Semantic layer	A business-friendly abstraction over structured data defining metrics, dimensions, joins, and naming, so “revenue” means one thing everywhere.	Making numbers consistent and queryable in natural language; stopping two dashboards from disagreeing about the same metric.	It assumes modeled tables underneath. It has nothing to say about a contract PDF, a Jira thread, or a policy manual.
Knowledge graph	An instance-level store of actual entities and the relationships between them: this customer, that contract, this incident, linked by typed edges.	Multi-hop traversal: “which contracts reference the clause this incident triggered.”	Building it over unstructured sources needs accurate extraction, and the graph is only as current as its last extraction run.
Ontology	The schema above a graph: the formal definition of entity types, attributes, and permitted relationships. The vocabulary, not the facts.	Enforcing consistency, enabling inference, and letting systems agree on what a “claim” or a “part” is.	It answers no questions by itself. It is a contract about meaning, still needing populated data and a retrieval path.
Context engineering	The practice, not a system, of deciding what goes into a model’s working context: what to retrieve, how much, in what order, and when to drop it.	Making one agent behave well within a finite context window and a finite budget.	Applied per application, it provides no connectors, permission enforcement, freshness, or audit on its own.
Context layer	The governed runtime tier that assembles, filters by entitlement, and serves context to agents across many applications, structured and unstructured alike.	Centralizing retrieval and access decisions so every agent inherits the same policy, freshness, and audit trail.	It will not set your content strategy, resolve conflicting source-of-truth claims, or fix permissions that are wrong in the source system.
RAG pipeline	An implementation pattern: retrieve relevant passages, then place them in the prompt before generation.	Grounding one application’s answers in specific content, quickly, with modest engineering.	A technique inside a context layer, not a substitute for one. Most RAG builds have no entitlement model and no audit.

The distinction people get wrong most often is semantic layer versus context layer. A semantic layer answers “what does this term mean, and how do I compute it correctly.” A context layer answers “what should this agent, acting for this person, right now, be given, and am I allowed to give it.” The first is a modeling problem solved at design time; the second is a serving problem solved at request time, containing an authorization decision a semantic layer was never designed to make. A semantic layer is an input to a context layer, not a smaller version of one.

The second confusion is ontology versus knowledge graph. The ontology is the type system; the graph is the populated instance data conforming to it. A graph with a weak or implicit ontology is common, and it degrades as teams add edges meaning slightly different things. An elegant ontology with almost nothing populated against it is equally frequent, and expensive. When a vendor says “ontology,” ask which of the two they are shipping.

The third is context engineering versus a context layer. Context engineering is what a good application team does inside one agent: trimming, reranking, summarizing, ordering the evidence. It is real skill. But if every team does it independently, you get a dozen different answers to “is this user allowed to see this document,” which is the condition a context layer exists to eliminate. Context engineering is the craft; the context layer is the substrate it runs on.

The half of the category nobody is building

Read the structured-data definitions closely and a consistent set of assumptions appears underneath them. A governed warehouse someone already curated. Modeled tables with stable schemas. Access policy expressible as row filters and column masks, attached to the table and evaluated by the query engine. Data created in order to be queried, which is why it has types and keys at all.

Now take a 300-page implementation plan in a SharePoint site whose permissions changed this morning because someone added a contractor to a group three levels up. Every one of those assumptions fails.

• There is no schema. The document has sections, tables, appendices, and a diagram with text inside it. Nothing declares which part is authoritative or what entity it concerns.
• Permissions live in six systems and change hourly. SharePoint groups, Active Directory nesting, Confluence space restrictions, ServiceNow roles, file-share ACLs, and one application’s own table. There is no single place to read “who can see this,” and no guarantee the answer holds five minutes later.
• Meaning is split across passages. The answer is often one paragraph on page 214 that only makes sense alongside a definition on page 12. Returning the file is useless; returning the wrong fragment is worse than useless.
• Duplication and versioning are the normal state. The same policy exists as a draft, an approved PDF, a wiki summary, and an email attachment. Three are wrong, and nothing in the content says which.
• It was never written to be queried. It was written to be read once, by a human who already had the context. Pronouns, implied subjects, and internal shorthand are everywhere.

None of this is fixed by a better embedding model. It is fixed by a serving tier that ingests from the systems of record, carries each item’s access rules alongside it, keeps both current, splits content into passages that retain their meaning, and evaluates entitlement on every request rather than at index time. That is the work Lucidworks does under the name AI Context Data Platform, applied to the unstructured side of the problem, and it sits behind our enterprise knowledge management solutions.

What a context layer for unstructured content has to do

Stripped of vendor framing, the functional requirements come down to six jobs, sequential in build order and simultaneous at runtime.

Connect. Bring every source together, from SharePoint and Confluence to ServiceNow and file shares. Each connector has to handle incremental change, deletions, throttling, and the source system’s own idea of identity. Content that is not connected is content your agents will confidently answer without. Our approach is described under data acquisition and connectors.

Secure. Permissions travel with the content. Access rules come along with every document and are checked each time someone asks. The agent sees exactly what the person asking is allowed to see, not a snapshot of what they could see when the index was built. This is the hardest requirement here, and the one structured-data definitions get free from the query engine.

Enrich. Find the passage, not just the file. Content is split into meaningful passages, so the agent gets the paragraph that answers the question instead of a 200-page PDF. Good chunking respects document structure, carries enough context that a passage stands on its own, and keeps a pointer back to the exact location for citation.

Find. Exact terms and meaning, together. Enterprise questions contain both: a part number, policy code, or error string that must match exactly, alongside an intent only vector search will catch. Neural Hybrid Search reads for keywords and for intent, which is why pure vector retrieval disappoints on the queries enterprises care about most.

Ground. Truth, not guesses. Every answer is grounded in approved content and cites its sources. Grounding is partly retrieval and partly policy: the layer has to know which content is authoritative and which is a superseded draft, and make that distinction visible to the agent.

Deliver. The right answer, or the right action, within policy. What was asked, shown, and answered stays on the record. For regulated buyers that record is the artifact an auditor asks for, and it has to capture the entitlement decision, not just the text returned.

How this relates to RAG, and why the model is shifting from push to pull

Early RAG was a push architecture. The application decided, before generation, what the model would see: run one retrieval, take the top passages, put them in the prompt, generate. The model was a passive consumer of a package someone else assembled. That pattern is still right for narrow applications with a predictable question shape.

The 2026 pattern is pull. The agent holds tools, decides at runtime what to fetch, reads what comes back, and decides what to fetch next. Retrieval is no longer one step before generation; it is a loop interleaved with reasoning. An agent working a support escalation might search the knowledge base, read an article, look up the customer’s entitlement record, then search again using terms it learned only from the first result.

Three things change in that shift, and all three land on the context layer, not the model.

• Retrieval happens many times per task. One user request may produce ten or thirty retrieval calls. Anything you did once per request, you now do thirty times.
• Latency and cost compound. A 400ms retrieval is fine once and unacceptable thirty times in series. Pull makes retrieval performance a product requirement, not an infrastructure detail.
• Permission checks happen on every hop. Under push you could, carelessly, authorize once and trust the package. Under pull the agent chooses where to go next, so every hop is a new access decision made for whoever the agent acts on behalf of.

That last point exposes the open problem in the category: agent identity. When an agent calls a tool, which calls another agent, which queries a repository, “whose permissions apply here” has to survive every hop. Most stacks either collapse this to a single service account (convenient, and a serious over-permissioning risk) or re-authenticate at each boundary with no shared notion of the originating principal. Nobody has fully solved delegated identity across layers, and a vendor who says otherwise is describing a roadmap.

Where MCP fits, and where it does not

The Model Context Protocol is the most important piece of plumbing in this stack and the most misunderstood. MCP is a transport and tool-calling standard: it specifies how an agent discovers tools and resources, how it calls them, and how results come back. It is the widely supported baseline, and standardizing on it is the right call. We have a longer explainer on what the Model Context Protocol is and why it matters for enterprise AI.

What MCP does not do is define what is on the other side of the call. It standardizes how an agent asks, not what comes back, whether that content is current, whether it is authoritative, or whether the requester is allowed to see it. An MCP server pointed at an ungoverned index is not an architecture. It is a liability with a standard interface: a machine-discoverable path to every document someone forgot to restrict. The protocol is doing exactly what it promised. Governance was always the other half.

Three related standards are worth tracking as of late 2026. A2A reached 1.0 in April 2026 under the Linux Foundation and introduced signed Agent Cards, a first credible step toward agents making verifiable claims about what they are and who operates them. WebMCP is on the W3C standards track, pointing at a future where web applications expose tools to agents natively. Open Semantic Interchange went live in January 2026 with Snowflake, Salesforce, Tableau, and dbt Labs as founding partners, aiming at portable semantic definitions. OSI is squarely a structured-data effort; there is no equivalent for unstructured content or for entitlements, which is a gap worth noticing.

The division of labor is clean. MCP is how the agent asks. The context layer is what answers, and what decides whether to answer at all. Our implementation of the first is the Lucidworks MCP Server, built so permission and provenance happen behind the protocol rather than being assumed away by it.

What to ask before you buy one

Every question below is answerable with a specific mechanism. If an answer comes back as a philosophy, treat that as the answer.

1. How do you acquire permissions from each source system, and how quickly does a permission change in the source take effect in retrieval results?
2. Is the entitlement check performed at query time against the requesting user, or applied at index time and cached?
3. When an agent calls on behalf of a person, how is that identity carried through, and what happens on a multi-hop call through another agent?
4. Which connectors do you ship, which handle incremental change and deletions, and which are built on a generic crawler?
5. How is content split into passages, and can you show me the exact passage boundaries and the citation pointer behind a given answer?
6. Does retrieval combine exact keyword matching with vector search, and can I see per-query evidence of which signal produced each result?
7. What is your p95 retrieval latency under an agentic workload of twenty or more calls per user task, and how is that priced?
8. What exactly is written to the audit record: the query, the documents considered, the documents returned, the entitlement decision, or all four?
9. How do you distinguish authoritative content from superseded drafts and near-duplicates, and is that distinction exposed to the agent?
10. Where does content live and where is it processed, and can the whole thing run inside our boundary if our regulator requires it?

Frequently asked questions

Is a context layer the same as a semantic layer?

No. A semantic layer defines what business terms mean and how to compute them over modeled data, mostly at design time. A context layer assembles and serves content to agents at request time and makes an authorization decision as part of that service. A semantic layer is a useful input to a context layer, but it does not cover unstructured content or runtime entitlement.

Do I need a context layer if I already use Snowflake or Databricks?

Honestly, you probably need both. Snowflake Horizon Context, Cortex Sense, and Databricks Genie Ontology solve the structured half well, over data already governed in those platforms. They do not address the documents, tickets, wikis, and contracts in SharePoint, Confluence, ServiceNow, and file shares, where permissions are external to the warehouse and change constantly. Most enterprises end up serving agents from both, which makes the integration question (how the two agree on identity and policy) worth asking early.

Can I just use MCP?

MCP solves the connection problem, not the governance problem. It standardizes how an agent discovers and calls tools; it says nothing about whether the content behind a tool is current, authoritative, or permitted for the requester. Point an MCP server at an index with no entitlement model and you have only made ungoverned content easier for agents to reach. Adopt MCP, and make sure something behind it owns access and provenance.

Is a context layer the same thing as RAG?

No. RAG is a retrieval and generation pattern one application implements. A context layer is a shared tier many applications consume, including connectors, permission enforcement, freshness, and audit that a typical RAG build does not have. RAG is a technique used inside a context layer.

Does a context layer need a knowledge graph?

Not necessarily. A graph helps with multi-hop relationship questions and entity-level reasoning across sources, but it carries real cost in extraction accuracy and maintenance, and a stale graph is worse than no graph. Decide based on whether your users’ questions actually require traversal, not on whether a graph appears in the reference architecture.

What is context engineering, and is it the same thing?

Context engineering is the per-application practice of deciding what goes into a model’s working context for a given task: what to retrieve, how much, in what order, and what to drop. A context layer is the shared infrastructure that discipline runs on, so every team is not independently reinventing how access decisions get made.

Is this something I buy, or something I build?

Both. Buy the connectors, the retrieval engine, the entitlement enforcement, and the audit trail, because those are hard, generic, and expensive to maintain. What you cannot buy is the decision about which content is authoritative, how long it is retained, and which identity an agent acts under in your organization. Vendors presenting a context layer as a switch you flip are skipping the part that determines whether the program works.