Data Platforms After the Dashboard

Watch what people do with a dashboard and a pattern shows up quickly. They open it, read one number (last week's revenue, the open-tickets count, yesterday's signups) and close the tab. The forty other charts on the page go unread. The dashboard did its job, which was to carry a single figure to a single person at a single moment, and the apparatus around that figure was scaffolding nobody asked to look at.

So here is where this goes. If an agent can assemble the three numbers someone needs, in the shape they need them, and discard the view afterwards, then the curated dashboard loses its monopoly on being the front door to enterprise data. The durable worth of a data platform moves down the stack: to the model, the metric definitions, the services and APIs, and the governance every interface has to sit on top of. The dashboard stops being the thing you buy a platform for, and the platform gets measured by what it can answer rather than what it can display.

In this article. What a dashboard is underneath the charts, what changes when an agent assembles the view per question, what stubbornly does not change, and what a platform is left selling once the picture is cheap.

• What a dashboard is underneath: a frozen set of decisions, useful because someone made them once.
• When the view is generated per question: where that is better, and where it is worse.
• What the agent still can't skip: the decisions move down the stack; they don't disappear.
• So what does a platform sell? Models, governed metrics, APIs, and the components an agent shouldn't reinvent.
• The promise that failed the people it was for: the self-service pitch of the 2010s, and why generated interfaces can repeat it faster.

The headline overstates it on purpose. Dashboards do not die. A fixed dashboard is worth building whenever you are tracking the same KPI over time, watching a metric you check every morning, or producing the same prebaked table for a regulator who expects it to look identical each quarter. For those, deciding the layout once and reusing it is exactly right; regenerating it from scratch on every visit would be waste. What shrinks is the hand-built one-off: the bespoke sheet someone commissions for a single analysis they need once and very possibly never again. That is the work an agent absorbs well, and it is a surprisingly large share of what BI teams spend their weeks on.

What a dashboard is underneath

Strip the charts away and a dashboard is a set of decisions someone froze in place. What is the grain? Is one row a transaction, a day, a customer-month? Which filters are always applied, and which ones excluded the test accounts and the migrated region before anyone saw a total? What does "active customer" mean here, and is it the same definition the churn report uses? Which slice of time, on whose fiscal calendar? The layout is the last decision, and the least interesting one.

The reason a dashboard is useful is precisely that those decisions were made once and everyone reuses them. Two people looking at the same revenue tile are, by construction, looking at the same definition of revenue. That shared reference point is most of the value. It is also the part that has nothing to do with the picture.

When the view is generated per question

The alternative is now real, not a roadmap promise. Ask a question in natural language and a system generates the query, runs it, and hands back a chart and a short explanation. Snowflake's Cortex Analyst turns a question into SQL against a semantic model and returns the result ^[R1]. Databricks Genie does the same over data governed by Unity Catalog ^[R2]. Qlik made its agentic experience generally available in February 2026 (Qlik Answers as the natural-language front, a Discovery Agent watching metrics for anomalies, and curated Data Products underneath), so that a question becomes a chart and a next step inside a governed conversation ^[R3].

This is where a generated view earns its place. The one-off question, the cut nobody will ask for twice, the "can you just show me X by Y for the Nordics" that used to mean a ticket and a two-day wait. That is exactly where a generated view shines, because the cost of building it dropped to the cost of asking.

It is worse, and I think this is underweighted in the excitement, anywhere the answer needs to be the same for two people. A generated view is assembled fresh each time. Two analysts asking the same question slightly differently can get two defensible-but-different numbers, and neither of them can see that the other got something else. For a shared reference point, a regulatory submission, or anything where the figure has to be identical and durable, the fixed artefact is not a legacy inconvenience. It is the point.

The vendors building generated views have noticed. MotherDuck shipped a feature it calls Dives: you ask an agent (Claude, in the example its own docs use) a question through its MCP server, it queries the warehouse and assembles an interactive chart, and you can save that chart as a live object that re-queries the data every time someone opens it ^[R4]. Similar offerings are starting to appear across the category. What I find telling is why Dives exist at all. MotherDuck's own write-up describes a colleague who built an AI-generated leaderboard that froze on the day she made it and was useless the next morning; making the view persistent and live was the fix. Which is the fixed dashboard coming back in a new shape, the moment a question turns out to be worth asking twice.

generated views are best where the answer is disposable and worst where it has to be shared. The era of building bespoke sheets for one-off questions is ending; the era of agreed, repeatable reference numbers is not.

What the agent still can't skip

Here is the part that survives the shift, and it is the whole argument compressed into one observation. An agent generating a view needs the same grain, the same filters, and the same definitions a dashboard builder needed. It does not get to skip them. When a person asked "show me revenue," a competent analyst silently resolved which revenue, net of what, on which calendar, excluding which accounts. The agent has to resolve the same things. It just resolves them from whatever you wrote down, or invents them when you wrote nothing. The decisions do not vanish. They move from the BI layer down into the model and the semantic layer.

the work didn't disappear, it relocated. Every decision a dashboard used to encode (grain, filters, definitions) now has to live somewhere the agent can read it. That somewhere is the model, not the prompt.

This is why the platforms converge on the same shape underneath. Cortex Analyst's accuracy depends on a semantic model (increasingly a Semantic View stored inside Snowflake) that maps business terms to the schema, so "net revenue" and "previous calendar month" mean one thing every time ^[R1]. Genie leans on Unity Catalog for the same reason ^[R2]. Qlik's positioning in 2026 reads less as a chat box bolted onto BI and more as governed, explainable reasoning that keeps permissions intact. The chat box is the demo; the meaning layer is the product.

_{The model used to feed one consumer: the BI layer. It now feeds several, and the dashboard is one of them. Author's illustration.}

I have argued the model side of this at length elsewhere and won't repeat the mechanics here.

So what does a platform sell?

Once the dashboard is one renderer among several, the platform's worth is whatever sits below all of them: a model that is correct, metric definitions that hold, services and APIs that return a trustworthy answer, lineage you can follow when someone disputes a figure, and permissions that apply whether the consumer is a person, a chart, or an agent. That last clause is doing real work. The recent moves are all about making the governed answer callable from outside the vendor's own screen. Genie ships a managed MCP server (beta) so any agent can ask its governed data a question and get a grounded answer back ^[R2]. Cortex Analyst is API-first: embeddable in a custom app, in Slack, in whatever surface you like ^[R1]. The permission model travels with the call; it is not reapplied at the UI.

Qlik's MCP server is worth dwelling on, because it shows how wide that opening goes ^[R3]. From outside the platform an assistant can browse the tenant and list the apps and datasets, open an app to read its sheets, fields, and the governed master measures and dimensions, and pull a chart's data straight back into the conversation. It can run a throwaway calculation as a temporary session object when the question is one-off, or go the other way and build something permanent (drop a new chart or a filter pane into an existing app for whoever opens it next) with glossary links, lineage, and data-quality checks reachable alongside. Two things hold throughout. The Qlik engine does the calculation, so the figure comes from the governed model rather than the assistant's own arithmetic; and the tools reach for the curated master items before raw fields. Or ignore the platform's visuals altogether: pull the data out and let Claude or another assistant do the ad-hoc analysis in-client. The catalogue, the definitions, and the permissions travel with it. The interface is the variable; the governed answer is not.

There is a counterweight I don't want to lose, because it is easy to over-rotate into "the platform is just an API now." The front-end building blocks still matter, and they matter more than the API-maximalists admit. If every generated view starts from nothing, you get an organisation full of charts that each invented their own colours, their own number formatting, their own idea of what a good comparison looks like. A platform that ships a validated set of visualisation components, a catalog, orchestration, and access control gives the agent something to assemble from, so it isn't reinventing analytics and data presentation on every request, and so the result keeps a consistent look and a consistent feel. The agent should be choosing among trustworthy parts, not improvising the parts.

For buyers

stop scoring platforms on dashboard polish. Score them on whether the model, the metric definitions, and the access layer are good enough to serve any front end you bolt on later, and whether they hand the agent good building blocks instead of a blank canvas.

I worked through the same shift for workplace software more broadly: the move from paying for interfaces to paying for validated models and APIs that something else calls into:

The promise that failed the people it was for

We have been here before. The self-service BI pitch of the 2010s said: give every analyst the tools and they will answer their own questions. What a lot of organisations got instead was nine definitions of revenue, one per analyst, each defensible in isolation and none reconcilable with the others. The tooling worked. The shared meaning underneath it didn't exist, so everyone built their own.

Looking back, I think we were too optimistic about self-service the whole way through, and I count those of us who built the solutions in that. The category error sat at the centre of it: self-service for a data professional is not the same thing as self-service for a business user. A data professional will happily root around in a schema, guess which cryptic column maps to the thing they want, and check their working. A casual business user has neither the time nor the inclination, and shouldn't need either. So in practice a great deal of that self-service capability simply went untouched. Some people never needed it: whatever they relied on was already built for them, and they were right not to bother. Others tried it once or twice, didn't get far, and quietly gave up. Handing someone a tool and calling the job done was, often enough, a way of moving the work onto the person least equipped to do it.

An agent that invents a definition per question is the nine-revenues problem at machine speed.

Generated interfaces can repeat exactly this failure, only faster, unless the definitions sit underneath. But the same shift contains the fix. If the meaning lives in the model (defined once, governed, and read by whatever asks) then the casual user finally gets self-service that works, because the hard part was done for them before they asked. Done well, this is what the 2010s promised and didn't deliver: analytics that reach people who were never going to learn the schema.

That is also where the work goes for those of us who built dashboards for a living. Less time assembling bespoke screens; more time on quality, documentation, and semantics: the unglamorous layer that decides whether any of the new interfaces can be trusted. It is a better use of the hours than hand-building a sheet someone opens once.

The picture was never the product

The dashboard becomes one renderer among several: the right one for recurring reference, the wrong one for the long tail, and no longer the only door in. What a platform was selling was never the picture. It was the trustworthy answer behind the picture, and that job gets larger, not smaller, when the answer has to hold up whether a person, a chart, or an agent is the one asking.

I am not certain where the boundary finally settles between the warehouse, the semantic layer, and whatever we end up calling the governed surface an agent calls into. That line is moving and I won't pretend to know its resting place. What I am fairly sure of is which way the value is flowing: away from the screen, down toward the model and the definitions and the permissions. Buy on that, not on the demo.

_{Data Platforms After the Dashboard · June 2026 · A strategy piece. Product capabilities are vendor disclosures and contemporaneous reporting; the read on where platform value is heading is my own. Full source records are in the References section above.}