What Is an Agentic Semantic Layer?

An agentic semantic layer is a metadata layer between AI agents and a data warehouse that defines business metrics, enforces access control, and exposes governed query interfaces. Instead of writing raw SQL, agents query metric definitions through protocols like MCP (Model Context Protocol) or REST APIs. Every agent gets the same answer because the business logic is defined once, not interpreted per query.

Traditional semantic layers were built for BI dashboards and human analysts. An agentic semantic layer is built for programmatic consumers: LLMs, AI agents, SDKs, and applications. The interface, security model, and deployment patterns are different.

The problem with AI analytics today

AI agents are becoming a primary interface to data. Executives ask Claude for quarterly numbers. Product managers ask Cursor for usage metrics. Customer success teams ask chatbots for account health scores. The agent is the new dashboard.

But most data infrastructure wasn't built for this. Two problems dominate.

Text-to-SQL breaks in production

The default approach is to give an agent access to your warehouse and let it write SQL. It works in demos; in production, text-to-SQL produces inconsistent answers, enforces no access control, and leaves no audit trail. Why Your AI Agents Need a Semantic Layer walks through each failure mode.

Legacy semantic layers weren't built for agents

Traditional semantic layers solve the consistency problem for dashboards. Looker's LookML, Tableau's semantic model, Power BI's DAX measures. They define metrics once and serve them to BI consumers.

But they were designed for a world where a human browses a catalog, selects metrics, and views a dashboard. That interaction model doesn't translate to AI agents.

Agents don't browse catalogs. They call tools at runtime. They need programmatic discovery, querying, and access control, over a standardized protocol rather than a proprietary query language embedded in a BI tool.

A BI-embedded semantic layer can't serve an MCP client. It can't scope each query to a tenant. It can't serve an AI agent, an embedded chart, and a dashboard from the same definitions.

How it differs from a traditional semantic layer

An agentic semantic layer treats programmatic access as the primary use case, so MCP support, multi-tenant keys, and row-level security are built in.

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.

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 MCP (Model Context Protocol) provides.

The agent calls explore_schema to see available cubes, measures, and dimensions. It reads descriptions to understand what each metric represents. Then it calls query with the right measures, dimensions, and filters. It never writes SQL. The semantic layer handles query generation, execution, caching, and access control.

Agent: explore_schema → "orders cube has total_revenue, order_count, status, category, created_at"
Agent: query(measures: [total_revenue], dimensions: [status], filters: [{created_at: last 90 days}])
Semantic layer: generates SQL, executes against warehouse, returns structured result

The agent selects from governed definitions, and the semantic layer's query engine writes the SQL for your warehouse dialect.

Five tools make this work:

• explore_schema: Discover available cubes, measures, and dimensions with descriptions
• query: Fetch aggregated data using governed metric definitions
• sql_query: Run queries for edge cases that need custom SQL (still governed by access controls)
• describe_field: Get detailed metadata about a specific measure or dimension
• A render tool: Return a chart or table in the conversation from the query result, so the model does not draw it from memory

3. Structural multi-tenancy

If you're building a B2B product, every agent query needs to be scoped to a specific tenant. It needs to be structural: impossible to bypass regardless of what the agent does.

    security_context:
      - name: tenant_filter
        sql: "{SECURITY_CONTEXT.tenant_id} = customer_id"

Every query for a given tenant automatically includes this filter. The consumer can't skip it. The agent can't override it. The caller's identity (an OAuth token, an API key, or a JWT) carries the tenant context, and every query is scoped from it.

This is how you ship AI-powered analytics to B2B customers without building a custom access control layer. The semantic layer handles isolation. You handle the product.

4. Pre-aggregation for agent-scale query volume

AI agents make more queries than humans. A human refreshes a dashboard once. An agent might make 10 queries to answer one question: exploring the schema, trying different dimensions, following up on anomalies.

Pre-aggregation handles this. Define which metric combinations to pre-compute:

    pre_aggregations:
      - name: daily_revenue
        measures:
          - total_revenue
          - order_count
        dimensions:
          - status
          - category
        time_dimension: created_at
        granularity: day
        refresh_key:
          every: 1 hour

The semantic layer builds and maintains these rollups. Hot queries hit the cache (single-digit milliseconds). Cold queries fall through to the warehouse. Without this, agent workloads can overwhelm your warehouse, especially when multiple customers' agents are querying simultaneously.

At agent scale, pre-aggregation is 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 is how you maintain trust in an agentic system. When someone asks why the revenue number changed, the answer is a Git commit. When a definition is wrong, you revert it and every consumer gets the corrected version.

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.

Data engineers and analytics engineers define the metrics. They write the YAML, review changes in PRs. 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 scoped to their tenant, 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] [Embedded charts] [API]
                                            [Dashboards]

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 (Snowflake, BigQuery, Databricks, PostgreSQL (including Supabase, Neon, and RDS), Redshift, DuckDB (including MotherDuck)) and generates the appropriate SQL dialect. Swap warehouses without changing your metric definitions or consumer integrations.

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. What is left is everything around the query: who is allowed to ask, which tenant's data they see, and what they get back. Bonnard covers that. It sits on dbt, Cube, MetricFlow, or a custom layer and delivers governed BI inside Claude, ChatGPT, Gemini, and Copilot. Setup is four steps: connect your data, create an app, choose the audience, publish. Each app has role-based access, tenants are isolated by one of four models, and every call is logged. Bonnard is pre-launch. Join the waitlist.

For a broader look at semantic layers beyond the agentic use case, see What Is a Semantic Layer?.

Frequently asked questions

What is a semantic layer in simple terms?

A semantic layer is a translation layer between raw data and the people or tools that query it. It defines what business terms like "revenue" or "active user" mean in terms of actual database columns and calculations. Instead of every consumer writing its own SQL, they all reference the same definition. See What Is a Semantic Layer? 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. Text-to-SQL produces plausible answers; a semantic layer produces governed, auditable ones. See text-to-SQL for more on why the raw approach breaks in production.

Do I need an agentic semantic layer if I use dbt?

dbt defines transformations: how raw data becomes clean tables. An agentic semantic layer defines metrics: what "revenue" means on top of those tables, and serves them to agents with caching and access control. They're complementary. dbt gets data into shape. The semantic layer defines the business logic on top and serves it. Most agentic semantic layers can import dbt models directly.

What is MCP and why does it matter?

MCP (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. 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.