The Semantic Layer Is the Missing Piece in Enterprise AI

A board deck goes out on a Tuesday with a revenue figure in it. The figure came from an analytics agent asked “what was revenue last quarter,” which wrote some SQL, joined orders to line items, and summed a column. Nobody notices for six weeks. The number counted cancelled orders, double-counted anything that shipped in two parcels, and used order date rather than recognition date. The SQL ran clean. The result was plausible. It was wrong by enough to matter and small enough to survive.

This is the characteristic failure of enterprise AI on top of a warehouse, and it is not a model problem. Frontier models write competent SQL. What they cannot know is that in your company “revenue” excludes intercompany transfers, that “active student” means one thing to finance and another to the attendance office, or that the encounters table has one row per clinical contact while the visits table has one row per arrival. That knowledge is not in the schema. It lives in analysts’ heads and in the WHERE clauses of a hundred inconsistent dashboards.

The semantic layer is where that knowledge is supposed to live. It is the largest gap between an AI demo that impresses and an AI system a CFO will sign off on.

The industry just said the quiet part out loud#

On July 23, 2026, Microsoft and Databricks expanded their partnership under an unusually specific banner: helping enterprises bring business context to enterprise AI. Not more parameters, not cheaper inference — context. Databricks CEO Ali Ghodsi framed it as grounding AI in business knowledge; Microsoft’s Judson Althoff framed the next generation of AI as defined by how well organizations turn their own knowledge into intelligence. The commercial substance runs into the 2030s and covers Azure infrastructure, Cobalt silicon, and pushing Databricks capabilities like Genie into Microsoft surfaces.

Strip the press release and the technical claim underneath is narrow and correct: an agent is only as good as the definitions it is handed. That is a semantic layer argument. Databricks shipped Unity Catalog metric views to general availability earlier in 2026 for exactly this reason, and Genie reads them as governed context rather than guessing at raw tables.

What a semantic layer actually is#

A semantic layer is a versioned, machine-readable contract that answers five questions about your data, and it is not a BI tool’s dropdown menu.

• Entities. The nouns — patient, encounter, student, enrolment, order — each with a primary key and declared relationships.
• Metrics. The numbers, defined once. Not “sum this column” but the full expression: filters, exclusions, and aggregation type (sum, count distinct, ratio, cumulative).
• Joins. Valid paths between entities, declared ahead of time, with cardinality. This is what stops fan-out: joining a header table to a child table and summing a header-level amount once per child row.
• Grain. The row-level meaning of every table. One row per what? Get this wrong and every aggregate above it is wrong.
• Time semantics. Which date column is the metric’s time axis, what a fiscal period is, how period-over-period and cumulative windows are computed, and what happens to backdated records.

The distinction that matters: this is a layer, not a feature of one tool. A metric defined inside a single dashboard product is a hack — invisible to the notebook, the reverse-ETL job, the alerting rule, and the agent. The moment a second consumer needs the same number, the definition forks, and once it forks it drifts. A real semantic layer sits below every consumer and compiles the query itself.

Grain traps, with two concrete domains#

Abstract governance talk convinces nobody, so here are the traps that actually bite.

In a Hospital Management System, an encounter is not a visit is not an admission. An encounter is one clinical contact — a consult, an imaging study, a nurse assessment. A visit is one arrival at a facility, which may contain many encounters. An admission is an inpatient stay with a bed, spanning days and many encounters across departments. Ask an agent “how many patients did we see last month” and it will pick whichever table looks most like the question. Count encounters and you inflate the number several times over. Count admissions and you erase all outpatient activity. Readmission is worse: it is a derived metric with a window, an index-event definition, and a set of exclusions — planned readmissions, transfers, deaths, patients who left against medical advice. No LLM reconstructs that from column names. It will produce a readmission rate anyway.

In a School ERP, the trap is the word “active.” Enrolled means a registration record exists for the term. Active usually means enrolled and not withdrawn as of a date, which requires a slowly changing dimension and a point-in-time filter, not a status flag read as of today. Attending means present in at least one class in a window. Each is the correct answer to a different question, and they do not agree. Report the wrong one to a regulator or a funder and the consequence is not an embarrassing dashboard.

The pattern in both: the failure is silent. The query succeeds. The number is in range. Nobody has a reason to check it.

The tooling, and where each one costs you#

The category has consolidated into two shapes with real tradeoffs.

Definition-first, warehouse-agnostic. The dbt Semantic Layer with MetricFlow, and Cube, both define entities, measures, dimensions, and joins in YAML that lives in a git repository. dbt’s advantage is proximity: the metric definition sits next to the transformation that produced the table, reviewed in the same pull request. Cube’s is that it is a standalone service with a REST and SQL API and a caching layer, so it fronts multiple warehouses and serves embedded analytics at latency BI tools cannot. The cost of both is another deployed component with its own query engine, and compute governance that now spans two systems.

Warehouse-native. Databricks Unity Catalog metric views and Snowflake semantic views put the definitions inside the platform that already holds the data and the permissions. Governance is unified — row-level and column-level policies apply to metric queries without a second enforcement point — and there is no extra service to run. The cost is portability: a metric expressed in a vendor’s object model does not move, and if you are genuinely multi-warehouse you maintain it twice.

Our call for most organizations: define metrics in version control, in the same repository as the transformations, and let the warehouse-native object be a compiled artifact rather than the source of truth. Definitions are code. They need diffs, review, blame, and a rollback path. A metric changed through a web UI at 4pm on a Friday with no reviewer is how a company discovers in January that Q3 and Q4 were computed differently.

This is also the argument against the legacy ERP posture. Those vendors keep business logic locked inside proprietary report writers and stored procedures nobody outside the vendor can read, which is precisely why extracting a trustworthy metric takes a services engagement. Treating an ERP as a data platform with thoughtful UI on top — logic in the open, definitions in git, the database a first-class interface — is what makes the AI layer above it tractable at all.

Give the agent a tool surface, not a SQL console#

Here is the architectural move that changes the risk profile. Do not give an analytic agent a database connection and a schema dump. Give it the semantic layer as a set of tools — typically over MCP — where the operations are list available metrics, list dimensions for this metric, and query these measures by these dimensions over this time range.

The agent’s job collapses from “author correct SQL against forty tables” to “map a question onto a governed vocabulary.” The join path, the grain handling, the fiscal calendar, and the row-level security are compiled by the semantic layer, deterministically, the same way every time. Two people asking the same question in different words get the same number, because the SQL was not written twice.

The safety property that matters most is the one people notice least: a semantic layer can refuse. dbt’s 2026 benchmark — a small question suite against an insurance dataset originally built by Juan Sequeda’s team at data.world, run repeatedly across Claude Sonnet 4.6 and GPT-5.3 Codex — found that on questions requiring more entity hops than the layer could express, raw text-to-SQL still answered, plausibly and wrongly, while the semantic layer returned nothing. Both approaches scored well in-scope once the underlying data was modelled properly, and the semantic layer scored higher. But the interesting result is the failure mode, not the headline accuracy: one architecture fails loudly, the other fails invisibly. In production, a system that says “I cannot answer that” beats one that is right most of the time.

Prove it with an eval set, or you are guessing#

A semantic layer is a claim about correctness, and claims need tests. Build an eval set the same way you would for any AI implementation: fifty to two hundred natural language questions paired with answers a human analyst has verified, drawn from the questions people actually ask. Include the ambiguous ones deliberately — “how many students do we have,” “what was our readmission rate” — and assert the right refusal or clarification, not just the right number.

Run it in CI on every change to a metric definition, every model upgrade, every prompt revision. Track three buckets separately: answered correctly, answered incorrectly, declined. Optimizing the first while ignoring the second is how teams ship confident wrongness. The declined bucket is a feature backlog, not a failure.

Wrap operational automation around the definitions themselves — freshness checks, uniqueness tests on the declared grain, referential integrity on every declared join path. If a join you promised was one-to-many turns out to be many-to-many after a bad upstream load, that should break the pipeline, not quietly inflate a metric.

The order of operations#

Most teams attempting analytic agents are doing it backwards: model first, prompt engineering second, semantics never. Invert it. Pick the twenty metrics the business actually runs on. Write them down in code with their grain, their time axis, and their exclusions, and get two people to sign off on each. Expose them as tools. Build the eval set. Then, and only then, put a language model in front of it.

The model is the easy part and it improves on its own. The definitions do not. They are your organization’s accumulated agreement about what its own numbers mean, and until that agreement is written down somewhere a machine can read, every AI answer you ship is an unaudited guess wearing the clothes of an analysis.

---

If an agent can query your warehouse but nobody can defend the number it returns, the problem is upstream of the model. Tell us what you’re building at /#contact.