In 2025, I sat in a leadership meeting and I was annoyed. Very annoyed.
A beautiful slide, with great graphics and charts and meaningful insights, was telling me things I knew we had the data to prove. But when I was working with the data, I couldn’t get my dashboards to render properly.
I confess. I was jealous.
So I sent the Slacks, set the meeting, wrangled the analyst, and said “What sources feed this Dashboard you displayed?!?!”
…
“Oh, we just used Excel to make it work for the slide.”
In 2025, the TRULY connected dashboard was the holy grail for Operations. It meant clean, curated source data, audit trails, and a stable warehouse. The best dashboards told the right story, at the right time.
Now, the paradigm has flipped completely — for me, the Dashboard is the QA Layer.
A thesis and a build pattern suggestion:
Agentic AI (my preference is Claude, though I admit to various dalliances) has brought two things on a collision course we need to name. The first is that Agentic AI likes to stretch its legs and run head first into existing data traffic patterns — and if you aren’t careful, you can get dragged along with it.
The second is that AI brings connected access to unfathomably large data sets for business-adjacent users with a few key strokes. Why analyze this quarter for a pattern when you can analyze 30? Why run the search against one geo when you can run it against them all? What patterns emerge when you inspect EVERY Opportunity note… ever? The marginal cost is tokens now. No more VLOOKUPs. No more asking Data Engineering for SQL joins. Just tokens.
The next step is where things get really interesting. The follow-on actions from the data insights are also agentic. If this, then send Slack. If that, then set meeting. Agentic workflows.
… But how do I know if it’s right? I AM still human. I have the ability now to adjust agentic workflows which impact dozens of people — and the AI seems very confident… but is it… right?
The Local-Host Python Server “Explorer” pattern has become a go-to for me. I have a template I follow: filters, link-outs to internal systems, sorting, surfacing, and the questions I want the explorer to answer. If I want to explore a topic, my agents know how to surface it to me for review and approval BEFORE it hits a workflow. I built an Explorer Refresh application which will fetch data for each explorer on demand, and I can launch or kill the localhosts on demand to keep my laptop crisp. Nothing I modify or manipulate gets pushed to the warehouse, nothing can alter a workflow while I explore and test.
Then the final step in the pattern — publish as an HTML page for discussion with an Analyst and Data Engineering build brief for how to move it to production if we approve.
There are probably better ways to do this, but this works for me, and it works well. I don’t think about Dashboards the same way anymore. The data is too large, and my world has moved on to modifying workflows fed by data. Dashboards are no longer the destination — they are my QA layer.
The agent workflows act on the stories now, and the right time for them is always on.