Data Reliability Series
An agent pulls a revenue number from one system to decide whether to flag an account for churn risk. The number is three days stale. Another system, two clicks away, has the updated figure. That number is lower, already past the threshold that would have triggered an account review. Nobody notices. No alert fires because all systems are green. Your observability tools show everything is healthy and working. The agent wasn’t wrong about what it read either. It was just reading the wrong version of the data, and there was no one in the loop to catch the disagreement.
This is not some exotic edge case. Some version of it may already be happening in your organization. The question is not simply whether the number exists, but whether it’s the right number for the decision being made.
Ask leaders if they trust their data, and many answer too quickly. “Sure. We’ve invested in modern data platforms, established database and ERP systems, improved pipeline monitoring, and put data governance programs in place.” All of this matters. These investments have improved reliability, speed, access, and flexibility. But how much attention has gone into whether the data is right for a specific business decision, especially one made without human review?
Trust is earned at the point of action
We’ve spent years building better places to put data: modern data warehouses, data lakes, data lakehouses, each promising to be the definitive home for enterprise truth.
But when an autonomous system reaches into that store and acts on what it finds, will the outcome be right? The technology may have worked perfectly. That still leaves the question of whether the agent used the right data.
Trust isn’t a property of where data lives. It’s a property of what happens the moment it’s used.
Three hard questions
Rather than asking whether you trust your data in the abstract, try these:
1. Can you trace it?
If an agent produces an answer today, can you follow that answer back to the exact source, the exact version, and the system of record it came from? Or does the trail go cold somewhere in the middle?
If you don’t have that trace, how does your team investigate a questionable result? How much time is spent? And what happens to that workload as more decisions become automated?
2. Would it survive a second opinion?
If two different systems in your enterprise were asked the same question right now, would they agree? And if they didn’t, would you know why?
This is where it gets uncomfortable. Different answers aren’t always a sign that something is wrong. Systems may use different definitions or reflect different points in time. But when those differences aren’t understood, an agent may treat either answer as equally valid.
Why does this matter more now? Because until recently, many of these differences didn’t have to be resolved at the speed of an automated decision. A human reconciling a report might notice a mismatch and make a judgment call. An automated workflow may simply move on.
3. Would you let it act without you?
Not “would a human read this and decide,” but would you actually trust your data enough to let an agent execute on it, unsupervised, today?
This question is the real divide. Human review has often served as an informal checkpoint, catching stale numbers, conflicting definitions, or other problems that were never explicitly covered by a data quality rule. Not always, and not reliably. But the opportunity to catch them was there.
When that review disappears, what takes its place?
Not every decision should be fully automated. Some will still require human approval. But for the decisions you do automate, how do you know the data can be trusted enough to act on?
Across medium and large enterprises, a common pattern emerges. The first question usually gets a quick yes. The second brings some hesitation. And the third? That’s where people tend to stop and think about what they’re actually prepared to let an agent do.
The cost of answering Yes too soon
Here’s the part worth sitting with: the gap between question two and question three is where organizations can get exposed. In practice, an organization may already be answering yes to question three by allowing an agent to act without human review, whether or not anyone has asked the question out loud.
When that gap goes unexamined, failure doesn’t look like an outage. The systems are running, the agent is doing its job, but the number it’s relying on may be three days old, an orphaned copy, or a metric that has quietly drifted from its source.
Check the box on acquiring the data, move on to the next action.
And this is no longer one person making one decision. You could have dozens of agents working from the same questionable data, each passing its results to another process. By the time the problem is discovered, it may have already affected decisions well beyond the original workflow.
What real trust looks like
A data platform or governance policy can help establish trust. But what happens when the data is actually used?
Knowing which data to use, not just whether it exists. Different systems may hold different versions of the same information, sometimes for good reasons. The question is whether the agent can identify which source, definition, and version are appropriate for the decision. Five versions slowly drifting apart under different names are a problem when nobody knows which one to use.
A track record you can actually examine. A one-time audit is no longer enough. You need to be able to look back at what data was used, which version was available at the time, what decision followed, and whether that decision held up under scrutiny. Just because no problems have been reported doesn’t mean the decisions were right.
Visibility into disagreement itself. Knowing where a number came from is a start. You also need to know when it changed, how it was derived, and why it differs from information held elsewhere. Some differences are expected. Others should raise questions before an agent acts on the data.
Take the churn example. Which revenue figure should the agent have used, and how would it know? If the two systems disagreed, what should happen before the agent acts?
The question isn’t how confident you feel about your data infrastructure. It’s what you can verify before an agent acts, and what you can investigate afterward.
So, do you trust your data enough to let an agent act on it? And what would you need to know before answering yes?
Related Reading