A traditional dashboard is a wine list.
It has structure, categories, labels, regions, vintages, prices. Everything the restaurant has is organized, accurate, and technically available to you. If you already know wine, that might be enough. You can scan the Burgundies and know exactly what you are getting into.
But most people are not sitting down with that kind of context. They are trying to make a good choice with partial knowledge, competing priorities, and a room full of other things demanding attention. The list may be correct, but correctness is not the same as guidance.
Then the sommelier walks over.
They are looking at the same list you are. Nothing about the underlying inventory has changed. But now the information has a point of view. The vineyard matters because of the dish you ordered. The vintage matters because of what happened that year. The pairing matters because it turns a long list of possible choices into one confident next step.
That is the difference between metrics and insight.
For twenty years, we have handed stakeholders wine lists and called it business intelligence. We organized the information beautifully. We made it filterable, sortable, exportable, and visually clean. Then we left the meaning as an exercise for the reader.
BI tools organized the information. AI-native apps explain why it matters.
That sentence is the whole post. The rest is the story of why the explaining — the part that was always too hard, too manual, and too easy to skip — just became the part you can actually ship.
Back of House: The Work Nobody Tastes
The traditional data stack is mostly back-of-house work: pipelines, warehousing, governance, modeling. Even in an open kitchen, the deliveries, prep, cleanup, and coordination usually happen out of view. Essential work, but rarely what the diner compliments.
Stakeholders eat at the table. They experience data only when it becomes a course they can taste, which means the only thing that ultimately counts is the insight.
I have written before that insights, not infrastructure, are the true goal of data work. Moving data into a warehouse is valuable, but nobody can use a warehouse by itself. They can only use what comes out of it. If the work never turns into a decision, it stays invisible — to the business, and eventually to the budget.
And yet most of what we ship stops one course short.
Pull up almost any support dashboard and you will see the same five tiles: total tickets, tickets by category, average resolution time, open versus closed, tickets by priority.
I built one for this post. It is live below — not a screenshot. The data is synthetic, a fictional B2B SaaS company, but the dashboard is the real pattern, the one we have all shipped:
The dashboard is accurate and complete. It even does the classic upgrade: every tile compares itself to the thirty days before it.
And the arrows are turning red. The backlog is up 207%. We are opening more tickets than we close, week after week. Resolution times are drifting up. SLA compliance is slipping. CSAT is sagging.
So this dashboard is not even silent. It is alarmed. It still cannot tell you why.
Look closer and it gets worse. Ticket volume is up just two percent — basically flat. A growing backlog against flat volume reads, to every level-1 instinct, like a staffing problem. The team is slow, so hire more agents.
Somewhere underneath those tiles, a new API and webhook feature is quietly breaking custom sync workflows for the enterprise tier. The dashboard's best guess points at the support team instead.
Can you see the release?
I cannot. And I am the one who planted it there.
This is the level-1 trap. Displaying data is not interpreting it. The wine list shows you everything, alarms you about some of it, and explains none of it.
The jump from level 1 to level 2 is not "add a better chart." It is "add the missing sentence."
A level-1 metric says: backlog is up 207%.
A level-2 metric says: backlog is up 207% while ticket volume is only up 2%, which means the queue is not flooded; it is jammed. The jam begins after an API/webhook release, concentrates in enterprise integration tickets, and points to a product compatibility fix before support hiring.
That is the difference. Level 1 shows the ingredient. Level 2 explains the dish.
So when I look at a chart now, I ask a second set of questions before I admire the design. Does it have context wrapped around it? Compared with what? Good or bad against which baseline? Normal or unusual for this customer segment? Better or worse than last week, last month, the target, or the pre-release period? Is the headline number hiding a concentration underneath it? Did a product change, customer cohort, time window, or category explain the movement?
If the metric cannot change a decision, say so. If it needs another comparison to matter, name the comparison. But do not stop at "tickets by category" or "revenue by month." A bar chart is not an insight. A KPI card is not an insight. They become useful only when someone can tell you what changed, why it matters, and what to do next.
We ended up here for two honest reasons.
First, data teams often do not know the dish. Data engineers are tasked with moving data, not understanding it. We can tell you the table is fresh and the rows are deduplicated. We often cannot tell you what the numbers mean to the business, because nobody ever told us.
Second, we often do not know the palate. A good story needs the KPIs that matter, and sometimes the stakeholders do not know them either. The requirement arrives as "show tickets by category."
So that is what gets built.
And the story — the actual deliverable — became extra credit. Not because nobody wanted it, but because nobody had the staff for it.
The Sommelier Walks In
Here is what a good sommelier can do that still amazes me: they can pick up a bottle they have never tasted and tell you what is inside. Grape, region, producer, vintage. From the label alone, they can sketch the wine — the acidity, the weight, what it will do with food.
That is not magic. It is pattern recognition over ten thousand bottles.
It is also close to what a modern model does with a dataset it has never seen.
That is why the support example above is more interesting than it looks. On the surface, the ingredients are ordinary: ticket categories, SLA status, account tier, usage events, release notes, revenue. None of them is exotic. But the useful answer is not sitting inside any one table. It lives in the relationship between a flat ticket count, a swelling backlog, enterprise integration issues, webhook failures, and a recent API release.
That is exactly the kind of cold read models are getting good at. The model can read the columns and a sample of rows the way a sommelier reads a label. It recognizes the cuisine. It proposes the metrics that matter. It frames the story — not "support is overwhelmed," but "a product change created an integration jam for high-value accounts" — and the analyst spends time steering and validating instead of starting from zero.
That is the label-reading skill. The second skill matters more: the pairing.
A sommelier's real trick was never describing the bottle. It is knowing the Barolo goes with the braise. Knowing what goes with what.
Your warehouse is a full cellar attached to a busy kitchen. Every domain in the company is piled into one place. Support tickets sit next to product usage, next to releases, next to revenue. The whole point of centralizing the data was that these things could be connected.
But the connecting never came free. Cross-source correlation is where the insight lives, and it is exactly what a static dashboard struggles to surface. The dashboard shows you the cellar one shelf at a time, which means the source where the cause lives often sits just outside the frame.
So let us go back to my planted dashboard.
This time, we skip the tiles. We also skip the export ritual. The agent can pull the same operating context directly: support tickets from Zendesk, product usage and webhook events from the app database, release history from Git, and account context from Salesforce. Then we give it a support-leadership brief instead of a blank "look at this data" prompt:
No hand-built extract. No prewritten finding. No hint about May. The agent still has to inspect the data, compare baselines, find the concentration, and connect the support symptom back to the product event.
Here is the story buried across those systems, the one the wine list could not tell:
Backlog is up 207% while ticket volume is only up 2%, so the queue is not flooded; it is jammed. Enterprise integration tickets increased 48% after the May 6 API v2/webhook release, take 2.3x longer to resolve than other categories, and now drive 62% of breached SLAs. The likely action is to prioritize webhook and custom-mapping defects before adding more support staffing.
That paragraph does two things the dashboard could not. It explains the operational symptom, and it connects support pain to a product change. Then the pairing makes it sharper: the same accounts filing those integration tickets are seeing webhook failures spike and are going quiet in the product. Eighteen enterprise accounts. $105,790 in monthly revenue. Usage still about 10% below baseline after the hotfix.
A support metric just became a revenue risk.
And the backlog from the wine list finally makes sense. The queue is not flooded — volume barely moved. It is jammed. Integration defects pend on engineering and partner-API debugging, and they take 2.3x longer when they do close, so opened keeps outrunning closed. More agents would not fix a jam.
Shipping the fix will.
Here is the same data, served as a story instead of a list:
Same ingredients. Different deliverable. One of them ends in a decision.
To be clear about what this is: extra help, not a replacement. The kitchen still matters. The storytelling layer is only as good as the data underneath it. What is new is that the role your team could never hire for — the one that turns organized information into why it matters — now shows up on demand.
From Printed Menus to Table Service
Strip the branding off a BI dashboard and what you are looking at is a narrow, hosted web app for reports.
That was a real breakthrough. BI tools solved two problems data teams badly needed solved: deployment and access. You could build a report, publish it to the web, put permissions around it, and give business users a link instead of a spreadsheet attachment.
For their time, they made data feel like software without asking every analyst to become a front-end engineer.
But the trade was control. A BI report is still a thin application inside someone else's frame: a canvas, a tab strip, a filter pane, a model editor, a publish button, and a set of interactions the vendor decided should exist. It can be powerful, but it is also manual. You shape the experience by clicking through a UI.
That bargain made sense when custom web apps were expensive. Making the custom dish took too much effort, so everyone ordered from the printed menu.
That constraint is collapsing. If modern hosting gives you a link you can update, and agent-generated code can turn an idea into a working interface quickly, the custom dish is no longer a special occasion. It is cheap enough to make on purpose.
And once the deliverable is a real app, you get the rest of the web back. You can design the workflow instead of filling a canvas. You can hide detail until it matters instead of building a giant table of contents. You can compose the experience from reusable modules, use modern interaction patterns, write tests, track changes in Git, and let agents inspect and modify the same code humans review.
That is the difference between a fancy PowerPoint with queries and a product surface.
A year ago I argued that the next-gen BI tool would be a kit — that AI plus modular tooling would let data engineers assemble their own reporting layer instead of renting a rigid one.
The argument has not changed. The distance has. The path from idea to working full-stack app has compressed to almost nothing, and the biggest platforms in data noticed.
On June 2, OpenAI shipped Sites. You describe a dashboard, a tracker, or a scenario planner in plain language, and Codex builds it, deploys it, and hands back a shareable URL with real persistent state.
Microsoft is turning Fabric into an app platform. At Build 2026, the pitch was agentic apps running directly on the warehouse — and they bought Osmos to automate the data engineering in the middle.
Databricks ships Databricks Apps. Full-stack apps in Streamlit, Dash, or React, running serverless on governed lakehouse data, with no infrastructure to stand up.
Three of the biggest platforms in data looked at the deliverable and reached the same conclusion: it is an app written in code, not a dashboard clicked together.
The restaurant is going menu-less: omakase. No fixed list, just the kitchen serving course by course, narrating as it goes, and adjusting to how you respond. That is what conversational, app-native analytics actually is — and it is why the printed menu suddenly looks like an artifact.
The incumbents see it too. Power BI Copilot and Tableau Pulse are real, and they are improving: natural-language summaries, anomaly alerts, generated reports.
But notice the shape of the move. A menu that describes itself is still a menu. It is AI bolted onto a licensed UI, recreating features the open web already has, inside the cage. The bet is that the UI layer stays the product.
Everything above suggests it will not.
The market has started saying this part out loud. In early February, roughly $285 billion came off software stocks in 48 hours — the selloff that got nicknamed the SaaSpocalypse. JP Morgan called the broader slide the largest non-recessionary software repricing in three decades.
Then software rallied 21% in May. The market is not torching the category; it is sorting it.
And the software getting repriced hardest is exactly the kind I wrote about heading into this year: lightweight, UI-heavy tools that mostly mediate between a user and structured data.
That is a printed-menu business in an omakase world.
The Kitchen-to-Table Distance Is Collapsing
Underneath both of these shifts — AI as the storyteller, apps over dashboards — is one cause: the distance from raw data to served insight is collapsing.
Exploratory analysis plus a working dashboard used to be a sprint. Now it is an afternoon. The steps of the stack — explore, model, build, publish — fold into one motion: get to the app that tells the story.
I made this case in relay terms last month: agents do not just make the runners faster, they shorten the track. The old BI workflow was another handoff: data team prepares the ingredients, report builder arranges the menu, stakeholder tries to infer the meal. Apps shorten that exchange. The same system can investigate, build, explain, publish, and then keep changing as the question changes.
It also explains why the BI tool's UI is aging so fast. That UI existed to dodge effort that used to be expensive: front-end code, hosting, auth, charting. The drag-and-drop layer was a workaround for the cost of building, and for a long time it was a good one.
But the cost it was working around is gone. Once making a chart in code is a sentence, having to click through a UI to make one starts to feel strange.
The barrier did not move.
It disappeared.
And the role changes with it. The data team is not locked in the kitchen anymore — it is moving into the control room. The dining room is part of the job now.
Running the Room
What I would actually do with this, starting now:
First, measure decisions enabled, not pipelines shipped. If the quarter's proudest artifact is invisible to stakeholders, the quarter was invisible too.
Second, practice driving the model toward the story. Hand it your schema and ask what matters. Ask what pairs with what. Ask what a VP should do about it. The skill is closer to editing than engineering, and a week of honest reps will teach you more than a quarter of reading about it.
Third, build the next deliverable as an app, not a dashboard. Pick one report people squint at and replace it with a small coded app that leads with the narrative and shows the evidence underneath it.
And yes, keep a few wine lists. There is a small set of numbers so important they need to be locked down, versioned, and identical for everyone who looks at them. That is the niche dashboards keep. It is a real niche. It is just much smaller than the industry built for it.
One caveat, because it is the failure mode that matters.
Beware the sommelier who invents the vineyard.
A confident story that is not in the data is worse than no story at all. Ground every narrative sentence in a query you can re-run. In my demo, every number on the storytelling page is computed from the same files the mute dashboard uses.
That is the standard. The sommelier does not get to freestyle.
Final Thoughts: Stop Printing Menus
Stakeholders were never hungry for menus.
They sat down, we handed them a beautifully organized list, and we wondered why they did not order more.
The kitchen still matters. The cellar still matters. Someone has to source the ingredients, keep the data clean, and know what is actually in the bottle. If anything, the storytelling layer raises the stakes on getting that part right.
But the deliverable was never the list. It was the meal, and the story that came with it. And for the first time, telling that story does not require staff we do not have.
The list is table stakes.
The service is the product.
Stop printing menus. Start working the room.