dbt Semantic Layer for AI Agent Querying

AI agents don't know what they don't know. Ask one for last quarter's revenue and it will give you a number, complete with confidence and formatting, whether or not that number is right. That's the core problem this piece is about: agents are built to produce a plausible-sounding answer rather than a verified one, and when the underlying data is messy or the business logic is undefined, they'll hand you a wrong answer that looks exactly like a right one. The dbt Semantic Layer exists to close that gap, and it's worth understanding exactly how.

How widespread the data quality problem is, and what it costs AI projects

Start with a number that should worry you. In a February 2025 Qlik survey of 500 U.S. AI data professionals, 81% said their company still has significant data quality issues. Only 15% said leadership was actually doing something about it. The gap between awareness and action is expensive.

The IBM Institute for Business Value put a dollar figure on it in 2025: more than a quarter of organizations estimate they lose over $5 million a year to poor data quality. Seven percent report losses of $25 million or more. Those numbers come from companies reporting about themselves, not from a vendor pitch deck.

Here's the thing nobody wants to say out loud: it's almost never the model's fault. I've sat in enough post-mortems to know the pattern by heart. Marketing has one definition of "customer." Finance has another. Product has a third. Nobody agrees on what counts as an "order" once refunds and partial shipments get involved. The model is being asked to reconcile three different businesses that happen to share a warehouse.

Now layer agents on top of that mess. TDWI's benchmark study found around 10% of organizations already have multi-agent systems running in production, and that number is only going up. The infrastructure to run agents is way ahead of the infrastructure to make sure they're right. Data quality, governance, and basic organizational readiness are lagging behind the capability curve, and that gap is where trust goes to die.

Bryan Himsworth at OvalEdge reported in 2025 that over 60% of organizations deal with conflicting metrics across teams. Every one of those conflicts erodes trust a little more and slows every decision that touches the number. For a reader trying to ship an AI project, the lesson is blunt: data quality isn't cleanup you schedule for later. It's the reason the project stalls before it ever reaches production.

What the dbt Semantic Layer actually is and what it does at query time

Picture the semantic layer as a translator sitting between your warehouse, whether that's Snowflake, Databricks, BigQuery, or Redshift, and whatever tool is asking it questions. Could be a BI dashboard. Could be a data scientist in a notebook. Increasingly, it's an AI agent.

Under the hood, it runs on MetricFlow, dbt's SQL generation engine. MetricFlow reads YAML files that describe your semantic models and metrics, and at query time, it builds the actual SQL for whichever warehouse you're running. You write the logic once, in plain, versioned config; MetricFlow handles translating that into platform-specific SQL every single time someone asks a question.

What's actually in that YAML matters a lot. It holds the metric calculations, including the messy stuff like time-based windows, conditional logic, and nested aggregations that usually live in someone's head or a half-forgotten wiki page. It holds entity relationships, so joins get resolved automatically instead of someone guessing which key connects orders to customers. And it holds business-meaningful names and descriptions, which is exactly the context an agent has zero access to when it's just staring at a raw schema.

That last point is worth sitting with for a second. Governance here gets enforced in the path of every single query, at the exact moment semantic meaning gets resolved, before any SQL even gets generated, rather than sitting off to the side as a policy reviewed once a quarter.

The layer gets exposed through GraphQL and JDBC APIs, so custom tools and agents can hit it directly. Because the definitions are version-controlled, when someone updates how "active customer" is calculated, every tool downstream, dashboards, notebooks, agents, gets the new logic automatically. Nobody has to go update twelve different queries by hand.

The distinction that matters most: this is the execution layer, the thing that actually runs when a question gets asked, rather than a catalog or a policy document sitting in Confluence that everyone ignores.

The accuracy gap between text-to-SQL and semantic-layer grounding

Text-to-SQL has gotten a lot better, and it's worth giving credit where it's due. Accuracy roughly doubled between 2023 and 2026, moving from about 32.7% up to 64.5% on benchmark tasks.

Here's the number that actually matters: even at that 2026 peak, text-to-SQL still trails a modeled semantic layer, which hit 72.7% overall accuracy in the same dbt Labs benchmark, cited by Atlan. That gap alone would be reason enough to care. The bigger story, though, is in how each approach fails.

Semantic-layer failures tend to look like a shrug: "I can't answer that with the data I have." Text-to-SQL failures tend to look like confidence: a specific number, formatted cleanly, that's simply wrong. One failure mode tells you something's off. The other one gets copied into a board deck.

Enterprise-realistic testing makes the gap even starker. Lei and colleagues built a 632-task benchmark out of real enterprise workflows for ICLR 2025, and frontier models that scored well above 80% on academic SQL benchmarks dropped to a fraction of that on these enterprise tasks. The models weren't suddenly bad at writing SQL. They just had no idea what the business meant by the terms in the question.

Databricks documented the same pattern with its AI/BI Genie tool: baseline accuracy on its own, a real jump once you add metadata enrichment, and another jump on top of that once you give it full metric definitions and example SQL. AtScale reports something similar, near-zero accuracy on complex questions without a semantic layer, rising substantially once one's in place.

Put plainly: the models can already write syntactically correct SQL. What they can't do, on their own, is know what a business metric actually means. That knowledge has to come from somewhere outside the model, and right now, the semantic layer is the most reliable place to put it.

How MCP connects AI agents to the semantic layer at runtime

Anthropic introduced the Model Context Protocol, or MCP, in late 2024, and it solves a problem that was previously an open wound: how does an agent get access to governed business logic instead of just raw, uncontextualized tables? MCP gives that connection a standard shape, with traceability and auditability built in rather than bolted on.

dbt's MCP server is generally available now. It works by exposing MetricFlow's metric definitions, lineage metadata, and transformation context to any agent that connects to it. That transformation context matters more than it sounds like it should, because that's where most of the actual business logic in a dbt project lives.

Without that server in place, an agent querying your dbt data is flying blind. It has no reliable way to check what a metric definition actually says, so it guesses, and guessing is exactly the failure mode we've been talking about this whole piece.

dbt Labs ran a webinar called "Building the Interface for AI Agents" that walks through Claude querying enterprise data over MCP, and it's a genuinely useful demonstration of how to structure and expose metrics so the agent lands on consistent, correct answers instead of plausible-sounding ones. dbt's own Analyst agent, available inside dbt Insights, takes this further: someone types a plain-language question, and the agent runs real analysis grounded in the same governed metrics everyone else in the company is using.

MCP is quickly becoming the standard way agents connect to tools across the industry, not just inside dbt's world. That matters for the semantic layer specifically, because its value compounds as more agents, from more places, start speaking the same protocol to reach it.

What governance actually looks like when it runs through the semantic layer

The instinct with AI agents is to lock down raw tables and hope for the best. A better approach: give agents curated metrics and dimensions through the semantic layer, so there's nothing ungoverned to accidentally expose.

Access controls get enforced at query time, scoped to whoever's actually asking, not assumed from some broad service account that has access to everything. Every query leaves a trail: what was asked, who asked it, which metric definitions got resolved, which tables in the warehouse actually got touched.

Sensitivity gets checked at the point where data actually combines, not just field by field. That distinction is easy to miss but it's the whole game: a join between two individually harmless fields can produce something sensitive, and a governance system that only checks fields in isolation will wave it right through.

AtScale's "Semantic Layer 2025 in Review" points to composable governance, treating semantic models as version-controlled, shared code with full lineage and auditability, as the leading architectural pattern going into 2026. The State of AI+BI Analytics Global 2025 Report found 38.3% of organizations now list governance frameworks and semantic layers among their top investment areas. That's not a niche concern anymore.

What this all adds up to: an agent running through the semantic layer plays by the exact same rules as a human analyst, with the same permissions, the same lineage, and the same audit trail, rather than some weaker, agent-shaped version of governance bolted on as an afterthought.

What it takes to wire up the dbt Semantic Layer for agent querying

Everything starts in YAML. You define your semantic models, entities, dimensions, measures, and your metrics inside your dbt project files. This is the single source of truth; everything downstream, every dashboard, every agent, inherits from it.

MetricFlow checks your definitions at build time, which means bad logic gets caught before it ever reaches a production query and quietly returns garbage to someone. That's a much better place to catch a mistake than in a board meeting.

From there, you expose everything through the Semantic Layer API, either GraphQL or JDBC, and that's the actual surface that BI tools and agents hit when they ask a question. Agents specifically connect through the MCP server: you configure it so agents get the metric definitions, the lineage, and the transformation context bundled together with the raw data, not just the numbers on their own.

Naming matters more than people expect. How you name and describe metrics in YAML, and how you define the relationships between them, directly shapes whether an agent resolves the right definition when someone asks a vague question. Call something "rev" instead of "netrevenuerecognized" and don't be surprised when the agent gets confused; vague names produce vague queries, every time.

Access control lives in one place too. Permissions set in the semantic layer propagate to every consumer downstream, agents included. You don't need a separate, agent-specific policy layer sitting next to the one you already built for humans.

None of this requires ripping out your warehouse. The semantic layer sits on top of Snowflake, Databricks, BigQuery, or Redshift, whatever you're already running. My advice, having watched a few of these rollouts: don't try to model everything on day one. Start with the metrics where a wrong answer actually hurts, revenue, churn, margin, get agent behavior right against those, then expand from there.

Where the dbt Semantic Layer ends and complementary tooling begins

dbt's semantic layer is tightly woven into the dbt transformation workflow, and it shows: it's strongest for teams already running dbt for their modeling and transformation work. If that's you, adopting it is mostly a matter of configuration, not a rebuild.

The appetite for this kind of infrastructure is bigger than dbt alone, though. The Modern Data Company's 2026 report, "The Data Activation Gap," surveyed more than 500 data practitioners and found a strong majority now name a unified semantic layer as the single most important thing standing between them and real AI value, ahead of better models, ahead of more tools. MIT CISR's research from May 2026 backs this up from a different angle: leadership pressure is growing to invest in semantic technology that makes data useful to humans and agents at the same time, which means this stopped being a data engineering concern a while ago and became a leadership one.

It's worth being honest about the edges, too. dbt's MCP server covers lineage, metric definitions, and transformation context, and it does that well. It doesn't federate across data sources that live outside dbt, and it doesn't reach into SaaS tools or operational systems that were never part of a dbt pipeline in the first place.

For companies where data is scattered across warehouses, SaaS platforms, and operational systems that were never built with AI consumption in mind, that's a real gap. Peaka addresses it by sitting on top of existing infrastructure and exposing one queryable interface with semantic context, query-time permissions, and lineage that spans all of those sources at once, without forcing a migration or a pipeline rebuild.

So the question worth asking about any semantic layer you're evaluating isn't just "does it work." It's: which sources does it actually reach, and what happens the moment an agent asks about data living outside its boundary. Because that's where the confident wrong answer creeps back in.

The architectural principle underneath all of this doesn't change based on which tool you pick. The semantic layer is the governance and context infrastructure that makes it possible to trust an agent's answer at all, wherever that layer happens to live, well beyond its origins as a BI feature bolted onto a dashboard.