The semantic layer stopped being a background discipline

The semantic layer stopped being a background discipline

There is a particular kind of failure that shows up once an organisation moves an AI project from a demo to production. The model is fine. The retrieval is fine. The answers are wrong anyway, and they are wrong in a way nobody can quite argue with, because the system did retrieve real rows from a real table and did summarise them accurately. It just did not know that "revenue" in that table excludes refunds, or that the finance team's definition of an active customer is not the one the growth team uses.

That gap has a name, and in 2026 it acquired a budget line.

The problem is context, not capability

Baris Guletkin, Snowflake's VP of AI, describes the pattern directly: "As companies begin moving more AI projects into production, they quickly realize that their AI initiatives struggle not because of a lack of intelligence, but because they lack business context." His summary of what follows is the sentence worth pinning above a project plan: "Agents need shared meaning and context, not just shared data."

David Menninger of ISG Software Research puts the same point as an analogy: "As the use of AI has expanded, and the importance of data to those AI efforts has become more apparent, it's also become apparent that accessing data without a semantic model is like trying to drive to your destination without a roadmap."

Both are describing the semantic layer — the place where a business defines what its metrics actually mean, once, so that every tool downstream computes them the same way. It is not a new idea. Every BI vendor has shipped some version of it for twenty years, and it has spent most of that time as a configuration detail that a analytics engineer maintained and nobody else thought about.

What changed is who consumes it. A dashboard with a wrong metric definition produces a number a human squints at and questions. An agent with a wrong metric definition takes an action.

Why 2026 and not 2024

The timing is not arbitrary. Michael Ni of Constellation Research frames the year's shift in one line: "2025 was about building agents. 2026 is about trusting them."

Trust, operationally, means something narrower than it sounds. It means the system's answer can be checked, its definition of every term can be traced, and the same question asked twice returns the same number. None of that is a property of the model. All of it is a property of the layer between the model and the warehouse.

The scale of the unfinished work is visible in the survey data. Gartner reports 57% of organisations saying their data is not AI-ready — a majority, at a point where AI budgets have already been committed. Gartner also expects the shape of data work to change underneath this: a forecast that by 2027, 60% of data management tasks will be automated, and that 75% of new data flows will come from non-technical users.

Read those two forecasts together and the semantic layer stops being optional. If three quarters of new data flows are created by people who do not write SQL, then the definitions cannot live in the SQL. They have to live somewhere the business states them and every tool reads them.

There is money moving on the same thesis. Gartner reports 71% of organisations planning to invest in data management technologies embedding generative AI within the next two to three years, and IDC puts global data and analytics spending approaching $420 billion by 2026.

The protocol argument is the same argument

Alongside the semantic layer, 2026's other unresolved question is which protocol agents use to talk to tools and to each other. It looks like a separate debate. It is the same one: both are about establishing shared meaning so that independently built components can cooperate.

Donald Farmer of TreeHive Strategy is sceptical about how much of the current proliferation survives contact with reality: "A2A has a tougher road ahead. The protocol is only needed when organizations actually run agent swarms that need to work together." Chris Aberger of Alation predicts absorption rather than coexistence: "MCP won't coexist with A2A. It will absorb the useful parts because the ecosystem will demand one standard."

The buyer-relevant version of this is not which acronym wins. It is that committing to a vendor's private convention — for tool calls, or for metric definitions — is the expensive choice in a year when the ecosystem is visibly converging on shared ones.

What it looks like when it ships

Two launches on TrustList's board this week are recognisable instances of the same thesis, which is a useful reality check on whether analyst framing is describing anything real.

Routines by Databox, which launched on 7 September, is scheduled analysis: a user gives an analyst-agent a prompt and a cadence, and it analyses live data on that schedule and delivers the result by email, Slack or in-app. The product is small. The idea underneath it is not. The recurring business question — how did acquisition do last week, and what changed — is precisely the question a human analyst re-answers every week, and scheduling is what converts a chat interface into something operational. It only works if the metric it computes on Monday means the same thing it meant last Monday. That is a semantic-layer dependency whether or not the product calls it one.

Kit by Speakeasy, which launched on 6 September, is a coding-agent runtime shipped as a single static binary containing a terminal client, an Agent Client Protocol server, an A2A endpoint and a subagent orchestrator. Its architectural claim is that the protocol is the boundary: because it speaks ACP, it works with compatible editors and can orchestrate other harnesses without bespoke integrations. That is a direct bet on the standardisation Aberger describes, made by a vendor rather than an analyst.

Neither product is proof of anything on its own. Together they are a reasonable sign that "shared meaning" has moved from a conference-slide phrase to something being shipped against.

What to do about it before buying anything

The uncomfortable implication of all of this is that the semantic layer is not a product you can buy your way out of the problem with. It is a description of your own business that somebody in your organisation has to write down.

Three things are worth doing first, and none of them require a vendor decision.

Write down the ten metrics your organisation argues about. Not all of them — the ones where two teams have produced different numbers in the last year. That list is the actual scope of the problem.

Find where each one is currently defined. In most organisations the answer is several places at once: a dbt model, a BI tool's calculated field, a spreadsheet, and someone's head. Every one of those is a definition an agent could pick up.

Decide what happens when they disagree. This is a governance question, not a technical one, and it is the part that consolidation and tooling cannot answer for you.

The reason to do this before a purchase rather than after is that the list you produce is also the best evaluation script anyone has written for this category. Take the three metrics your teams argue about most and ask each vendor to model them in a trial. Not a demo dataset — yours, with the awkward edge cases that caused the arguments. A tool that can express your actual definitions cleanly is worth more than one that scores better on a feature matrix, and a tool that cannot will not become able to after the contract is signed.

It also tells you something about how portable the result is. Ask, during that trial, to export the definitions you just built. What comes back — a readable specification, or a binary the vendor's own software reads — answers the exit question from the previous section far more honestly than a sales call will.

Only then does the tooling question become answerable — and by then it is a much smaller question than the vendors selling into this moment would like it to be.

Why this failed the last three times

Semantic layers are not a 2026 invention, and it is worth being honest about that, because the reasons earlier attempts stalled have not all gone away.

The pattern has repeated roughly every BI generation. A vendor ships a modelling layer. A team invests in defining metrics inside it. The organisation then adopts a second tool that cannot read those definitions, so the definitions get re-implemented there. Within two years there are three sources of truth and the layer that was supposed to end the argument has become another participant in it.

Two things are different this time, and one thing is not.

Different: the consumer has changed. Every previous semantic layer was built for humans reading dashboards, and a human reading a dashboard applies judgement to an implausible number. The consumer now is a system that acts. That raises the cost of a wrong definition from an awkward meeting to an incorrect action taken at machine speed and volume.

Also different: the interface is converging on protocols rather than on a vendor's SDK. If tools agree on how to ask what a metric means, a definition written once has a route into systems the author never anticipated. That is exactly the argument Chris Aberger of Alation is making when he predicts that "MCP won't coexist with A2A. It will absorb the useful parts because the ecosystem will demand one standard" — standardisation is what makes a definition portable, and portability is what previous attempts lacked.

Not different: somebody still has to write the definitions, and that work is unglamorous, politically awkward and impossible to buy. Gartner's finding that 57% of organisations say their data is not AI-ready is, read one way, a finding that the majority have not done it. No amount of investment in tooling — including the 71% who plan to buy generative-AI-embedded data management within two to three years — substitutes for an organisation deciding what its own words mean.

What "agent-ready" is actually asking for

The phrase doing the rounds in 2026 is agent-ready data, and it is worth unpacking because it sounds like a product tier and is really a checklist.

An agent that is going to act on enterprise data needs four things that a dashboard does not.

A definition it can retrieve, not infer. If the agent has to work out what active customer means by looking at column names, it will guess, and it will guess consistently enough that nobody notices for a quarter.

Freshness it can reason about. A human looking at a dashboard knows the number is from last night. An agent needs the staleness to be a value it can read, because "as of when" changes whether an action is correct.

Permissions that travel with the question. The agent is acting on behalf of someone. Row-level access has to resolve to that person, not to the service account the integration was set up with — the single most common way an enthusiastic internal AI deployment turns into an access-review finding.

A record of what it did. Not logs of the model's tokens, but of the business action: which definition was used, which rows were read, what was sent where.

None of those four are model capabilities. All four are properties of the layer between the model and the warehouse — which is why the money and the acquisitions have moved there, and why IDC's estimate of global data and analytics spending approaching $420 billion by 2026 is being spent on plumbing rather than on intelligence.

Sources

• TechTarget — 4 trends that will shape data management and AI in 2026 (quotes from Baris Guletkin, David Menninger, Michael Ni, Donald Farmer and Chris Aberger)
• N-iX — Data management trends in 2026 (Gartner: 57% not AI-ready; 60% of data management tasks automated and 75% of new data flows from non-technical users by 2027; 71% planning generative-AI data management investment; IDC spending figure)
• Routines by Databox on Product Hunt and Kit by Speakeasy on Product Hunt (the two launches described, verified on their own pages)