From Mihir Katiyar | Product & Market Analysis
Your Dashboard Is Dead: What Software Looks Like Without a UI
On this page
A dashboard exists because a person needs to look at data and decide something. If an agent reads the data and decides, the dashboard stops being a workspace and becomes an audit surface: the place you go to check what was already done. That is a smaller job than the one dashboards were built for, and product teams are only starting to design for it.
Key takeaways
- The dashboard's job was deciding, not displaying. Remove the human decision and the interface loses its purpose rather than its features.
- Approval flows replace exploration flows. The primary interaction becomes reviewing a proposed action rather than assembling a view.
- Reporting and dashboard products score high on absorption exposure. They transform and present information without owning it, which is what agents do natively.
- Auditability becomes the interface requirement. The most cited enterprise concern is agents acting without a readable record of what they did.
The claim, precisely
The argument is not that interfaces disappear. It is that the dominant interaction changes, and interfaces designed for the old interaction become badly fitted to the new one.
Concretely: an interface built for exploring data, filtering it and forming a judgement is optimised for a person doing analysis. An interface built for reviewing what an agent proposes, understanding why, and approving or rejecting it is a different product with different requirements.
Most software today is the first kind. The transition is not that screens vanish. It is that the screens people spend time in become approval queues rather than workspaces.
One observability vendor has already reported close to 20% of monthly interactive queries coming from agents rather than people, which is what this looks like early.
What dashboards were actually for
Three jobs, and only one of them survives.
Monitoring. Watching for a condition that requires attention. This job transfers cleanly to an agent, which does it better because it never stops watching and does not need the data pre-arranged.
Exploration. Forming a hypothesis and interrogating data to test it. This partly survives, because human curiosity is not a defined query, though the interaction increasingly becomes conversational rather than visual.
Justification. Producing evidence for a decision already made, to a colleague, an auditor or a regulator. This job grows rather than shrinks, because more decisions made by more actors means more evidence required.
The category exposure follows directly. Reporting and dashboard products score high on absorption risk precisely because two of their three jobs move elsewhere, a pattern set out in the analysis of category absorption.
Why the third job grows
This is the counterintuitive part and it is worth dwelling on. Automation does not reduce the demand for evidence. It increases it.
When a person made a decision, the evidence was that a qualified person made it. When software makes the decision, that assurance disappears and something has to replace it, which means a record showing what happened and why.
More decisions, made faster, by actors that cannot be questioned afterwards, produces strictly more demand for reconstruction. That is why audit surfaces are the one interface category where demand is rising.
What replaces them
The replacement pattern has three parts. A notification layer that surfaces only what needs a decision. An approval surface showing what is proposed, what changes, and the reasoning behind it. And an audit surface where anyone can reconstruct what happened afterwards.
None of that is a dashboard. All of it uses the same underlying data, which is why the system of record beneath survives while the presentation layer above it does not.
Approval is the new interface, and it is badly designed
The hardest problem in this transition is not building approval flows. It is that approval flows fail in a specific and predictable way.
A person asked to approve fifty agent actions a day will approve them. Not because they checked, but because the fiftieth looks like the first forty-nine and nothing has gone wrong yet.
That produces the worst possible outcome: an oversight mechanism that satisfies the governance requirement and catches nothing. It is worse than no approval step, because it creates documented false assurance.
The design responses that work all reduce volume rather than improve the interface. Approve policies rather than instances. Escalate only outside defined bounds. Sample rather than review everything. Each of those is an admission that human review does not scale, which is uncomfortable and true.
What this means for product teams
Four practical shifts.
Design for the reader who was not present. The most important user of an agent interface is the person reconstructing a decision three months later, not the person approving it today.
Make reasoning visible, not just outcomes. An approval showing what will change is insufficient. It must show why, in terms the approver can evaluate without redoing the work.
Treat notification design as core product. When the primary interaction moves out of your application, what you send and how often becomes the product experience.
Build the audit surface first. It is the part regulated buyers evaluate, the part that is hardest to retrofit, and the part almost nobody builds until required to.
Why reasoning is harder to show than outcomes
Displaying what will change is straightforward. Displaying why is not, because the reasoning is usually long, technical and boring, and users skim it entirely.
The interfaces that work compress reasoning to the single factor that determined the decision, with the full trace available for anyone who wants it. That requires knowing which factor was decisive, which is a genuinely hard technical problem and not a design one.
Four design shifts, in order of difficulty
| Shift | Why it is hard | What good looks like |
|---|---|---|
| Design for the absent reader | Requires imagining a user who is not in the room | A record someone can follow with no prior context |
| Show reasoning, not just outcomes | Reasoning is verbose and users skim | The one factor that determined the decision, prominently |
| Treat notifications as core product | Nobody staffs notification design | Fewer, better-timed, each requiring a decision |
| Build the audit surface first | No customer asks for it during a sales process | Complete before the first regulated deal, not after |
The last row is where most teams get caught. Audit surfaces are never the reason a deal is won and are frequently the reason one is lost, which makes them chronically under-prioritised.
What the transition gets wrong
Two errors are common and both are expensive.
The first is removing the interface entirely and calling it progress. A system that acts without any surface for understanding what it did is not post-UI, it is unauditable, and it will fail its first compliance review.
The second is keeping the dashboard and adding a chat box. That produces two interfaces neither of which is designed for the actual job, and it is the most common thing shipping in this category right now.
The harder work is deciding which decisions genuinely transfer to the agent and building the surfaces for those specifically. That requires knowing which decisions in your product actually matter, which many teams have never had to articulate.
Who this affects first
Not evenly, and the sequence is predictable from the three-jobs analysis.
The sequence
Products whose primary value is monitoring go first, because that job transfers cleanly and completely. Anything that exists to tell a person when a threshold was crossed is competing with something that never stops watching.
Products whose value is exploration go slowly, because human curiosity does not reduce to a defined query and people genuinely enjoy looking at their data.
Products whose value is evidence and justification grow, because the number of actors making decisions is increasing and every one of them creates something that needs explaining afterwards.
If your product does all three, the useful exercise is working out what share of usage each represents. Most teams have never measured it and are surprised by the answer.
Where this argument is weak
Three honest problems.
The evidence is thin and mostly directional. One vendor reporting a share of agent queries is a data point, not a trend, and no broad measurement of how interface usage is shifting has been published.
The argument also assumes agents become trustworthy enough that people stop checking. Current evidence points the other way, with developer trust in AI output falling even as usage rises, which would keep humans in the interface for considerably longer than this framing suggests.
And dashboards have been declared dead several times, by conversational interfaces, by mobile and by alerting. They survived each time, because looking at a picture of your data turns out to be something people want to do independently of whether a machine could do it for them.
Frequently asked questions
Are dashboards becoming obsolete?
Not obsolete, but repurposed. Dashboards did three jobs: monitoring, exploration and justification. Monitoring transfers cleanly to agents that never stop watching. Exploration partly survives, increasingly as conversation rather than visualisation. Justification grows, because more decisions by more actors means more evidence required. Two of three jobs move, which is why reporting products score high on absorption exposure.
What replaces the dashboard in agent-driven software?
Three surfaces rather than one. A notification layer that surfaces only what needs a decision, an approval surface showing what is proposed and the reasoning behind it, and an audit surface where anyone can reconstruct what happened afterwards. All three use the same underlying data, which is why systems of record survive while presentation layers do not.
Why do agent approval flows fail?
Because a person asked to approve fifty actions a day approves them, not from checking but because the fiftieth looks like the previous forty-nine. That produces documented false assurance, which is worse than no oversight. The responses that work reduce volume rather than improve the interface: approve policies rather than instances, escalate outside defined bounds, and sample rather than review everything.
What should product teams build first for agent interfaces?
The audit surface. It is what regulated buyers evaluate, the hardest thing to retrofit, and the part almost nobody builds until required to. The most important user of an agent interface is not the person approving today but the person reconstructing a decision three months later, and designing for them first produces better approval surfaces too.
Is adding a chat box to a dashboard the right approach?
It is the most common approach and one of the two main errors. It produces two interfaces, neither designed for the actual job. The other error is removing the interface entirely, which produces a system nobody can audit. The harder work is deciding which specific decisions transfer to the agent and building surfaces for those.
Has anyone actually measured this shift?
Barely. One observability vendor reported that close to 20% of its monthly interactive queries came from agents rather than people, which is a data point rather than a trend. No broad measurement of shifting interface usage has been published, and dashboards have been declared obsolete several times before by conversational interfaces, mobile and alerting.
Where to start this week
Take one screen in your product that people use daily and ask what decision it exists to support.
If you can name the decision, ask whether an agent could make it correctly ninety percent of the time. If the answer is yes, that screen is going to become an approval queue, and designing for that deliberately beats having it happen badly.
If you cannot name the decision the screen supports, you have found something more useful. A screen that supports no decision is a screen nobody will miss, whether or not agents arrive.
Do this for your five most-used screens and the pattern usually resolves quickly. One or two support real decisions and deserve investment as approval surfaces. The rest are habit, and habit is not a moat.
References
- Gartner projection via Deloitte, 2025, on point-product SaaS absorption into agent ecosystems by 2030.
- Model Context Protocol blog, The 2026-07-28 specification, July 2026. Used for the agent query share reported by Honeycomb.
- Synvestable, Model Context Protocol for enterprise: 2026 deployment guide, May 2026. Used for the visibility gap as the most cited enterprise concern.
- Coderio, Mastering AI integration: Model Context Protocol, April 2026. Used for the MuleSoft integration research.
The evidence for this shift is thin and directional. One vendor's reported share of agent queries is a data point rather than a measured trend, and no broad study of changing interface usage has been published.
Related reading