All guides

Conversational Analytics in Looker: 6 Prerequisites

What Conversational Analytics, Gemini in Looker and Looker MCP do in 2026, why they need a clean semantic layer, six prerequisites and a four-week pilot plan.

Yousri Majani, founder of Neuravoid · 9 min read · Updated 5 September 2026

Conversational Analytics in Looker lets a user ask a question in plain language and get a number, a chart and an explanation of how it was calculated. In 2026 the feature is generally available, an API of the same name lets you embed it in your own applications, and a Looker-managed MCP server opens the model to Gemini CLI, Claude or Cursor. All of these agents share one property: they only answer correctly when the LookML model beneath them is correct. Here are the six prerequisites and a four-week pilot plan.

What these tools actually do

Google's vocabulary has shifted a lot; this is the state of play in September 2026, per the documentation and the Google Cloud blog.

Feature Status What it does
Conversational Analytics in Looker GA since November 2025 Chat over one or more Explores (up to five per agent), charts, a "how was this calculated" explanation
Data agents GA Named, shareable agents with instructions, glossary, verified queries and default filters
Dashboard agents Rolled out in 2026 A conversation panel embedded in a dashboard, scoped to its data
Advanced Analytics (Code Interpreter) Available, not for dashboard agents Generates and runs Python for analysis beyond SQL (forecasts, correlations)
Conversational Analytics API GA since summer 2026 Embed agents in your apps, Slack, portals; SDKs for Node, Python, Java, Go, .NET
Looker-managed MCP server Preview (August 2026) Gemini CLI, Claude Code and Desktop, Cursor, VS Code query the LookML model with the user's own rights, OAuth 2.1
Publishing to Gemini Enterprise Preview Agents built in Looker appear in the company's Gemini workspace

The mechanism is the same everywhere: the agent does not write SQL against your tables. It picks fields and filters in an Explore, and Looker composes the query through LookML. Joins, aggregations, definitions and permissions are the model's.

Why the semantic layer decides everything

Google says it plainly: Looker's semantic layer "reduces data errors in gen AI natural language queries by as much as two thirds". The reason is simple. An LLM writing SQL directly against tables has to guess which table is right, which column holds the net amount, how to join orders to customers without doubling rows. On a real warehouse it is often wrong, and plausibly so.

Given an Explore, it only has to choose among named, described, correctly joined fields. The net_revenue measure exists, its description says what it includes, row-level security applies automatically.

The flip side: the agent inherits every flaw in the model. Three measures called "Revenue" with different formulas, and the agent picks one at random. Four hundred fields with sixty useful ones, and it gets lost. No descriptions, and it guesses. A Conversational Analytics pilot on an unaudited model produces confident wrong answers, and the organisation concludes that "AI does not work".

The six prerequisites

1. One Explore per domain, with only the useful fields

The agent works on one to five Explores. Each should answer one family of questions (sales, marketing, support) with fields narrowed by fields: and technical fields hidden. An Explore of sixty to a hundred well-chosen fields gives better answers than one with four hundred.

2. Labels and descriptions on every field

This is the highest-return prerequisite. A business-language label, a description stating what the field includes and excludes, with the synonyms users actually say. The agent reads these to choose.

measure: net_revenue {
  label: "Net revenue"
  description: "Invoiced revenue excluding tax, net of discounts and credit notes. Synonyms: net sales, net income from sales. Reference date: invoice."
  type: sum
  sql: ${invoiced_amount_excl_tax} - ${discount_amount} - ${credit_note_amount} ;;
}

3. One definition per metric

No duplicated measures across views, no dead fields. The LookML audit checklist covers this; without it the agent is a coin toss between competing definitions.

4. Row-level security in the model

Agents honour access_filter and access grants because they go through Looker. If your restrictions lived in hand-filtered dashboards or separate reports, they do not exist for the agent. They must be in the model before the conversation is opened to anyone.

5. Reference questions with expected answers

Before the pilot, collect twenty to thirty real user questions and compute the expected answer by hand. This test set measures the agent, then feeds it "verified queries" that improve answers to nearby questions.

6. An owner and a token budget

Since the 2026 pricing page, usage is measured in data tokens with a quota included per edition (60M input and 1.2M output per month on Standard, 300M and 6M on Enterprise). Free through 30 September 2026, then billed beyond the quota from 1 October ($3 per million input tokens, $20 per million output). Someone must track consumption in System Activity and own answer quality.

A four-week pilot

The format that works: one domain, one user group, one quantified success measure, one decision at the end.

Week 1: scoping and targeted audit. Pick the domain (the one where ad hoc requests clog the data team most). Audit the relevant Explore against prerequisites 1 to 4, fix on a branch. Collect the thirty reference questions with the future users. Confirm Gemini in Looker is enabled and permissions are in place.

Week 2: build the agent. Create a data agent on the fixed Explore. Write the instructions (business context, units, fiscal year, what not to do), the glossary, the default filters. Load five to ten verified queries. Run the thirty questions: score correct, wrong, ambiguous. Week-end target: 70 percent correct.

Week 3: iterate and open up. Fix the causes of wrong answers, almost always in the model (an ambiguous description, a missing measure) rather than in the agent. Rerun the test set, aim for 85 to 90 percent. Open to ten real users with a simple feedback channel. If the use case calls for it, test the dashboard agent or MCP access from Gemini CLI.

Week 4: measure and decide. Count questions asked, the share of answers users rated useful, data-team time saved on ad hoc requests, token consumption. Decide: extend to a second domain, embed via the API in a business tool, or stop. Write down why.

What we see in production: in a large industrial group, the Looker semantic layer on BigQuery had been in place for several years before the agent question came up. The preparatory work was not building the model but cleaning it for a reader with no implicit context: descriptions, removing duplicates, tightening Explores.

What not to expect

Agents do not replace modelling. They do not reconcile three revenue figures; they show one, confidently. They do not fix a join that doubles rows. They do not invent a measure that is not in the model, and that is a feature.

Nor do they replace dashboards. Leadership's recurring questions are still better served by a fast, stable dashboard. Agents serve the long tail: the questions nobody asked because it meant waiting for an analyst.

FAQ

Do I need a specific Looker edition for Conversational Analytics?

The feature is available on Looker (Google Cloud core) and Looker (original) once an admin enables Gemini in Looker. Data token quotas differ by edition, and the managed MCP server is not available for customer-hosted instances.

Can the agent see data the user is not allowed to see?

Not if it goes through Looker. Agents, the API and the MCP server apply the authenticated user's roles, access grants and access_filter. That is exactly why security must live in the model rather than in dashboards.

What happens when the agent gets it wrong?

Every answer exposes the generated query and the calculation explanation. The user can check the fields and filters chosen. Recurring errors are fixed by improving descriptions, adding a verified query or tightening the Explore, not by retraining anything.

How much does a pilot cost?

Software cost is zero through 30 September 2026, then covered by the included quota for a ten-user pilot. The real cost is the time to prepare the model and build the agent: four weeks for one domain, with a business contact available two hours a week.

Next step

If you are considering a pilot, start with the thirty reference questions and a review of the relevant Explore. Those two deliverables decide the pilot's outcome before the agent is even created.

See the Analytics agents service, and read next: The LookML audit checklist and Why your numbers disagree.

Sources

All guides

9 min read · 6 September 2026

Looker for e-commerce: margin, AOV, repeat, one revenue number

Ten e-commerce metrics defined once in dbt and exposed in Looker: net revenue, margin, AOV, repeat rate, returns, grain trap. With a public reference repo.

Read the guide →

10 min read · 6 September 2026

Looker for fintech: TPV, chargebacks, churn, loan book

Settled vs attempted TPV, take rate, chargeback ratios against Visa and Mastercard thresholds, customer-month churn, point-in-time loan book, SCD2. Public repo.

Read the guide →

9 min read · 6 September 2026

Looker for healthcare: readmissions, length of stay, patient data

OMOP in brief, 30-day readmission and length of stay defined once in dbt, prevalence by concept hierarchy, patient fields protected in Looker. Public repo.

Read the guide →