How the best AI-ready product teams get a head start on building right

Imagine it's 80 degrees in Miami. A group of store managers at a U.S.-based global retailer are staring at a warehouse full of winter jackets that just arrived. An AI agent saw November on the calendar, confirmed the store was active, and did exactly what it was designed to do: trigger a shipment. The data told it to. So it did.

The AI wasn't broken. The data underneath it was.

That story, shared by Ada Lau, Head of AI Data Consulting at Google Cloud, during her session at MXP San Francisco, was the sharpest illustration of a problem that most teams building AI products are still avoiding. Getting AI right is both an engineering and a data challenge. And that gap is where a lot of otherwise well-designed AI features go sideways.

The old rule still applies. Bad data in, bad outputs out. But AI adds a new wrinkle—it executes on bad data with complete confidence.

The Miami jacket situation happened because the data model had what it needed on the surface: a product entity, a store location, a launch month. What it didn't have was any connection to weather. No temperature attributes, no seasonality logic, nothing that would tell the agent "Miami in November is not the same as Chicago in November." The agent looked at the available data, found no contradicting signal, and acted.

Lau's point wasn't that the AI was dumb. It was doing its job perfectly. The problem was structural, and structural problems don't announce themselves. They hide in data models that were built quickly, under deadline pressure, by people solving for today's dashboard with no thought what an autonomous agent might do with that data six months later.

This is the challenge that AI product analytics has to reckon with. AI features can appear to be working until they aren't, and by the time a user notices, the damage is done.

The current process for building and maintaining data models, Lau argued, is slow, linear, and consistently outpaced by the rate at which AI features are being shipped.

Here's a scenario most data teams will recognize:

Repeat this enough times and you have a data model that technically works, but that nobody fully trusts.

What makes this especially risky in an AI context is that agents don't have judgment about data quality. They don't know that a table was created under deadline pressure and might not be the source of truth. They just query it.

Data governance used to be mostly about cleaning up messes after the fact. In the age of agentic AI, that's too late.

"You have to use data for AI, but you also need to use AI for data." 

Lau's proposal is to use the same agentic approach to fix the data foundation that teams are using to build AI features on top of it. This framework has three components and each one feeds the next:

Back to the jacket example. An agentic data modeling system would have flagged the problem before it became a shipment. It would have recognized that "Winter Collection" implies temperature-dependent attributes, scanned the product entity, found no temperature-related fields, and generated an alert (and a proposed fix) before any agent had the chance to act on incomplete data.

The human data engineer isn't gone in this framework. But they're freed from being the bottleneck that everything waits on.

"I like to think that the biggest driver can now go home earlier instead of doing weekend work." 

The goal isn't to remove humans from the loop, it's to make sure they're in the loop at the right moments, making judgment calls rather than just manually ferrying data between systems. And for teams already using Mixpanel MCP, this kind of structured, governed data layer is what makes those integrations actually reliable.

Getting the data foundation right solves the Miami jacket problem. It means your AI agents are working from accurate, well-structured, semantically rich data. It means fewer confident wrong answers.

But it doesn't tell you whether the AI features you've built are landing with users. That's a different question entirely, and it's one that traditional measurement frameworks often get wrong. The ultimate AI eval is your user. Whether they found the output useful, whether they came back, whether the feature changed how they work. That's behavioral signal, and it's what product analytics captures.

It's the right starting point. But for product teams, there's a second question that follows—once you've built something on that foundation, how do you know it's working?

AI-native product thinking requires more than having the right infrastructure. The feedback loop matters just as much that tells you when to iterate, what to improve, and when something that looks fine in the data is actually failing users in the product.

The companies moving fastest on AI didn't get there with better models. They got there because they treated their data foundation as a competitive advantage before AI made it urgent, not a cleanup task they'd get to eventually. That work is now table stakes, and as Lau made clear, it doesn't have to be entirely manual anymore.

A clean foundation gets you to the starting line. Whether your AI features are actually working is a different question, one your data warehouse can't answer. Behavioral signal tells you what the data can't, if users found it useful, came back, or walked away. That's where product analytics comes in.

Learn more about how Mixpanel AI helps you build and measure better products.