Sometime in Q1 of 2026, a few months after ServiceNow rolled out Claude Enterprise accounts to the entire company, someone on our team tried to make a list.
The list was supposed to be simple: which internal dashboards existed, who owned each one, and which teams were actually using them.
The request was reasonable. The Data and Analytics organization which we were nested under had maintained a tight, well-governed list of dashboards, owners, and usage analytics for years. As the Enterprise AI team, we were the team most likely to be asked why any of this had happened, and it seemed prudent to know the answer before the question arrived. So, the request landed on our desk.
The attempt lasted about a week and got nowhere. We quickly realized that this wasn’t a question easily answered with a data-driven or technical approach.
Every dashboard lived at its own unguessable URL, the kind an AI tool generates when you ask it to build a shareable artifact. There was no index. Dashboards surfaced in Teams threads, in meeting invites, in the Claude account of whoever had built them. Ask a division which reports it ran on and the honest answer was that it depended on who you asked and which week. The list stopped at over 200 entries before the person doing it went back to their actual job.
Now, as far as I know, nothing broke as those dashboards rapidly proliferated across the company. The company kept reporting numbers, as it had before, faster than before. The only thing that had changed was that no one could say what the company was reporting to itself, or where any of it came from.
Andrew Chen published a piece on September 8, 2026, called The coming product retention crisis, and his argument was about consumer apps: when an app takes about as long to build as a video takes to edit, apps start behaving like content. A spike, a decay, on to the next one.
Average retention collapses, and the organizations that survive it will need, in his phrase, “really, really good people stitching it together.”
He was writing about products that ship to strangers. I read it thinking about the dashboards, because the same economics had already arrived inside a corporate firewall. The big difference is that this wasn’t people vibe coding a consumer app on the weekend. These were dashboards producing numbers that could find their way to the CFO and beyond.
Two Costs
Every reporting view has two costs, and most companies usually only prices one of them.
The first is the cost to build the view: get the data, curate it, put it in a chart, make it presentable. For most of the history of business reporting this cost was high enough to act as a filter. A dashboard took a data team weeks, a request form, and an architecture review board approval. So the dashboards that existed were the ones somebody had fought for.
The second is the cost to make the view trustworthy. Where do the numbers come from, and can they be traced back to the system that produced them? Who owns the dashboard, so that when something goes wrong - technically or with the numbers - they have a responsibility to fix it? How does it refresh, and how does it incorporate any upstream changes? And when two views of the same KPI disagree, whose job is it to say which is right? Lineage, ownership, refresh, reconciliation.
None of it is visible on the dashboard. All of it is required to make the dashboard trustworthy. And trustworthy data is what makes it worth acting on.
Rapid-build tooling drives the first cost toward zero and leaves the second cost unaddressed. That's the mechanism, and it is enough to predict what happens next.
When building is nearly free and trust is exactly as expensive as it was, every team builds and no team reconciles, because reconciliation is still the expensive part. The filter that used to limit the number of views was the development cost. Remove that cost and the views multiply until they run out of people to build them.
What you get is many maps of one terrain, each locally convincing, none reconcilable with the others. The company is legible. It's legible one dashboard at a time.
What Grew
I should say what the ServiceNow case was and was not, since I watched it from a particular seat on the inside.
Claude Enterprise went out to the whole company. Within a quarter, dashboards appeared everywhere: sales ops, finance, a dozen product teams, individual managers who had never asked anyone for a dashboard before. Each one was owned by whoever had prompted it into existence. The refresh mechanism, in most of the ones I looked at, was that the owner re-uploaded a CSV.
The views looked live. They were a snapshot of one person's export, and its data lineage, if you want to call it that, was a folder on SharePoint at best, and a local Downloads folder on a laptop at worst.
Many were labeled prototypes. The label was sincere; the person who built the thing did not think they were building a production dashboard. But in my experience, a prototype that gets consulted by leadership every Monday is production, whatever the tab says.
Nobody decided these dashboards would enter the battle rhythm of their teams. They entered it by being faster than what they replaced, and once a director had opened one in a staff meeting three weeks running, the word "prototype" wasn’t doing much governance work.
Here is the part that keeps this from being a simple nostalgia piece. The regime these dashboards displaced was PowerPoint and Excel. Slides assembled by hand, on a cadence, from numbers pulled by whoever pulled them, presented up the chain in a format that had not changed in years.
It was slow. It was also trusted, and it was trusted for the wrong reason. Nobody had checked the PowerPoint numbers any more rigorously than the new dashboards; the deck had simply been the way things were reported for long enough that its age, and the person presenting it, read as accuracy. When the new views showed up and disagreed with the old ones, the reflex in the room was to trust the deck. That reflex was not evidence. It was habit.
And the governance function that was supposed to sit underneath all of this, the process by which a report became an official report, had ossified. Getting a view blessed off took long enough that by the time it was blessed the question had moved. At one point, the backlog to get new data into the enterprise data warehouse was six months. The people who routed around that process were justified, and circumvention was a sane move.
So the new regime replaced a slow, semi-trusted reporting layer with a fast, semi-untrusted one. That is not a story about tools making things worse. It's a story about two reporting layers standing on the same foundation, and the foundation was the problem in both cases. The data underneath was opaque, the systems that produced it were slow to change, and the people and process around it were even slower.
The agentic tool did not touch any of that. It generated a second layer that inherited every weakness of the first and shed the one thing the first had, which was a known owner. The PowerPoint had a name on it. The dashboard had a URL.
The Case for Routing Around
The reader who built forty of these will have an answer ready.
Governance had failed. The old reporting was garbage dressed in a template. The new tools produced more usable information in a month than the data team had produced in a year, and people who had been waiting quarters for a view of their own business finally got one. The correct response to a process that has ossified is to go around it; waiting for permission is how nothing gets built.
Ask for forgiveness rather than permission. Move fast and break things. That start-up style philosophy has disrupted gigantic, ossified incumbents and created trillions of dollars in value.
The answer is not that anyone should have waited. The answer is that routing around a slow foundation does not produce a fast foundation. It produces fast views of a slow one.
The speed was real, and it was borrowed, and what it was borrowed against was a reconciliation debt: the accumulating cost of every pair of views that could disagree and had not yet been asked to. That debt comes due at a specific moment, and the moment is always the same. Two dashboards disagree in front of someone senior enough that the disagreement can't be waved off, and nobody in the room can say which export each one came from, or when, or from what.
At that point the company discovers it has no way to answer a question about itself that it was answering, slowly and wrongly, the year before. The old regime would have produced one wrong number. The new one produces several, with confidence, and no tiebreaker.
Where the Argument Breaks
There are three places this argument breaks.
First, nothing here licenses restoring a monthly review board in the age of AI. A company that responds to dashboard sprawl by reinstating the approval queue has learned the wrong lesson, and it will get the old regime back, slower. The problem was never that people could build. The problem was that building and trusting had been the same cost for so long that nobody noticed when they came apart.
Second, the argument is strongest for financial and operational reporting, where reconciliation matters because somebody will act on the number. For exploratory analysis, for one-off questions, for the view a product manager builds on Tuesday to settle a Wednesday argument and then never opens again, forty disposable dashboards are fine. That is Chen's content model working as intended: spike, decay, next. The line is not fast versus slow, or governed versus ungoverned. It is whether anyone is going to make a decision on the number, and whether they will be able to say afterward where it came from.
Third, the scale. ServiceNow is a ten-billion-dollar software company with a data team, a governance function, and the budget to have both fail. The reader of this newsletter is more likely running a company with one data person, or none, where the CSV in the Downloads folder is not a degraded reporting regime but the only reporting regime there has ever been.
The mechanism is identical: the cost of building fell, the cost of trusting did not. What a large company can fix with a lineage tool and an owner-of-record field is, in a small one, a question of who is willing to be the person whose problem it is when the numbers disagree. That is a staffing problem before it is a data problem, and the essay can't solve it for anyone.
Four Questions
- Can anyone in the company list the dashboards that teams actually run on, as opposed to the ones that exist? If the list would take a week and stop early, the second reporting regime is already in place.
- Pick one dashboard. Where does the data come from, in the sense of which system produced it, and who last refreshed it, and how? If the answer involves a person's laptop, the view is a snapshot, not a live dashboard.
- If two of them disagree, whose job is it to say which one is right? Not whose job it should be. Whose job it is, today.
- Which of the things labeled prototype would cause a meeting to stall if they went dark tomorrow? Those are production.
The fast tools are fine. They just can't do the part that was never fast (yet).