Context layer (for AI agents)

What is a context layer for AI agents?

A context layer sits between your data and an AI agent and supplies the meaning of that data at the moment the agent asks for it. When the agent reaches for a table, the layer tells it what the company means by revenue, which measure is the approved one, where the numbers come from, whether the last load succeeded, and whether the person asking may see the answer at all.

The term is an umbrella. A business glossary, a semantic model with measures, a data catalog, lineage, data quality checks and access policies all exist as separate things, and most companies already have a few of them. What is new is wiring them into one service a machine can query, because an agent cannot walk over to a colleague and ask.

One way to picture it: everything an experienced analyst knows about your data but never wrote down, written down and put behind an endpoint. The agent asks, the layer answers with definitions, relations and permissions, and only then does the agent go and fetch numbers.

Why raw tables are not enough for an agent

Point an agent at a warehouse and it will find its way around the schema. The schema does not say what anything means, though, and a language model fills silence with a guess.

Column names lie. A column called amount can be net or gross, in euros or in the order currency, before or after discount. The agent reads the name and picks the meaning it has seen most often elsewhere.

The same word means three things. Sales calls a signed quote revenue, finance calls an issued invoice revenue, and the board pack uses recognised revenue after returns. An agent asked for revenue per quarter picks one and does not tell you which.

The agent cannot ask. An analyst who is unsure about a field asks the person who built the report. Whatever is not written down somewhere an agent can read does not exist for it.

Permissions live in the wrong place. Many companies control who sees what by deciding who gets which report. Once an agent can reach the underlying table, that control is gone unless the rule sits on the data itself.

Gartner put a number on this at its Data and Analytics Summit in London in May 2026: organisations that prioritise semantics in AI-ready data will, by 2027, raise agentic AI accuracy by up to 80 percent and cut costs by up to 60 percent. Whatever you make of the percentages, the direction matches what we see: agents fail on meaning far more often than on SQL.

The parts you already have, and the two that are usually new

Most of a context layer is assembly rather than construction.

• Business glossary. The agreed definition of each term, with an owner. Often in a catalog, sometimes in a wiki. The layer needs it in a form a machine can read, so the wiki version has to move.

• Semantic model measures. A Power BI semantic model already encodes how revenue and margin are calculated, in logic finance has signed off on. That is the best input you own.

• Catalog metadata. Table and column descriptions, sensitivity labels, certification status. The catalog knows which of the four customer tables is the certified one.

• Lineage. Where a number comes from and what it depends on, so the agent can flag that this margin figure runs through a mapping table changed last week.

• Data quality checks. Freshness and completeness results from your pipeline tests, so the agent can say the sales table has not loaded since Monday instead of answering with stale data.

• Access policies. Row-level and column-level security, sensitivity labels, workspace permissions. The layer has to enforce them on every call, with the identity of the person asking.

Two things are usually missing.

A machine-readable ontology. A glossary defines terms one by one. An ontology says how they relate: a customer places orders, an order has lines, a line refers to a product. Those relations let an agent answer a question that spans three tables without inventing the join. In practice this can be a small model with twenty entity types, generated from the semantic model you already have.

A serving interface. Everything above has to be reachable from inside the agent's loop. In 2026 that is usually an MCP server that exposes the definitions, measures and policies as resources and tools, or a semantic-layer API such as the one dbt ships with its MCP server. The interface is the difference between context that exists in a document and context an agent actually uses.

Example: gross margin per customer

A sales director asks an agent for the gross margin on customer Vandenbroucke NV in the second quarter.

Straight from the raw tables. The agent finds sales_lines with columns amount and cost, sums both for the customer and the period, and answers: amount 121,000 euro, cost 70,000 euro, margin 51,000 euro or 42 percent. Three things went wrong that the agent could not know. The amount column includes 21 percent VAT, so real revenue is 100,000 euro. Credit notes for 8,000 euro sit in a separate table the agent never joined. And cost is the standard cost at order time, while finance defines gross margin on landed cost, which adds 4,000 euro of inbound freight from another table.

Through the context layer. The agent first asks the layer what gross margin means. The layer returns the approved measure: net revenue after credit notes, minus landed cost, with a note that net revenue excludes VAT and that credit notes are booked in credit_notes. It adds that the customer entity is the billing customer, not the ship-to address, that the sales table was loaded this morning, and that the person asking is in the sales management role that may see margin per customer. The agent now computes 100,000 minus 8,000 for revenue and 74,000 for cost, and answers 18,000 euro, or 19.6 percent.

That is 42 against 19.6 percent on the same customer, and the first answer looked perfectly confident. Had a warehouse planner asked the same question, the layer would have returned the definition and refused the data, because margin per customer is not in that role's policy, and the agent would say so instead of guessing around the restriction.

Context layer versus metrics layer and knowledge graph

Context layer versus metrics layer

Separate them by what an agent gets back. A metrics layer returns a number: ask for gross margin by customer and it returns the figure, calculated by one governed definition. That is what it should do, and a good context layer uses the metrics layer for that job.

A context layer returns meaning, relations and permissions: what gross margin means here, how customer relates to order and invoice, which tables the measure depends on, when they were refreshed, and whether this user may see the result. The metrics layer answers the question. The context layer tells the agent which question to ask, from which source, and whether it is allowed to.

Context layer versus knowledge graph

A knowledge graph is a way of storing entities and their relations. It is a natural store for the ontology part of a context layer, and both Microsoft's Fabric IQ and DataHub build on a graph underneath. The context layer is the service on top: the interface an agent calls, the policy enforcement on every call, and the plumbing that pulls in measures, quality results and lineage from systems that are not graphs at all. You can build a context layer without a graph, and you can have a graph nobody serves to an agent.

How vendors package it in 2026

Microsoft announced Fabric IQ at Ignite in November 2025, with an ontology item in preview that defines entity types, properties, relationships and rules and binds them to lakehouse tables, event streams and Power BI semantic models. Microsoft's documentation describes the ontology as a business context layer that grounds agents in shared business language. An ontology can be generated from an existing semantic model, and the Fabric data agent queries with the identity of the user, so row-level and column-level security still apply.

Catalog vendors have repositioned around the term. Atlan now calls itself the context layer for AI and treats a semantic layer as one part of it. DataHub announced a Context Platform for analytics agents in May 2026, with an MCP server that serves definitions, proven query patterns and join logic, and cites a design partner whose agent went from around half to around 90 percent correct answers. Those accuracy figures are the vendor's own, but the mechanism they describe is the one above.

Decision traces and context graphs are the newest addition. Foundation Capital's essay on context graphs, from late 2025, argues that the missing record in most companies is not the data but the decision: which definition was used, under which policy, with which exception. Whether that becomes a product or a catalog feature is not settled, but it is where the umbrella is heading: from what the data means to why the last decision on it was taken.

Where an SME starts

You do not need a graph database or a new platform for most of the value. Four things, in this order, cover the common case.

1. Twenty defined measures in the semantic model. Take the questions people actually ask, follow them back to the measures they rely on, and give each one an approved definition and a plain-language description. In Power BI that is the measure description plus the AI instructions under Prep data for AI, saved on the model.

2. A glossary with owners. One page per term that has caused an argument, with the definition and the name of the person who decides.

3. A read-only serving endpoint. An MCP server or a semantic-layer API that exposes the measures and the glossary, runs with the identity of the person asking, and cannot write. Start with your platform's own agent where one exists, because the permission passthrough is already built.

4. A test question set. Thirty questions with the answer you expect, including a few the agent should refuse. Run them after every change to the model or the glossary. It is the only way to know whether the layer works rather than merely exists.

What to watch out for with a context layer

It does not settle the argument. If sales and finance have not agreed what revenue means, the layer serves the disagreement to the agent with more confidence. The definition work comes first and it is a management job.

Permissions belong in the layer, not in the prompt. Telling an agent in its instructions not to show salaries is not a control. The policy has to be enforced on the data call, with the user's identity, so a prompt injection or a clever question cannot talk its way past it.

A protocol moves context, it does not create it. An MCP server over a warehouse with no definitions behind it gives the agent faster access to the same ambiguity. The serving interface is the last piece, not the first.