TLDR
Most B2B products answer their customers’ data questions with an embedded dashboard, and for the people who use your product every day, that remains the right surface. The agent era doesn’t change what dashboards are good at. It changes where analysis happens:
- Your customers are handing analysis to AI agents. On workflow triggers, monitoring loops, and ad-hoc questions, a growing share of the asking is done by software rather than by a person in your UI.
- Agents do that work in the data warehouse. An agent reads a schema, writes a SELECT, and has structured results seconds later. It can join your product’s data against everything else the customer keeps there. And warehouse-native agents like Snowflake Cortex and Databricks Genie run inside the customer’s data platform itself.
- The data agents can use is the data that’s synced in. Syncing your product’s data to the customer’s data warehouse is what lets customers run the analysis they need with your data in it. That’s the job of data exports.
The complete analytics story for the agent era has three surfaces: the dashboard for people in your product, an MCP server for lookups and actions, and data warehouse syncs for analysis. This guide is a framework for sequencing them.
What embedded analytics is for
In 2022 we published three questions to ask when specing a data product: Is your data useful independent of your product? Is the data consumer your product’s primary user? Are your customers SMBs or enterprises? The framework routed teams between in-product dashboards and data warehouse syncs, and it has held up well.
Embedded analytics wins when the consumer is a person inside your product: campaign performance for a marketer, delivery stats for an ops lead, usage curves for an admin. Glanceable answers with zero setup, right where the user already is. That job doesn’t go away.
The agent era adds a fourth question to the framework: who (or what) is consuming the data? A chart is a great answer for a person. An agent doesn’t consume charts; it queries tables. When the consumer is software, the question isn’t what to render. It’s where your data can be queried.
Agents do their analysis in the data warehouse
Three things make the warehouse the natural home for agent-driven analysis.
The query loop is what agents do well. An agent reads your schema, writes a SELECT, and gets structured results back in seconds. It can reach your data through your app instead, logging in and navigating the way a person would. But every hop adds latency and new ways to fail, and none of them are needed when the data is a table away.
The analysis customers care about spans systems. Churn risk joins your product’s usage data against billing and support tickets. Spend anomalies join your platform’s events against the finance system. The data warehouse is where the rest of the customer’s data already lives, so it’s the one place those joins happen.
Warehouse-native agents are on the rise. Snowflake Cortex, Databricks Genie, and their peers run inside the customer’s data platform itself, and the broader trend is steep: HUMAN Security measured agentic traffic growing over 7,800% year over year, and automated traffic passed human traffic on the web in 2026. The reach of a warehouse-native agent is exactly the set of tables synced into the platform. If your product’s data is there, it’s part of every analysis those agents run.
For why the data warehouse beats routing whole tables through an agent’s context window, see MCP vs. Data Exports: it has the token math and the spec details. The short version: one SQL query in the warehouse does in seconds, for fractions of a cent, what would take an agent dozens of paginated tool calls to approximate.
Where each surface fits
| Embedded dashboard | MCP server | Data warehouse sync (exports) | |
|---|---|---|---|
| Built for | People in your product | Agent lookups and actions | Analysis by agents, analysts, and BI |
| Access pattern | Rendered charts | Tool calls with small payloads | SQL over whole tables |
| Joins with the customer’s other data | No | No | Yes |
| Freshness | Whatever you compute | Live state | Synced, typically within minutes |
| Adding a new analysis | Your roadmap | Your roadmap (a new tool) | The customer writes a query |
The last row is where product teams feel the difference day to day. On the data warehouse surface, the customer’s next analysis doesn’t route through your backlog: they write it themselves, or their agent does, and your team ships nothing. Every “can you add a filter for this” ticket is a request that could have been a query.
What this means for your analytics roadmap
- Keep the dashboard focused on people. Serve the glanceable, universal KPIs that users check inside your product every day. That’s the job it’s best at, and nothing about agents changes it.
- Ship data warehouse syncs as your analysis surface. Custom-report requests, CSV exports, and API-scraping customers are all demand signals for the same thing: your data, queryable next to the rest of theirs. Data exports turn that demand into a product feature. They also make your product usable by the agents your customers already run.
- Ship an MCP server for lookups and actions. It covers the transactional half of agent-readiness: fetch a record, check a status, take an action. The routing rule and the cost math are in MCP vs. Data Exports.
- Treat warehouse-native delivery as the bar. Customer-built API pipelines and one-off CSV drops push the integration burden onto the customer. Warehouse-native means the sync is part of your product: self-serve setup, incremental transfers, schema evolution, observability. Which features that requires is its own guide.
For what the combined surface looks like as a product, see how Prequel makes products agent-ready.
FAQs
Do agents make embedded dashboards obsolete? No. Dashboards serve the people who work inside your product, and they’ll keep doing that well. Agents are an additional consumer with a different way of using data: they query it. The change is additive. Keep the dashboard for people, and give agents a queryable surface.
Isn’t an MCP server enough to make us agent-ready? It’s half the story. MCP is excellent for point lookups and actions, and you should ship one. Analysis is different: it scans tables, aggregates, and joins, and that work belongs in the customer’s data warehouse. The full argument is in MCP vs. Data Exports.
Do agents need real-time data? Rarely. Most analysis tolerates minutes of staleness, and incremental syncs every 15 minutes cover the rest. The questions that genuinely need live state are point lookups, and that’s what the MCP surface is for.
Our embedded-analytics vendor is adding AI features. Does that cover this? It helps the people in your product: natural-language chart building and automated insights make the dashboard easier to use, and that’s genuinely useful. What it can’t do is put your data where the customer’s own agents work, or next to the systems they join it against. Those need your data in their data warehouse.
