How to Build a Looker AI Agent

Looker's LookML layer is a semantic model: it defines what revenue means, how orders join to customers, which rows a regional manager may see, and what a chart's numbers are based on. That is exactly what an AI agent needs and what most BI tools lack, and it is why a Looker agent that queries through the model produces numbers that match the dashboards rather than contradicting them. This guide covers building one that uses the model properly, drawing on FISTA Solutions' AI agents delivery on analytics platforms. It complements how to build an ai analyst agent and how to build a text to sql agent.

Why query through LookML?

Because it carries the three things the agent would otherwise have to reimplement, and would reimplement wrongly.

Concern	Raw SQL agent	Explore-based agent
Metric definitions	Reinvented per query	Inherited from LookML
Joins and grain	Guessed from schema	Defined in the model
Row-level security	Must be reimplemented	Applied by access filters
Consistency with dashboards	Frequently contradicts	Matches by construction
Caching	None	Looker's cache applies
Cost control	Unbounded	Query limits and timeouts apply

An agent that bypasses the model for raw SQL loses all of that and produces the classic failure: a fluent answer with a number nobody else's chart shows. Everything should go through explores, and if an explore cannot answer a legitimate question, that is a modelling gap for the data team to close.

How does execution work?

Through the Looker API. The agent constructs an explore query specifying the model, explore, fields, filters, sorts, and limit, and runs it. The result returns as structured data the agent can present or reason over.

The essential practice is running as the requesting user, using sudo with appropriate API credentials or user-scoped tokens, so that model permissions, access filters, and row-level security apply exactly as in the interface. A service account with broad access that queries on behalf of everyone produces results users should not see, which is a disclosure problem rather than an analytics one.

What grounds the agent?

LookML metadata: explore names, field names, labels, descriptions, types, and the view relationships. This is what lets the agent map a natural-language question to the right explore and fields.

Descriptions are the critical and neglected part. A model with three fields labelled "revenue" and no descriptions gives the agent nothing to choose on, and it will choose wrongly. Investing in field descriptions that state what the field means, its grain, and when to use it is the highest-return preparation for a Looker agent, and it improves the human experience too.

How are questions translated?

Into explore queries with explicit fields and filters, using the metadata to choose. A question about last quarter's revenue by region maps to the sales explore, the revenue measure, the region dimension, and a date filter, and the agent returns the result with exactly that specification and a link to the query in Looker.

Ambiguity produces a clarifying question. Which revenue measure, which date field, whether to include refunds, and what "region" means when the model has sales region and shipping region are decisions the agent surfaces rather than guesses. A clarifying question costs the user five seconds; a silently wrong basis costs them a decision.

How are results presented?

With provenance every time: the explore, the fields, the filters, the date range, and a link to open the query in Looker. That lets the user verify, adjust, and share, and it means the agent's answer is a Looker query rather than an assertion.

For results that warrant it, the agent can also return a chart by creating a Look or a query visualisation, but the table with provenance is the baseline.

How is warehouse cost controlled?

Deliberately. An agent that issues exploratory queries in response to every question can generate substantial warehouse spend, particularly on pay-per-query platforms. Looker's cache absorbs repeated queries; row limits and timeouts bound individual queries; and the agent's total query volume and cost per question should be monitored from the first day.

Where a question requires a heavy query, the agent should say so and confirm before running rather than issuing it silently. See ai cloud cost optimization.

How is it evaluated?

Against real questions with answers verified by building the query in Looker. Measure whether the agent chose the right explore and fields, applied the right filters, and returned a matching number. Measure clarification behaviour on ambiguous questions. Test as users with different access filters to confirm results differ correctly, which is the permission test that matters most.

What does the build sequence look like?

One to three weeks improving LookML descriptions and labels for the explores in scope, which is modelling work and the step that determines quality. One week on API access and user-scoped execution. Two weeks on question translation with the data team testing against their own queries. One week on presentation and query links. Then expansion to further explores.

What goes wrong?

Raw SQL. A service account querying for everyone. Explores with no field descriptions. Silent disambiguation. Unbounded query volume against the warehouse. Answers without query links. And treating the agent as a replacement for the model rather than a consumer of it, which reintroduces every inconsistency LookML exists to remove.

How does this fit with Looker's own conversational features?

Looker ships conversational analytics capability, and where it meets the need it should be used rather than rebuilt. A custom agent earns its place where the organisation needs its own presentation and integration into the tools people work in, wants to combine Looker results with other systems, needs evaluation against its own reference questions, or has ambiguity-handling requirements the platform feature does not meet. The custom agent should still query through explores; the difference is in what surrounds the query, not in bypassing the model.

How FISTA Solutions helps

FISTA Solutions builds Looker agents that query through LookML explores as the requesting user, grounded in enriched field descriptions, translating questions into explicit explore queries with provenance and links, asking on ambiguity, and running under query budgets that protect the warehouse, through AI enablement, AI agents, and forward deployed engineers working with data teams. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To give users conversational access to governed data, message FISTA on WhatsApp, or read how to build an ai analyst agent.