What Is an Agentic Semantic Layer?

The core shift: an agentic semantic layer treats programmatic access as the primary use case, not an afterthought. MCP support, multi-tenant keys, and row-level security aren't add-ons. They're the foundation.

Core capabilities

An agentic semantic layer needs five capabilities to work in production. Missing any one of them and you'll end up rebuilding it later.

1. Machine-readable metric definitions

Metrics defined in YAML or a similar declarative format that both humans and machines can read. Not trapped in a GUI. Not embedded in a proprietary tool.

cubes:

  - name: orders

    sql_table: public.orders

    measures:

      - name: total_revenue

        sql: "CASE WHEN status != 'refunded' AND type != 'trial' THEN amount ELSE 0 END"

        type: sum

        description: "Total revenue excluding refunds and trials"

      - name: order_count

        type: count

    dimensions:

      - name: status

        sql: status

        type: string

      - name: category

        sql: category

        type: string

      - name: created_at

        sql: created_at

        type: time

total_revenue is now a governed definition with a description the agent can read. Deploy this schema and any MCP-compatible agent (Claude, Cursor, or any client supporting the protocol) can discover and query these metrics at runtime.

The description field matters more than it looks. When an agent calls explore_schema, descriptions are what it uses to decide which metric answers the user's question. Good descriptions are the difference between an agent that picks the right metric and one that guesses.

2. Programmatic discovery and querying

Agents need a standardized way to find out what metrics exist and query them. This is what isn't a performance optimization. At agent scale, it's a requirement.

5. Schema-as-code with version control

Metric definitions should live in Git. Changes should go through pull requests. Rollbacks should be git revert.

This isn't just good engineering practice. It's how you maintain trust in an agentic system. When someone asks "why did the revenue number change?", the answer is a Git commit, not "someone clicked something in the admin UI." When a definition is wrong, you revert it and every consumer immediately gets the corrected version. No agent retrained. No dashboard patched. One diff in your schema repo.

git diff HEAD~1 schema/orders.yml  # see what changed

git revert abc123                   # undo a bad metric definition

# redeploy your semantic layer, and every consumer gets the fix

Who needs an agentic semantic layer?

Different teams interact with the agentic semantic layer differently. The common thread: everyone benefits from one source of truth for metric definitions.

Data engineers and analytics engineers define the metrics. They write the YAML, review changes in PRs, and manage pre-aggregation strategies. The agentic semantic layer gives them a single place to define business logic instead of maintaining it across dashboards, notebooks, and custom API endpoints.

Engineering leads and product teams consume the metrics. They connect AI agents via MCP, build features on the REST API, and let agents chart query results in the conversation. The semantic layer means they don't need the data team to build a custom endpoint for every new feature.

Data leaders govern the metrics. They ensure definitions are correct, access controls are appropriate, and audit trails are maintained. The semantic layer centralizes governance instead of distributing it across tools.

Customers (in B2B products) query their own data. Through embedded dashboards in your product, through AI agents connected via publishable keys, or through APIs. The semantic layer ensures they see only their data, with the same metric definitions your internal teams use.

How it fits the modern data stack

An agentic semantic layer doesn't replace your existing infrastructure. It sits on top of it.

[Data Sources] → [Ingestion (Fivetran, Airbyte)] → [Warehouse (Snowflake, BigQuery)]

                                                            ↓

                                                    [dbt transformations]

                                                            ↓

                                                  [Agentic Semantic Layer]

                                                    ↙    ↓    ↘

                                            [MCP Agents] [React SDK] [REST API]

                                            [Dashboards] [TypeScript SDK]

Your ingestion pipeline feeds raw data into the warehouse. dbt transforms it into clean tables. The agentic semantic layer defines business metrics on those tables and serves them to every consumer through the appropriate interface.

The semantic layer connects to your warehouse (, (including Supabase, Neon, and RDS), (including MotherDuck)) and generates the appropriate SQL dialect. Swap warehouses without changing your metric definitions or consumer integrations.

This is the key architectural property: the semantic layer decouples metric definitions from both the warehouse and the consumer. Change your warehouse and consumers don't notice. Add a new consumer and the warehouse doesn't change. The semantic layer is the stable interface between infrastructure and applications.

Agentic semantic layer tools compared

The right choice depends on whether AI agents are your primary consumer or a secondary integration. If agents are an afterthought, most semantic layers can be retrofitted with API access. If agents are the primary interface, you need a layer designed for programmatic consumers from the ground up.

Getting started

An agentic semantic layer gives the agent governed metrics to query. The last mile is what the agent shows the user: not a wall of numbers, a chart in the conversation. That's what . For the design behind an agent-friendly chart tool, see .

Repo: for the full guide.

What makes a semantic layer "agentic"?

Three things: programmatic discovery (agents find metrics via API, not a GUI catalog), programmatic querying (agents call tools, not SQL), and structural multi-tenancy (access control enforced per query, not per dashboard). A traditional semantic layer might have an API, but an agentic one is designed for agents as the primary consumer.

How is an agentic semantic layer different from RAG?

RAG (Retrieval-Augmented Generation) feeds unstructured documents to an LLM for context. An agentic semantic layer provides structured metric definitions for data queries. RAG answers "What does our refund policy say?" A semantic layer answers "What was Q1 revenue?" They solve different problems and are often used together: RAG for knowledge, semantic layer for data.

How is an agentic semantic layer different from text-to-SQL?

Text-to-SQL lets an agent generate arbitrary SQL from natural language. The agent interprets column names and guesses business logic. An agentic semantic layer defines metrics once and lets agents query those definitions. The difference: text-to-SQL produces plausible answers. A semantic layer produces correct, governed, auditable answers. See (Model Context Protocol) is a standard protocol for connecting AI agents to external tools and data sources. It defines how agents discover available tools, call them, and receive results. For an agentic semantic layer, MCP is the interface that lets any compatible agent (Claude, Cursor, Claude Code, and others) discover and query your metrics without custom integration code.

Can any AI model use an agentic semantic layer?

Yes. A semantic layer with MCP support works with any MCP-compatible client. For other agents, REST APIs and SDKs provide model-agnostic access. The semantic layer sits between the agent and the warehouse, not inside the model. It doesn't matter whether the agent runs Claude, GPT, Gemini, or an open-source model.

What is the performance impact?

With pre-aggregation, queries get faster, not slower. The semantic layer caches rollups so agents query pre-computed results instead of running full aggregations on every request. Hot queries resolve in single-digit milliseconds. Without pre-aggregation, agent-scale query volumes (hundreds of queries per minute across multiple tenants) will overwhelm most warehouses.

How does an agentic semantic layer handle hallucinations?

It eliminates the primary source of data hallucinations: ad-hoc SQL generation. The agent never writes SQL. It selects from governed metric definitions and the semantic layer generates correct SQL. The agent can still hallucinate its interpretation of the results (that's a model problem), but the underlying data is always correct and traceable to a versioned definition.