A semantic layer is not a context layer

They are both invaluable to agents, but they are distinct

There is a huge amount of hype around semantic layers right now. At Snowflake Summit last month it was one of the most talked-about ideas in the building; the whole event was organised around the argument that agentic AI runs on governed enterprise context. Serious independent voices are making the same case: Karl Ivo Sokolov calls the semantic layer “the single most strategic asset in the enterprise AI stack”, and argues that whoever builds it for a customer is best placed to build that customer’s entire agentic transformation. Semantic layers certainly have a critical role to play in the emerging AI stack. But a number of serious people are making the same mistake: assuming that role is the same as a context layer’s.

A semantic layer is not a context layer. It does a real job, and a durable one, but it is a fraction of the job many agents acting in the enterprise actually needs done. And the rest of that job is not a matter of putting more data into the semantic layer. This piece is about the gap: what a context layer has to do that a semantic layer does not, and why anyone putting agents into production should care which one they are actually building.

I should declare my interest. At Snowplow we are building a customer context layer, for agents that work with customers, whether directly in an application or by supporting the marketing and support agents that serve them. Read what follows with that in mind. The argument stands or falls on its own logic.

Context layer: the phrase everyone is using but no one has defined

Start with what is not contested, because it shows how precise this language can be. “Context window” is exact: Anthropic’s documentation calls it the model’s “working memory,” all the text a model can reference when generating a response. “Context engineering” converged fast: Tobi Lütke reached for the term in June 2025, Andrej Karpathy sharpened it a week later into “the delicate art and science of filling the context window with just the right information for the next step,” and LangChain and Anthropic landed in the same place within months.

Then you reach “context layer,” and the ground gives way. Enterprise Knowledge, a consultancy with nothing to sell in this particular fight, is blunt: practitioners “are still struggling to agree on the terms themselves.” Different camps use the phrase to mean materially different things: governed metadata over the warehouse (Atlan, and the reading analysts applied to Snowflake’s Horizon Catalog at Summit), agentic retrieval across both structured and unstructured information (Contextual AI), a knowledge graph (Enterprise Knowledge again), or the live, identity-resolved state of a specific entity, the camp Snowplow and Amperity are in.

But underneath, every camp makes the same move: each assumes the job is to give an agent access to data that already exists, differing only on which data and in what shape. That assumption fails twice. First, access is not the hard part: context has a real cost, so it is not enough to make data reachable; it has to be the right data, optimised for this agent at this moment. Second, it counts only the data the enterprise has already captured, and says nothing about the data that has to be created before any of it can run.

Give the semantic layer its due

To see the difference clearly, give the semantic layer its due, because it is a real and durable idea that long predates this conversation.

It was, in effect, invented by Business Objects. Their patent, filed in November 1991, describes a system that lets “end users access (query) relational databases without knowing the relational structure or the structured query language,” wrapping the metadata model in a container they called a “universe.” The label came later; the thing is thirty-five years old, and its job has never changed: the consistent interpretation of data that already exists. What does “revenue” mean? It is the agreed dictionary that stops every team in the building defining “churn” differently.

The self-service-BI wave ushered in by Tableau largely did away with the semantic layer: analysts pointed a visualisation tool straight at the data and each re-implemented their own definitions. Looker brought it back in 2012 with LookML, so many people could work consistently with the data the cloud warehouses were making available. It is having a full renaissance now, with dbt, Cube, AtScale, Snowflake’s Semantic Views and Databricks’ Metric Views, for a reason that has nothing to do with humans: an agent that guesses what “revenue” means is worse than useless. The clearest tell that the term is live and contested: in September 2025, Snowflake, Salesforce, dbt Labs and others launched a standard, the Open Semantic Interchange, to make their semantic layers interoperate. You do not standardise something everyone already agrees on.

So the semantic layer is enjoying a deserved second life. The mistake is not in valuing it. It is in thinking that makes it a context layer.

The difference is the job, not the data

The tempting way to distinguish the two is by their contents: to say a context layer just has more in it, usually the documents and transcripts that never fitted neatly into tables. But that invites an obvious rebuttal: then put more data in the semantic layer. If the only difference is what is inside, the distinction collapses, because in principle you can put anything inside anything.

The distinction is not the contents. It is the job. A semantic layer answers one question: what does this data mean? It is definitional, retrospective, aggregate, and the same dictionary whoever opens it. A context layer answers a different question: what does this agent need to know to act well, here, now? Put in one line: a semantic layer describes the past consistently; a context layer assembles the present for a decision. Two things separate them. One is tense: the settled past versus the live present. The other is address: a semantic layer is unaddressed, indifferent to who is asking or why; a context layer is written for one reader, this agent, in this situation, trying to do this thing. Tense and address together, and everything else in this piece follows from them.

The word “context” is overloaded, so let me fix the vocabulary. I will use situation for the raw thing an agent is dropped into: the environment, the entities in it, and what each is trying to do. And I will reserve context for the refined, decision-ready package assembled both from that situation and for it: from it, to understand what is going on at all; for it, when handed back to the agent so it can take its best next step. The situation is the raw material; context is what you manufacture from it. A semantic layer is one ingredient in that manufacture. It is not the factory.

So what is the job, exactly?

The job of a context layer is to give an agent the most relevant, precise, succinct yet complete picture of the situation it is in, together with the knowledge it needs to act, so it has the best possible chance of success, however the agent defines success. (”Succinct yet complete” is deliberately a tension: enough to act on and no more, because context is not free.)

The interesting question is how, and it breaks into a five-step pipeline that runs not once but over and over, learning as it goes.

1. Comprehend the situation. Build an accurate picture of the environment: which entities are involved, their current state, what each is trying to do. Get this wrong and everything downstream is precise about the wrong thing.

2. Frame the problem. Translate the situation into the specific problem to solve. One situation affords many; this picks the real one. Get this wrong and you solve the wrong problem flawlessly.

3. Determine what is needed. Map that problem to the information and knowledge required to solve it. Get this wrong and you retrieve a pile of plausibly-related, useless material, or miss the one input that mattered.

4. Acquire it, across every source. Gather it wherever it lives: tables, knowledge graphs, documents, real-time event streams, external systems. This is the only step a semantic layer touches, and even then only the slice whose answers sit in governed warehouse tables.

5. Compose it for use. Arrange the material into the form most usable for this decision by this consumer: the right granularity and precision, disambiguated, no more than is needed. Get this wrong and you hand the agent a technically-complete data dump it cannot use.

The semantic layer contributes to step four, for one source type, and is silent on the rest. That is not a criticism; it is simply a much smaller part of the job than the conflation implies.

This answers the obvious objection: can’t I just put an agent on top of my semantic layer and let it do the rest? You can, and for one case it is the right architecture. Picture an analytics agent, an internal user asking the warehouse questions in natural language: “What was net revenue retention in EMEA last quarter, and which segments dragged it down?” The agent handles steps one to three by reasoning, the semantic layer handles step four, and the answer is good, because the situation is simple, the data already exists in the warehouse, and it is already aggregate. From inside that case, “semantic layer equals context layer” looks obviously true. But notice what that arrangement is. The agent supplies the reasoning, which a capable model can do for itself. What it cannot do for itself is the infrastructure: making sure the right data was created in the first place, acquiring it from sources the semantic layer does not reach, and composing and delivering it in time. Split the job that way and the boundary draws itself. The context layer is the infrastructure half, and it is precisely the half a semantic layer does not provide.

It all rests on data that has to be created

The most important thing the decomposition surfaces hides inside steps one and four: both presuppose that the relevant data exists. Step four quietly assumes the thing you are reaching for was recorded somewhere. Often it was not. Step one is more demanding still: you cannot comprehend a situation that was never captured. Describing a situation accurately is not a passive act of reading; it is an act of creating the data that represents it.

Take two agents facing very different decisions. An incident-response agent has to decide whether to roll back a release the moment a service starts erroring: what settles it is which deploy shipped in the last ten minutes and which downstream services are degrading right now, not last quarter’s uptime. A customer-facing agent, handling a live chat or working inside an application, has to decide what to say or do next: what settles that is what this customer just did, that they hesitated on the pricing page, abandoned checkout, and came back twice in the last five minutes. In both cases the context that matters is made of events happening now, and it exists only if those events were deliberately captured as they happened. Typically, neither situation sits in a table waiting to be queried.

So the job of a context layer is not, fundamentally, to support a retrieval process. It is to ensure the data needed to run all five steps has been designed, created and made available in the first place. A semantic layer assumes that work is done. For a real-time agent it usually is not, and no amount of consistent definition conjures data that was never recorded. (This is the thread back to where this series started: a context layer is where created context gets served; data creation is how that context comes to exist.)

This is general, and worth proving general by stepping outside the customer-data world I happen to live in. Take a coding agent. It needs the current state of the codebase, the diff in flight, the failing test, the ticket, the team’s conventions, and, above all, why a piece of code was written the way it was. That last one is a decision trace, and decision traces are almost never recorded: they live in someone’s head, or a Slack thread that scrolled away. A semantic layer over a metrics warehouse is irrelevant here; this agent’s context is a code graph, live editor state, and institutional knowledge that has to be captured to exist at all. Or take a clinical decision-support agent at the bedside: live vitals streaming now, a history resolved across record systems that share no identifier, medical knowledge that is graph-shaped and constantly revised. A consistent definition of “readmission rate” is no use mid-ward-round.

Three different domains, one structural fact in each: much of what the agent needs is graph-shaped rather than tabular, real-time rather than batch, and often not recorded until something deliberately records it. None of those three properties is what a semantic layer is built for.

And it has to arrive in time

The decomposition makes a second thing visible, the one the warehouse path most often founders on: composing the perfect context and delivering it a moment too late is a total failure, and a different failure from getting the content wrong. Semantic layers are typically built on the gold tables at the end of a batch pipeline. That is the right place for consistent reporting and the wrong place for a decision happening in a live conversation. The agent is mid-sentence with a customer, or mid-edit in a file. Context that is correct but arrives with last night’s batch is not context; it is history. This is the tense difference made physical: the past, however consistently described, arrives too late for the present.

The loop that makes it better

One more thing, and the part I am least willing to draw a clean box around. A good context layer gets better over time: it records what the agent did and what happened, and feeds that back in, which is itself an act of creating new data, the decision traces step three will want next time. That loop is shared, and cannot be optimised from one end. The agent owns the action and its outcome; the context layer owns turning that outcome into durable, retrievable signal. Optimise one without the other and it breaks: an agent that learns nothing it can pass on, or a layer of traces no agent ever acts on.

Why the distinction is worth defending

The failure mode is by now easy to picture: a flawless semantic layer, every definition agreed, that can still only tell a real-time agent what the terms mean and what this segment did last quarter, when what it needs is what is happening right now. That gap is the space a context layer occupies, and it is why the definition currently forming, context layer as semantic-layer-plus-agent, is worth resisting: it is a definition the data platforms already meet by construction. If that version wins, the category was settled the moment it was named.

I want to be fair to the most serious version of the opposing view, because serious people hold it. Snowflake’s own engineering team has written one of the sharpest accounts of what agents need from data. Their “Agent Context Layer” post lays out six stacked layers and makes a good prediction, that “winning architectures will treat agent context, and not the model, as the core product, as the model gets commoditised.” I agree with that sentence, and a warehouse can assemble a great deal of context. The disagreement is narrower and more structural: the real-time, entity-resolved, behavioural creation at the front of the five steps is the part the warehouse-native version cannot do, not through any failure of engineering, but because that data was never in the warehouse to begin with. A semantic layer is a tool for interpreting data, not for bringing it into existence.

So: a context layer is defined by a job a semantic layer does only a sliver of, and that job rests on data that has to be created, resolved to a live entity, served in time, and improved through use. Get that general definition right and any more specific claim, a “customer context layer,” say, follows from it rather than having to be asserted.

A closing note on how to do this honestly. The temptation in pieces like this is to invent a term and plant a flag on it, and coining a word when adequate ones already exist is the surest sign someone is trying to own a category rather than describe one. So I am not going to coin anything. I would rather build inside the vocabulary that already exists, Brinker’s “systems of context”, Karpathy’s “filling the window,” define the job as precisely as I can, and let you judge whether what anyone builds actually meets it. That includes us: if “customer context layer” earns the name, it will be because it does the job, not because we said it first. A clear definition is the one thing the people best placed to own a term have the least incentive to supply. I would rather supply it, and compete on whether we meet it.