Edited for clarity.
Why is real-time insight with context so hard?
Real-time insight with context does sound like a reasonable ask, but under the hood it's a tough problem. Real time is actually not the hard part. You can stream events, and warehouses update really quickly now, so that's almost a solved problem. The problem that gets in the way is context. When conversion drops, approvals dip or refunds spike, you immediately hit three things. First, the data is very fragmented: the payments team has one view, the marketing team has another and product has another. None of them line up cleanly, and none of them agree on what a customer is or what an order is.
Second, tooling has historically separated detection from understanding. A dashboard tells you conversion has dropped, but not whether it's a change in ads, an inventory issue, a payment provider or seasonality. So people drown in alerts and stop trusting them.
Third, even when you've figured out why, there's almost no connection to who should do something about it right now. By the time the right merchandiser or the right payments owner hears about it, it's already too late.
What should real-time analytics actually deliver?
If I have to put it in one line: you don't get a chart, you get a decision-ready brief. Take a payments example, which serves as a good proxy for all transactional businesses. Instead of a chart that tells you approval rate is down, you get what changed: approval is down seven points. Where it's happening: cross-border, when cards are not present, at a specific issuer. When it started: right after a gateway change. How much it matters: this amount of revenue at risk in the next hour. And what to do next: you can reroute traffic, open an incident, or notify the issuer.
Then it goes to the person who can actually act. It's not going to a generic channel. The bar to set is whether someone can take action in 60 seconds without opening a dashboard.
What does an analytics agent need from your data before it can work?
There are about three things at a minimum. Number one is a clean event stream. Whatever your bookings, orders and payments are, whatever the verbs in your business are, they need to be structured and timestamped. The best case is that they're all in Snowflake or BigQuery, or coming in through Kafka or Kinesis, and they're clean and organized. If you have to merge multiple CSVs or get a PDF export from a SaaS tool, that's where the struggle is.
Number two is common definitions. Everyone needs to agree on what an order is, what revenue is, what a failed payment is. Otherwise the agent finds an anomaly and the finance team comes back asking which version of revenue that is.
The third and most important thing is latency that matches the decisions. If you want to intervene within the hour, the data can't come in tomorrow. Near real time where it matters, batch where it doesn't. Agents cannot fix bad modeling magically. An agent is only going to amplify what's underneath. It's not going to fix it.
What does an analytics agent do all day?
It's obviously not a chat window. It's an always-on analyst. Number one, it wakes up every few seconds or minutes and asks whether any of the KPIs or journeys it cares about moved in a meaningful way, and not just raw values, but normalized for seasonality, campaigns and holidays.
Number two, when it finds something, it doesn't stop at 'this dropped' or 'this spiked'. It starts pulling slices by country, by device, by payment method, by merchant, to see where the deviation is concentrated. That's what a typical analyst would do, and it's where scaling becomes a problem.
The third part is that it builds a hypothesis tree: is it localized to cross-border, is it new customers, is it one payment gateway, did it start right after a config change?
And the last one is that it decides whether this is just interesting or also urgent. Then it can send a summary to a human, or kick off an automated playbook in some cases. Eventually it produces a short brief: here's what changed, here's likely why, and who should act.
Where should a team start with agentic analytics?
My advice would be to start painfully small. Pick one revenue-critical area, like checkout conversion or payment approvals, and even that for a particular market, or order cancellations. Don't try to take on the whole business. Once you pick that area, the question is whether you can give an agent the data and the context it needs to own this one KPI or journey end to end, so it can sit on top of it, detect issues, explain them and propose actions.
Pick one KPI that matters and one playbook, and run the agent in parallel with your current processes for a few weeks. Keep your existing dashboards and processes, everything you're doing, and run the agent in parallel.
See if it catches things earlier, explains things better, and reduces the manual back and forth. That's how I would start, rather than some giant AI transformation that tries to agentify the whole thing.
Will people still start their day in a dashboard in three to five years?
I think the big shift is that fewer people start their day in a dashboard. I've seen customers still resistant to shifting to an agent, because the dashboard is something they trust and it's easy to follow. They almost want something that isn't interpreted, because it gives them peace of mind. The AI has to mature to really give them that trust.
As it does, people will start their day with a short brief instead: here are the three things that moved yesterday, here's why we think they moved, here's what we already did, and here's where we need discussion. Operations, product and marketing teams will all spend less time hunting for problems and more time deciding tradeoffs, like whether to accept this risk for that upside.
If five years from now your best people are still manually stitching CSVs together to understand what happened last week, we would have failed. So: less hunting, more steering, more decision-making.
