The dashboard stopped one step short
A dashboard shows that a number moved and leaves the reason to the reader. Business users now schedule AI briefings that supply the reason and a next step. What that changes for governance, for BI, and for the data team.
For most of the history of business intelligence, the recurring report has had a fixed division of labor. The data team decides what the dashboard shows. The business reads the number. What the number means, why it moved and what to do about it is left to the reader, and any question the dashboard was not built to answer joins a queue for an analyst.
That division is coming apart from the business side. Once a data platform can be reached by an AI agent, through the Model Context Protocol or something like it, people who have never written a query are scheduling their own reports: the metrics they care about, cut by the dimensions they choose, delivered every morning, and followed by a paragraph no dashboard ever carried. What probably moved the number, and what might be done about it.
I saw it first in my own users. Most of the people reading the dashboards I was responsible for were already passing them to an AI assistant and asking for a summary. When I talked with them, I learned how: they exported the dashboard as a PDF and asked the model to explain it. The summaries read well. They lacked the context to explain why a number had changed, because a PDF of a chart doesn’t carry any. That is where I started thinking in terms of governed data and ungoverned insights.
So I took the project on myself. Each scheduled report began going out with a briefing built from the report and from a connection, through the platform’s MCP tools, to the governed source behind it, and both landed in the channel people subscribed to. It became popular, and it will keep changing as the technology and the demand do.
Executives have noticed. The version of the future I hear most often is governed data plus insight drawn from the numbers, the team’s conversations and the meeting notes. I think that is the right direction, and I have spent a good part of my recent work making a data platform ready for it. I also think it moves the hard problem rather than removing it.
The numbers can stay governed. The reasons are where the new risk lives.
What the dashboard left to the reader
A dashboard carries the number most of the way to a decision and stops. It shows that a metric moved and leaves the reader to work out why, whether it matters, and what to do. When the reader knows the business well and has the time, that works. Often neither is true, which is why so many dashboards are built, launched and ignored. The limitation was never the chart. It was that interpretation happened in the least structured part of the process: in the reader’s head, or in a meeting where whoever spoke first set the explanation.
- Number
- Reader’s guess
- Decision
- Governed number
- Labeled reason
- Owned proposal
What changes is who authors the report. A business user describes it in plain language, and an agent assembles it on a schedule from governed tools, then adds its reading of the result. The cut belongs to the reader now, and the context can be wider than the data: the thread where a lost deal was discussed, the meeting where a launch slipped.
By 2026 the large BI vendors were moving the same way. Tableau Pulse, generally available since early 2024, detects drivers and outliers in defined metrics and sends generated summaries to chat and email. Copilot in Power BI summarizes report pages inside scheduled subscriptions. Conversational analytics in Looker is grounded in Looker’s semantic model. The vendors agree the report will carry an interpretation. What is still open is who commissions it, and whether the definitions live inside each tool or in the platform underneath all of them.
Keep the numbers in the platform, not in the prompt
The encouraging part is that the governance of the numbers does not have to move. An agent computes whatever definition it finds. If net revenue lives in a semantic layer and reaches the agent as a tool, every briefing that mentions net revenue computes it the same way, whoever built it and however they asked. If the agent writes that calculation itself from raw tables, each briefing becomes its own definition, and the disagreement moves from the meeting into the reports.
So give agents metrics as tools, not tables. The tool computes the metric, and the agent chooses among metrics and dimensions and passes the filters. A knowledge base holds what a definition cannot: that a metric changed method in the spring, that one region reports a week late, which measure finance takes to the board.
A 2026 preprint by Michael Rumiantsau and Ivan Fokeev, on arXiv, tested three frontier models on a hundred retail-analytics questions, with and without a document describing the semantic layer, and found that grounding the models in it improved both accuracy and hallucination rates, and mattered more than which model was used. That matches the deployment I wrote up, where the failures that survived were mostly definitions not yet settled. Hardening definitions inside the platform, writing the context agents need into a knowledge base, and exposing both as tools on an MCP server is the work I have found most worth the effort, because a business user’s agent inherits all of it without being told to.
A governed number is not a governed reason
Govern the number and the failures move into the paragraph after it.
A correlation reported as a cause. Two series moved together last week, and the briefing says one drove the other. The prose is fluent, the claim is untested, and nothing in the format tells it apart from the measured number above it.
Evidence of different quality, blended. A governed metric, a remark in a chat thread and an action item from a meeting land in one confident paragraph. The reader cannot tell which sentence was measured and which is someone’s opinion, repeated.
An action with no owner. “Consider revisiting the pricing change” names no decision, no alternative and no condition, which is why human recommendations go nowhere too. An agent writes that sentence faster, and more often.
A warning that becomes wallpaper. The line at the bottom of every briefing saying it was generated by AI and should be verified gets read in the first week. Automation bias, the tendency to over-rely on automated advice, is one of the better-documented findings in decision-support research (Goddard, Roudsari and Wyatt, in the Journal of the American Medical Informatics Association, 2012). A standing caveat does not change behavior. The structure of the report can.
Label the evidence, not the report
The fix is not a louder warning. It is to make every sentence say what kind of evidence it is, so a reader can weigh it at a glance and an evaluator can check it. These are the labels I would require:
| Label | What it contains | What it must carry |
|---|---|---|
| Measured | A governed metric | Definition, period, filters and freshness, from the tool result |
| Observed | A pattern in governed data | The comparison that shows it: which cut, against which baseline |
| Reported | Something a person said or wrote | The source, its date, and who can see it |
| Inferred | The agent’s hypothesis about a cause | Its evidence, a confidence, and what would disprove it |
| Proposed | A possible action | An owner, an alternative, and the condition that would change it |
Net revenue fell 8% on last week, driven by the pricing change. Consider reverting it.
The cause is asserted, the action has no owner, and nothing says which part was measured.Measured: net revenue down 8% on last week, governed definition, as of 6 a.m.
Observed: the drop sits in the two repriced plans.
Reported: two renewals delayed, per the sales channel.
Inferred, moderate: the price change, unless the renewals explain most of it.
Proposed: the pricing lead decides by Friday whether to roll back for new customers.
The labels are also what make evaluation possible. A measured sentence can be checked mechanically against the tool result it cites. An inferred one can be sampled for review. A proposed one can be followed up: whether anyone acted, and whether the inference held.
Every user a report builder, again
Self-service BI produced the spreadmart: hundreds of private workbooks, each a local truth. Scheduled agents can produce the same thing faster, as a prompt instead of a workbook. Briefings get copied, modified and rarely retired, and two leaders can read briefings that agree on every number and disagree about the reason. Three controls cover most of it: a registry with an owner, audience, sources, schedule and cost for every briefing; expiry by default, so a briefing earns its renewal; and a small set of shared briefings for the forums where decisions are made together, so the leadership meeting starts from one picture.
The richest context is also the easiest attack
Simon Willison, writing on his blog in June 2025, named the combination of access to private data, exposure to untrusted content and the ability to communicate externally the “lethal trifecta”: if an agent combines the three, “an attacker can easily trick it into accessing your private data and sending it to that attacker,” and, he adds, “we still don’t know how to 100% reliably prevent this from happening.” A scheduled briefing that reads the warehouse, reads a shared channel or an inbox, and posts its summary to a channel has all three.
The controls follow. Inherit the reader’s permissions, and check the audience at delivery. Prefer curated sources, a meeting summary its participants have seen, to raw ones like a whole inbox. Limit where output can go: a briefing that can only be delivered to its owner cannot send anything to an attacker. Treat retrieved text as data, never as instructions, and design as though that will sometimes fail. And ask whose words these are. The colleague whose remark in a chat thread becomes a line in someone else’s weekly report never agreed to that.
What it costs
The data team’s work moves and gets less visible. Fewer dashboards ship. More effort goes into published definitions, a curated knowledge base, evaluated briefings and a maintained registry. That is harder to show in a headcount conversation, and it is the work that decides whether any of this can be trusted.
Compute becomes a per-reader cost. A briefing that queries the warehouse and calls a model every morning for hundreds of readers is a workload, and it grows with readers, schedules and context, so precomputed metric tools, caching and a budget per briefing belong in the design from the start, for the same reasons platform cost needs an owner.
And some errors get harder to see.
A wrong chart often looks wrong. A wrong paragraph reads well.
Gartner predicted in June 2025 that over 40 percent of agentic AI projects would be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Those are the three places this piece asks for design: what a briefing costs, which decision it informs, and what it can read and where it can send.
What I expect to happen to BI
These are my expectations, not observations.
The recurring management report becomes a briefing, and the dashboard keeps what it does well. Monitoring, a shared reference everyone can point at, audit and drill-down do not need prose. The weekly business review does, and it will increasingly arrive written.
Definitions move down into the platform, and BI becomes one client among several. When agents, notebooks and applications all need the same metric, a definition that lives inside one BI tool’s model is in the wrong place. The Open Semantic Interchange, launched in September 2025 by Snowflake, Salesforce, dbt Labs and others, set out to write a vendor-neutral specification for business metrics, dimensions and metadata, so that BI tools, catalogs and AI applications read the same definitions. I expect the semantic layer to become the most valuable governance asset a data team owns.
Evaluating insight becomes a discipline, the way testing pipelines did. Most teams evaluate the query today. The next thing to evaluate is the paragraph, and labeled sentences are what make that tractable.
The data team’s scorecard changes. Dashboards shipped and tickets closed stop describing the work. Definitions reused, briefings retired and decisions a briefing informed describe it better.
Access to conversation becomes a policy question. Whose messages may feed whose report will be settled by legal and people teams as much as by the data team. The organizations that connect everything first will write that policy after an incident rather than before it.
The dashboard stopped one step short and left the step between the number and the decision to the reader. The briefing takes that step, and it is the step that makes a platform worth paying for. The job, as I see it, is not to slow any of this down. It is to make sure that whoever builds the report, wherever it arrives, starts from the same definitions and says which of its sentences are known.