# Text-to-SQL Agents Are Breaking the Semantic Layer dbt Built > Source: > Published: 2026-10-15 13:16:11+00:00 **TL;DR —** Semantic layers like dbt's metrics layer, Cube, and LookML exist to stop every tool from reinventing what 'revenue' means. Text-to-SQL agents skip that layer and query raw warehouse tables directly, which quietly recreates the exact metric-definition chaos semantic layers were built to kill. The fix is architectural: give the agent the semantic layer's API as its tool, not a raw SQL connection to the warehouse. Every data org eventually relearns the same lesson: if two tools can compute "revenue" independently, they will compute it differently, and someone in a leadership meeting will notice. The semantic layer exists to prevent that. dbt's metrics layer, Cube, LookML, MetricFlow — different implementations of the same idea: define a metric once, centrally, and make every downstream consumer ask for it by name instead of re-deriving it from raw tables. LLM agents are quietly breaking that discipline. Not through malice or a design flaw in the models — through plain architectural convenience. The fastest way to build a "chat with your data" feature is to give an agent a SQL tool, point it at the warehouse, and let it generate queries against the physical schema. It works great in a demo with twelve tables. It becomes a liability at the scale where semantic layers were invented to help in the first place. Before semantic layers, every BI tool, every analyst, and every ad hoc script had its own definition of core metrics. "Active user" might exclude trial accounts in one dashboard and include them in another. "Net revenue" might or might not subtract refunds depending on who wrote the query. None of these definitions were wrong, exactly — they were just inconsistent, and inconsistency at the metric layer is worse than being wrong consistently, because it's invisible until two numbers that should match don't. The semantic layer fixes this by moving business logic out of individual queries and into a shared, versioned definition layer. "Revenue" becomes a named object with a formula, a grain, allowed dimensions, and lineage back to source tables. Every consumer — Looker, a dashboard, a Python notebook — asks the semantic layer for revenue instead of writing the SQL to compute it. One definition, many consumers. That's the whole value proposition. Now put a natural-language agent in front of the raw warehouse. Someone asks, "what was our revenue last quarter?" The agent doesn't call the semantic layer — it was never given that tool. It introspects the schema, finds a table that looks like orders or transactions, infers a plausible join, writes SQL, and returns a number with total confidence. That number might be close. It might even be right once. But it was derived independently, from the agent's own read of column names and foreign keys, with no awareness of the refund logic, the currency conversion step, or the exclusion of test accounts that the finance team's canonical metric already encodes. Ask the same question in a new session, with slightly different phrasing, and the agent may join a different table or apply a different filter. You now have the pre-semantic-layer problem back, except the inconsistent query is being written by something that sounds authoritative and never says "I'm not sure." This is worse than the old multi-dashboard inconsistency in one specific way: a dashboard's SQL is static and auditable by a human who built it once. An agent's SQL is generated fresh, silently, per request. There's no artifact to review before the number ships into a Slack message or a report. The instinct is to patch this with better prompting — feed the agent a data dictionary, add comments to columns, paste in the dbt docs. That helps marginally and caps out fast, because you're asking an LLM to re-derive, from documentation, the exact logic a semantic layer already compiled and tested. You're solving a solved problem with probabilistic text generation. The better fix is architectural: don't give the agent a SQL tool against the warehouse at all. Give it a tool against the semantic layer's query API. MetricFlow, Cube, and most modern semantic layers expose programmatic interfaces — you can request a metric, a set of dimensions, filters, and a time grain, and get back a result computed through the canonical definition. That's the surface the agent should see. This changes the agent's job in a way that matters for reliability. Instead of "write correct SQL against an unfamiliar, hundred-table schema" — a task with enormous surface area for silent error — the task becomes "select the right metric and dimension names from a bounded, declared vocabulary." That's a much narrower, much more checkable problem. You can validate metric and dimension names against a schema before execution, the same way structured function calling validates arguments. The agent isn't inventing a join path through the warehouse; it's picking from a menu that was already reviewed by the people who own the business logic. It also fixes the audit problem. "Which metric and filters did the agent use" is a question you can log and review. "What ad hoc SQL did the agent happen to generate on this request" is not something anyone is going to review before it reaches a stakeholder. Semantic layers don't cover every question. Analysts ask long-tail, exploratory questions that nobody has modeled yet — a one-off cut by a dimension that's never been defined, a correlation nobody anticipated. Forcing every agent query through a fixed metric catalog will frustrate real use cases. The honest answer is a tiered tool design, not a single tool. Favor the semantic layer for anything matching a known metric — this should be the default path and the one trusted for anything that gets repeated or reported. Allow raw SQL generation as an explicit fallback for genuinely exploratory questions, but mark its output differently: lower confidence, visibly "not a canonical metric," and ideally routed to a sandboxed read replica rather than production warehouse credentials. There's a second-order benefit to this tiering that's easy to miss: it turns agent usage into a feedback signal for the semantic layer itself. If users keep asking fallback SQL questions that cluster around the same dimension cut, that's a strong, concrete signal that the metric catalog is missing something real — not a hypothetical modeling exercise, but a demonstrated demand pattern. The semantic layer stops being a static artifact maintained by a data platform team in isolation and starts being a living contract shaped by what agents are actually being asked. That's a far better feedback loop than the current default, where every unmodeled question just gets quietly re-derived from scratch, forever, by whichever agent happens to answer it. Semantic layers were never really a BI feature. They were an answer to a coordination problem: how do you let many independent consumers compute the same number consistently. LLM agents are a new, very active consumer of warehouse data, and right now most of them are opted out of that coordination by default — not on purpose, just because "connect the agent to SQL" was the easiest thing to build. Treat the semantic layer as the tool contract for your agents, not an afterthought for your dashboards, and you keep