Text-to-SQL agents need a semantic layer, not just a bigger model

What the research shows

Spider 2.0, presented at ICLR 2025, was built from real enterprise workflows: 632 problems over databases often with more than a thousand columns, in systems such as BigQuery and Snowflake. The authors reported that a strong reasoning model using a code agent framework solved 21.3% of tasks, compared with 91.2% on the earlier Spider 1.0 benchmark and 73.0% on BIRD¹².

The gap isn't mainly about SQL syntax. It is about knowing which tables matter, what columns mean, how entities join, and which business rules apply. That knowledge rarely lives in the schema.

What a semantic layer gives an agent

A semantic layer defines business concepts, such as metrics, dimensions, entities and their relationships, once, in governed code, and exposes them to every tool. For an AI agent, that changes the task from "write SQL against 1,500 columns" to "pick the governed metric 'net revenue', group by the dimension 'sales region', filter to last fiscal quarter". The layer generates the SQL.

• Consistency. The agent's answer matches the dashboard, because both use the same definition.
• Smaller search space. Choosing from a curated set of metrics is far easier than reasoning over raw tables.
• Governance. Access control, row-level security and certified definitions apply to AI queries just as they do to BI.
• Explainability. The agent can say which metric and filters it used, in business terms a user can check.

The market is converging

In September 2025 Snowflake, Salesforce, dbt Labs and others announced the Open Semantic Interchange, an initiative for a vendor-neutral semantic model specification, explicitly framed around making data ready for AI³. In October 2025 dbt Labs moved MetricFlow, the engine behind its semantic layer, to the Apache 2.0 licence and said it would align it with that initiative⁴⁵.

Whatever tools you choose, the direction is clear: business definitions are becoming portable, open artefacts that AI and BI share, rather than logic buried in each dashboard.

Semantic layer, ontology or both?

A semantic layer is optimised for metrics: numbers aggregated over dimensions. An ontology describes entities and relationships more broadly, as I set out in ontology vs knowledge graph vs semantic layer. For "how much" questions, the semantic layer is the right tool. For "which suppliers are connected to this incident", a knowledge graph answers better. Mature data platforms give agents both, with clear guidance on which to use.

How I design data access for AI agents

1. Start with the twenty questions people actually ask, and define the metrics and dimensions they need in the semantic layer first.
2. Expose governed tools, not a SQL console. Agents call "query metric" and "list dimensions" tools, for example through MCP servers built with the controls in securing MCP servers.
3. Return the definition with the answer, so users see which metric, filters and time range were used.
4. Fall back honestly. If a question can't be answered from governed definitions, say so and route it to an analyst, rather than improvising SQL.
5. Evaluate with real questions and known answers, as in evaluation sets that predict production, and track accuracy by question type.
6. Keep definitions under contract, with the change discipline in data contracts, so a schema change can't silently break what agents report.

How I can help

I design data platforms where AI agents and BI share governed definitions, from semantic layers and ontologies to the tools agents call. See ontology and knowledge graphs, or analyse your challenge and bring the result to a call.