Every conversational analytics demo follows the same script. Someone connects a model to a clean warehouse schema, types "show me revenue by region last quarter," and gets a correct chart in four seconds. The room nods. Then somebody says the sentence that has launched a thousand doomed pilots: "Now let's roll it out to the whole company."
I have spent the last few years doing exactly that rollout — building governed conversational analytics on Looker and its semantic layer, most recently exposing it to AI agents through the Model Context Protocol (MCP). The rollout I work on now runs at enterprise scale, and the metric that matters isn't the user count. It's accuracy — the kind you can defend in a board meeting — achieved not by using a bigger model, but by refusing to let the model touch raw data at all.
Here is what actually breaks between the demo and production, and why the fix is architectural, not prompt-based.
Break #1: Your company doesn't have one definition of anything
Ask a demo dataset for "revenue" and there's one column. Ask a real company and you get a knife fight. Finance's revenue is recognized revenue, net of refunds, on an accrual basis. Sales' revenue is bookings. Support's "active customer" hasn't opened a ticket in 90 days; Growth's "active customer" logged in this week. These aren't errors. They're legitimate, battle-tested definitions that happen to share a name.
An LLM pointed at raw tables has no way to know which definition you meant — so it guesses, fluently and confidently, and it guesses differently on Tuesday than it did on Monday. This is the failure mode that kills trust in production, and it never appears in demos because demo schemas have one table per concept.
The fix is unglamorous: a semantic layer where each metric is defined exactly once, in code, with the business logic owned by the people accountable for it. In Looker, that's LookML — measures, dimensions, and joins curated by data teams, version-controlled, reviewable. When the model asks for "revenue," it isn't writing SQL against a guess. It's invoking a definition that already survived your company's internal arguments. The semantic layer is the contract between the LLM and your data: the model decides what the user is asking, the layer decides what the data means.
This is also why text-to-SQL demos age so badly. Generated SQL re-derives your business logic from scratch on every single question, with a probabilistic engine. A semantic layer derives it once, deterministically, and reuses it forever.
Break #2: The model is the wrong place to enforce access control
The second thing that breaks is security, and it breaks quietly. In a traditional BI setup, access control lives close to the data: row-level filters, column restrictions, user attributes. Put an LLM in front of the warehouse with a broad service account — the default in most quick integrations — and you have just handed every user the union of all permissions the agent can reach, wrapped in a friendly chat interface.
Natural language makes this worse, not better. Nobody types "SELECT salary FROM…" into a chat box by accident; they ask "who on the team got the biggest raise?" A model eager to be helpful will route around your intent unless the data layer itself says no.
The principle that works in production: the agent inherits the requester's permissions, never its own, and enforcement happens at the data layer, not in the prompt. With a semantic layer in the middle, every query the agent issues carries the user's attributes, and the same row- and column-level rules that govern your dashboards govern the conversation. "Please ignore your restrictions" is not an attack a data layer has to care about. I've written elsewhere about the harder version of this problem — what happens when agents start caching and sharing results with each other — but the baseline rule is simple: if a control only exists in the system prompt, it doesn't exist.
Break #3: "Mostly right" is a failing grade
In a demo, a slightly wrong number is a chuckle. In production, one executive catches one wrong number in one board meeting, and your rollout is dead for a year — not because the system is bad, but because trust in data tools is binary in a way trust in search results isn't.
This is why the architecture above isn't optional decoration. Deterministic definitions (the semantic layer), deterministic permissions (the data layer), and a model constrained to intent-parsing and presentation is how you get from "impressive demo" to answer accuracy you can defend in production. It also gives you something a raw LLM integration never will: an audit trail. Every answer can be traced to a governed query against named definitions, which matters the first time someone asks "where did this number come from?" in a regulated business.
Connecting this to agents through MCP is what makes it timely. When we exposed the semantic layer through Looker's MCP server — including to desktop agent clients across the company — the agents didn't get new powers. They got a well-lit doorway into powers that were already governed. That's the pattern I'd argue for everywhere: don't build a special, weaker governance regime for AI. Route AI through the governance you already trust, and let the model be the interface rather than the authority.
What I'd tell any team starting today
Start with twenty questions your business actually asks, define those metrics properly in a semantic layer, and only then connect the model. Resist the warehouse-wide text-to-SQL launch; it's a demo that scales its failure modes along with its coverage. Enforce access where the data lives. Measure accuracy like an SLO, with a golden set of questions and known-good answers, and publish the number internally — nothing builds adoption like a team willing to be measured.
The demo is the easy part; it's supposed to work. Production is where the same KPI has three definitions, the helpful model outruns its permissions, and one wrong number costs you the room. All three failures are fixable — but they're fixed in your data architecture, not in your prompt.
Venkata M Sangaraju is a Sr Database Engineer working on governed conversational analytics and AI agents over enterprise data. He spoke on this work at Google Cloud Next '26 and co-authored "Lineage-Aware Memory Governance" (IEEE Access, 2026).
