Google Shows How to Build AI Analysts in Under 5 Minutes

Okay so Google just dropped a tutorial on building AI-powered analytics agents, and the pitch is basically: "You can do this in five minutes with zero SQL knowledge." Which... honestly? That's both the coolest and most concerning thing I've heard all week.

Chrissie Goodrich from Google Cloud Tech walks through the whole process using Looker's Chrome UX block—a pre-built data model that connects to real website performance metrics. The demo is slick. It's fast. And it raises some genuinely interesting questions about what happens when we make data analysis this frictionless.

The Five-Minute Promise

Here's what Goodrich demonstrates: You install a block from the Looker Marketplace (basically a plug-and-play data model), connect it to the Chrome UX Report—a public dataset tracking how actual users experience websites—and boom, you have an AI agent that can answer questions about site performance.

No SQL. No LookML. The block already has "the metrics defined in natural language, which means your agent has an informed knowledge engine right out of the box."

The agent can tell you how your site's loading speed compares to competitors, show performance trends since 2017, and explain technical metrics in plain English. In the demo, Goodrich asks it to compare Google Docs against Google Scholar, and the agent immediately serves up useful benchmarks.

It's legitimately impressive. But the interesting part isn't the setup—it's what happens when Goodrich tries to break it.

Teaching AI Agents Boundaries

The tutorial spends significant time on something most "here's how easy this is!" demos skip entirely: instruction design. Goodrich walks through creating specific guardrails for the agent's behavior.

She tells it to stay on topic and "refocus the user if they ask questions beyond the scope of the data." She defines which performance metrics to prioritize. She restricts it to data from January 2024 onwards. She even instructs it to add missing URL prefixes automatically.

Then comes the testing phase, which is where things get real. Goodrich asks the agent: "What's the weather like in New York City?"

The agent refuses—but for an interesting reason. "The agent triggered our custom rejection, but we did already mention weather in our prompt," Goodrich notes. So she tries something completely unrelated that wasn't mentioned in the instructions.

The result? The agent politely declines. "This shows us the agent seems to be grounded in our instructions, not merely its general training data," she explains, "and it's not that interested in poetry."

This is the actually fascinating tension: We're building AI systems that need explicit boundaries, then testing whether those boundaries hold. And we're doing it democratically—anyone with Looker access can spin up these agents now.

The Guardrail Problem

What Goodrich is demonstrating, whether intentionally or not, is that conversational AI agents require extensive behavioral scaffolding. The five-minute setup is real, but the work of making the agent useful versus chaotic is all in those instructions.

Consider what she's encoding: date restrictions, metric preferences, scope limitations, error handling for incomplete URLs, default device filtering. That's not just configuration—it's essentially writing policy for an autonomous system.

And here's where I start squinting at my screen: How many people spinning up agents in five minutes are going to invest time in robust instruction design? How many will test edge cases? The barrier to entry is beautifully low, but the barrier to doing it well hasn't changed much.

Google's tutorial is honest about this. "Be sure to become familiar with the limits and capabilities of AI agents and experiment with instructions," Goodrich advises. "Apply clear labels, use synonyms, and address data quality to make your agents robust."

Translation: The five-minute part is installation. The indefinite part is making sure your AI analyst doesn't confidently hallucinate insights.

What This Actually Enables

The Chrome UX data itself is legitimately useful—it's real-world website performance metrics from actual users, not synthetic tests. Being able to query it conversationally opens analytics to people who couldn't access it before.

Goodrich points out that you can "look for your company's site to offer immediate impact with an AI powered agent." The use case is clear: marketing teams comparing load times against competitors, developers tracking performance trends, product managers getting quick benchmarks without bugging the data team.

But there's an unstated question hovering over all of this: What happens when insights become this easy to generate? When anyone can spin up an agent and ask it questions, who's validating the answers? Who's checking that the guardrails are appropriate?

The video addresses this obliquely by mentioning different permission roles—there's a "conversational analytics agent manager" role for building agents, and a "conversational analytics user" role for people who just ask questions. That's governance architecture, which is smart. But it's also a reminder that these aren't neutral tools—they require institutional thinking about access and accuracy.

The Data Layer Nobody Sees

Here's what I find myself thinking about: The Chrome UX Report has been public since 2017. It contains genuinely valuable performance data. But most people couldn't use it effectively because you needed to know BigQuery, understand the schema, write SQL.

Now that friction is gone. Which means the Chrome UX data might actually become influential in ways it wasn't before—not because the data changed, but because the access model did.

That pattern repeats across AI tooling. We're not necessarily getting new capabilities; we're getting distributed capabilities. The analysis that used to require a specialist can now be done by whoever's curious enough to click through the Marketplace.

Which is either democratization or commodification, depending on your mood and whether the agent just confidently told you something wrong.

Where This Gets Weird

Goodrich's demo is straightforward because she's using clean, structured, public data with clear definitions. But Looker's conversational analytics agents aren't limited to the Chrome UX block. You can connect them to your own datasets, your own explores, your own messy organizational data.

And that's where instruction design gets significantly harder. When your data has quality issues, conflicting definitions, or institutional context that's not captured in field names—how do you encode that into agent instructions? How specific do those guardrails need to be?

Google's tutorial gestures at this: "Apply clear labels, use synonyms, and address data quality to make your agents robust." But that's the work of data governance, not a five-minute tutorial. The ease of agent creation might actually expose how messy most organizational data really is.

The Permission Layer

The video mentions permission requirements multiple times—you need specific roles, you need the right connections, you need marketplace access. That's standard enterprise software stuff, but it's worth noting: This isn't actually "anyone can build an AI analyst." It's "anyone with the right Looker permissions and BigQuery connections can build an AI analyst."

Which is still a dramatically lower barrier than before. But it means the gatekeeping has moved from technical knowledge to institutional access. Whether that's better depends entirely on your organization's permission structure and whether the people with access are the ones who should be creating agents.

The shift from "you need to know SQL" to "you need the conversational analytics agent manager role" is genuinely significant. It changes who can participate in data analysis. But it doesn't eliminate the need for judgment about what agents should exist and what they should do.

Goodrich's tutorial works because she demonstrates that judgment—testing the agent, refining instructions, thinking about scope. The question is whether the five-minute pitch encourages that same rigor, or whether it accidentally suggests that spinning up agents is consequence-free.

Because here's the thing: When you can create an AI analyst in five minutes, the bottleneck isn't creation anymore. It's knowing whether you should, what it should do, and how to verify it's doing it correctly. Those questions don't have five-minute answers.

—Zara Chen, Tech & Politics Correspondent