Semantic Layer Is the New Data Stack for Agents — Oracle, Google, and the Benchmarks All Agree
Oracle wants agents to pick trusted reports, not write SQL. Google folds Measures + Graph into BigQuery. A SIGMOD 2026 semantic-layer-mediated NL2SQL agent pushes Spider 2.0 accuracy from 17% to 94.15%. Three very different players landed on the same idea in the same week.
Three players made the same bet in one week
Over the past week, "semantic layer" became the loudest phrase in enterprise data.
Oracle published a blog asking the data world to let agents choose fixed trusted reports, not write SQL themselves. The recipe is simple: wrap analyst-approved queries as callable tools; the agent picks one and fills typed parameters. Even if a prompt-injection bypass opens 40+ MCP vulnerabilities, the data an agent can reach is still bounded by the tool surface.
On August 13, Google Cloud released Using BigQuery Graphs with measures for trusted agentic workloads, putting Graph and Measures inside the same governed model. In the Seattle winter‑jacket example, SQL plus Measures can tell you revenue "dropped 12%"; only Graph can trace "why" — which distribution center, which supplier, which storm delayed the supply. Agents need both a calculator and a map to give responsible answers.
The research side followed. A paper accepted at SIGMOD 2026, A Semantic‑Layer‑Mediated Agent for Natural Language to SQL, plugged Gemini 3 Pro into a curated semantic layer, expressed intent as a Semantic Model Query (SMQ), and reached 94.15% execution accuracy on the 547‑task Spider 2.0‑snow benchmark — third on the official leaderboard. The same benchmark still breaks o1‑preview at 17.0%. That is roughly a 1x to 5x gap.
Oracle, Google, academia — three very different players landed on the same idea in one week. This is not coincidence; it is engineering consensus: "raw schema → LLM emits SQL" is no longer a viable architecture for enterprise agents.
Why "model writes SQL directly" stopped scaling
Putting the past three years of production pain together, three ceilings explain why semantic layers are suddenly necessary.
Ceiling 1 — business vocabulary is not a column. When a user asks for "high-value customers' churn risk", no column is named exactly that. To compute it you need a business-side definition ("recent 12‑month spend × profit contribution × contract status"), and the model cannot guess which version your company uses.
Ceiling 2 — one metric, many definitions. Revenue means recognized cash to Finance, order amount to Sales, GMV minus refunds to CX. Telling the model "use the Finance definition" in a prompt works once and fails the next time someone changes context.
Ceiling 3 — JOIN paths are guesswork. Customer, order, contract, and product tables often lack clean foreign keys; some need mapping tables or time‑bounded joins. Letting the model guess the path reliably produces duplicate counts or silently dropped rows.
Spider 2.0 amplifies all three: 1000+ fields, multiple dialects, and 5+ real‑world tables per query. o1‑preview completes only 17.0% of those tasks, which is exactly the gap between "smart model" and "useful model".
Once a semantic layer sits between the model and the warehouse, the model's job shrinks from "write all of SQL" to "express intent": which business object, which metric, what time window, what filters. Everything downstream — metric expansion, table selection, JOIN paths, permission injection — moves to the semantic layer and its compiler. The Spider 2.0 jump from 17% to 94.15% is not "Gemini is 5× smarter than o1". It is what happens when you take work that should never have belonged to the model and give it back to a deterministic layer.
Three-layer semantic layer + business compiler in practice
To make agents trustworthy, the leading stacks are extending the semantic layer to three layers — Measures + Entities + Relationships, each maintained and governed independently, with a deterministic compiler that emits dialect-specific SQL.
- Google BigQuery Graph with Measures (Preview) — defines MEASURE (SUM/AVG/COUNT DISTINCT/...) directly on Property Graph node or edge attributes, bound to a KEY so graph traversal can't double-count. Promoted as zero ETL — no separate graph database required.
- Oracle Trusted Reports — queries are frozen as reports, agents can only pick a report and fill parameters. Logic is not free to be rewritten by the model, which closes the SQL fabrication attack vector at the source.
- Ant Group Agentar-SQL — Agentar-Scale-SQL ranks at the top of the BIRD-SQL leaderboard; a top-tier city commercial bank reported query accuracy above 92% in pilot — over 3× the previous approach.
- Alibaba Lingyang "Super Data Analyst" — orchestrates Query / Interpret / Report agents on top of a shared metric semantic layer; e-commerce analysts cut a 2-hour data fetch to 10 seconds.
- Snowflake Cortex Analyst + Semantic Views — compiles dbt Semantic Layer and MetricFlow definitions straight into the BI agent's prompt.
| Approach | Semantic-layer shape | Model role | Primary wins |
|---|---|---|---|
| Classic NL2SQL | None | Generate SQL end-to-end | Model capability |
| Oracle Trusted Reports | Frozen report tools | Pick tool + fill inputs | Repeatability / safety |
| BigQuery Graph + Measures | Nodes + edges + Measures | Express intent | Governance |
| Semantic-Layer-mediated NL2SQL | Objects + metrics + relations | Translate to SMQ | Accuracy + audit |
| OntiCards Data Cards | Entities + fields + relations + terminology + quality | Called by query agents | Delivery + closed loop |
Every path above takes work that should never belong to the model and hands it back to a deterministic layer. The differences are mostly packaging: a BI report, a Graph, a dbt metric, or a business object. The skeleton is the same — the model expresses intent, the semantic layer compiles and governs.
How OntiCards works the semantic layer both ways
Looking at OntiCards' four-layer architecture, the second layer — Data Cards — is essentially an engineering realisation of an agent-oriented semantic layer. We did not build it as a Graph, nor as a dbt project; we built it as a business-readable entity that business owners can read and govern directly.
A Data Card bundles four things:
- Entity (a business object) — Order, Product, Customer, Distribution Center, mapped 1:1 to the things your business cares about.
- Field (a business field, not a physical column) — "high-value customer", "new customer this month", "signed but not yet shipped" — the concepts people actually use.
- Relationship — business associations between entities (who orders from whom, who supplies which DC).
- Quality gate — which fields must be non-null, which values must fall in a known set, which associations must hold.
Compared with BigQuery's Graph, OntiCards cards sit closer to the business: a domain owner can define "high-value customer" without writing Property Graph DDL. Compared with a dbt metric layer, OntiCards adds a terminology layer — the same thing may be called "sales", "revenue", or "GMV" in different teams, and the terminology service maps all of them to one canonical business object.
Compared with Oracle Trusted Reports, OntiCards is lighter weight: agents do not need to pick from a fixed report pool every time. They can ask about new metrics, as long as those metrics have already passed through a data card and its quality gate. When a new metric enters a card, the quality gate runs automatically; anything that fails is invisible to agents.
That is why OntiCards sits squarely on this trend. This wave is not a vendor's invention — the whole industry is converging on the same shape. OntiCards split data and agents into four layers (Ingest / Cards / Query / Consume) from day one; it just took the rest of the industry a while to agree that this separation is necessary.
How to tell whether a semantic layer is "ready"
If you are about to wire a semantic layer into your own agent stack (buy or build), a four-step smoke test catches most under-built systems:
- Business-readable — domain owners can read and edit definitions. If they cannot, the layer will silently rot into another "schema maintained by data engineering".
- Metrics carry definitions — every business metric must answer what window, what status, what is excluded. Anything else is a half-defined metric.
- Relationships are explicit — cross-table joins should not be assembled on the fly via prompts. The semantic layer must own the relationship graph.
- Governance is closed-loop — metric errors, definition drift, and field gaps should be blocked at the layer, not caught later by an analyst reviewing numbers.
If your semantic layer passes all four, but agent accuracy is still flat, the bottleneck is more likely the data ingest layer — see our data QA & reconciliation walkthrough. The semantic layer is not a silver bullet, but it solves the hardest half of the problem on the path from demo to scale.
References
To see how the semantic layer and ontology differ in our plans, read the OntiCards H2 roadmap. Want to try card-driven querying for yourself? Contact us at hello@onticards.com to request a trial account. Pricing and the finance solution are also ready to walk through.
