What is a semantic layer for AI agents?
Summary
- A semantic layer "sits between source data and the end users or systems that consume it". For an AI agent it supplies governed business definitions to read and query, so the agent does not have to infer them from raw tables.
- Databricks documents two ways agents use it: grounding (reading the semantic layer's descriptive context before querying) and execution (querying governed metric definitions instead of base tables).
- On Databricks, metric views are the core implementation of Unity Catalog semantics. Genie Ontology, in Public Preview, adds context that Genie infers from your assets and usage.
- Metric views can be queried with
MEASURE()from SQL editors, JDBC and ODBC connections, dashboards and Genie Agents. The Genie One MCP server lets other MCP clients and agents ask Genie questions.
What is a semantic layer for AI agents?
A Databricks blog on semantic layer architecture defines it this way: "A semantic layer sits between source data and the end users or systems that consume it." For an AI agent, the agent is the consumer. The layer holds the business vocabulary the agent would otherwise have to guess: dimensions, measures, joins, filters and governance metadata.
Why do AI agents need a semantic layer?
The blog says large language models "have no inherent understanding of your business vocabulary". It describes the problem: "An LLM querying your data warehouse has to infer what 'ARR' means, which table contains it, what filters apply, and whether the result should be for active contracts only or all-time."
It contrasts two designs. "Pure text-to-SQL systems generate queries against raw tables, meaning the LLM must infer business logic, filter conditions, and join paths from table names and column descriptions alone." Then: "A semantic layer approach inverts this: the LLM generates queries against governed metric definitions, not raw tables."
How do agents use a semantic layer?
The blog describes two uses. The first is grounding: "before generating any query or responding to a question, the agent reads the semantic layer's descriptive context to understand available metrics, dimensions, their definitions, and the governance rules that apply". The second is execution: "rather than generating raw queries against base tables, the agent queries the semantic layer's interface using governed metric definitions."
What does a semantic layer contain?
| Component | What the blog says |
|---|---|
| Dimensions | "the axes of analysis" |
| Measures | "quantify business outcomes as computed functions" |
| Joins and relationships | The join layer enriches "a primary fact table" with "related data, such as customer geography, product hierarchies, and contract types" |
| Filters | "Filters encode business rules directly into the metric definition." |
| Metadata and governance | "Data lineage tracks which source tables feed each metric and which downstream consumers depend on it." |
How does Databricks implement it?
The Unity Catalog docs say "Metric views are the core implementation of Unity Catalog semantics in Unity Catalog". You define a metric once and "users can group by any available field". Databricks announced general availability of Unity Catalog Business Semantics, with metric views at its core, on April 2, 2026.
CREATE OR REPLACE VIEW orders_metric_view WITH METRICS LANGUAGE YAML AS
$$
version: 1.1
comment: "Orders KPIs for sales analysis"
source: samples.tpch.orders
fields:
- name: Order Month
expr: DATE_TRUNC('MONTH', source.o_orderdate)
comment: "Month of order"
measures:
- name: Total Revenue
expr: SUM(source.o_totalprice)
comment: "Sum of all order prices"
$$
SELECT `Order Month`, MEASURE(`Total Revenue`)
FROM orders_metric_view
GROUP BY ALL
ORDER BY `Order Month`;
"All measure evaluations in a metric view query must use the MEASURE aggregate function." The docs also describe agent metadata: "Add synonyms, display names, and formatting rules to improve agent accuracy and display consistent formats across tools."
Genie Ontology is "the unified context layer that gives the Genie family of AI experiences a business-aware map of your organization." It combines Unity Catalog semantics that you define, govern and certify with inferred context that Genie extracts from metric views, dashboards, SQL queries and Genie Agents. Genie One and Genie Code search the same ontology.
| Piece | Role | Stage |
|---|---|---|
| Metric views | Define governed measures and fields once | Generally available with Unity Catalog Business Semantics |
| Pages | Governed definitions of business concepts | Beta |
| Genie Ontology | Unified context layer, modeled plus inferred | Public Preview |
| Genie One MCP server | Lets MCP clients and agents ask Genie questions | Generally available |
FAQs
Is a semantic layer the same as Genie Ontology?
No. Unity Catalog semantics is "the human-modeled layer of the Genie Ontology: the business context that you define and govern explicitly". The ontology adds context Genie infers automatically.
Which tools can query a metric view?
The docs list SQL editors on a SQL warehouse, notebooks, AI/BI dashboards, Genie Agents, alerts, JDBC and ODBC connections, and external BI tools using custom SQL.
Can agents built outside Databricks use it?
The docs list JDBC and ODBC connections among the ways to query a metric view, so an external tool that runs SQL can read the same governed definitions with MEASURE(). The Genie One MCP server, which the docs label generally available, is described as a way to "Connect any MCP client or agent to ground its data questions in Genie's trusted insights". The docs say Genie resolves business terms, metric definitions and table relationships through Genie Ontology.
Are metric views open source?
Databricks said it is "open sourcing the core Metric View implementation in Apache Spark OSS". The Apache Spark 4.2.0 release notes list metric views, "declarative semantic modeling with a CREATE VIEW ... WITH METRICS surface" (SPARK-54119).
The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.