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.
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, and the data team’s job moves with it.
The numbers can stay governed. The reasons are where the new risk lives.
What the dashboard left to the reader
A platform is a cost until it changes a decision. A dashboard carries the number most of the way there 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, and why the questions they were not built for arrive in the chat window instead.
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
A briefing that states a likely cause and a proposed action attempts the step the dashboard left out. That is why business users want it, and it is why it has to be built with more care than the dashboard ever needed.
The reader now commissions the report
What changes is who authors the report, not only what it looks like. The platform publishes governed metrics, their definitions and a knowledge base of business context as tools an agent can call. A business user describes the report in plain language, and the agent assembles it on a schedule from those tools, then adds its reading of the result. Besides the interpretation, two things differ from BI.
The cut belongs to the reader. Dimensions are chosen when the question arises, not fixed when the dashboard was built. The analyst queue for “the same, but by region” empties for anything the governed layer supports.
The context is wider than the data. A briefing can draw on things no dashboard held: the chat thread where a lost deal was discussed, the meeting where a launch slipped, the email announcing a supplier’s delay.
The large BI vendors are moving the same way, which says the demand is real.
Keep the numbers in the platform, not in the prompt
The encouraging part is that the numbers can stay governed, and the unglamorous governed metrics matter more than they did. An agent computes whatever definition it finds. If the definition of net revenue lives in a semantic layer and reaches the agent through a tool, every briefing that mentions net revenue agrees on the number, 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; the agent chooses among metrics and dimensions and passes the filters. Grain, exclusions, freshness and the appropriate use of each measure travel with the result, as the guardrails for an assistant require. The 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.
This is the work I have found most worth the effort: hardening definitions inside the platform, writing the context agents need into a knowledge base they can read, and exposing both through the tools of an MCP server, so a business user’s agent inherits them without being told to.
Governance that lives in the tool is followed by default. Governance that lives in a guideline is followed by whoever read it.
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, the one saying it was generated by AI and should be verified, is 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, 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.
The first failure is sprawl. Briefings get copied and modified and rarely retired, and some keep running for people who have left the team. Dashboard rot becomes briefing rot, with a model bill attached.
The second is a fragmented picture. When every leader reads their own briefing, two briefings can agree on every number and still disagree about the reason, and the meeting becomes an argument about whose agent to believe.
Three controls cover most of it. A registry, as dull as a dashboard catalog: owner, audience, sources, schedule, cost and review date, with a briefing that has no owner switched off. Expiry by default, so a briefing earns its renewal. And a small set of shared briefings for the forums where decisions are made together, built on the same tools and reviewed by the data team, so the leadership meeting starts from one picture. Personal briefings go deeper from there; they do not replace it.
The richest context is also the easiest attack
The context that makes a briefing useful is also the most dangerous to connect.
The controls follow from that. Inherit the reader’s permissions, and check the audience at delivery: a briefing posted to a channel reaches everyone in it, including people who could not see its sources. Prefer curated sources to raw ones, a meeting summary its participants have seen or a channel set up for the purpose, rather than 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 rather than instructions, and design as though that will sometimes fail, so a successful injection has nowhere to send what it finds.
Then 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. Consent and retention are part of the design, not an afterthought.
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. 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.
Some errors get harder to see.
A wrong chart often looks wrong. A wrong paragraph reads well.
The pattern is familiar beyond reporting. Gartner predicts that over 40 percent of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls. That is an analyst forecast, not a measurement, but its three reasons 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 expectations, not observations, with the reasoning behind each.
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. Vendors that compete everywhere else are already working on one specification for it. The Open Semantic Interchange was launched by Snowflake, Salesforce, dbt Labs and others in September 2025, on the premise that “every tool interprets business metrics and metadata differently,” and published a first open specification in January 2026. 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 at scale.
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, not a technical one. Whose messages may feed whose report will be settled by legal and people teams as much as by the data team, because it is a question about colleagues rather than about data. The organizations that connect everything first will write that policy after an incident rather than before it.
Before a briefing leaves its author
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, and wherever it arrives, it starts from the same definitions and says which of its sentences are known.