A stakeholder asks where a number came from. The agent got it right — same value a human analyst would have produced — but when asked to show its work, there's nothing to show. No query, no source tables, no filter logic, just a confident sentence. The number was correct. The trust evaporated anyway.
Correct and legible are not the same property
Most conversations about AI data agents focus on whether the answer is right. We've written about why the underlying data has to be fresh, why schema drift breaks pipelines silently, and why the model answering the question has to be certified for the job. All of that effort can still produce an answer nobody can verify — because being right and being able to prove you're right are different engineering problems.
A generated SQL query can land on the correct number for the wrong reason. A join that fans out rows and a filter that happens to collapse the fan-out back down can cancel out this month and diverge next month when the underlying data shape changes. If the agent can only hand back a value, nobody catches that until the number is visibly wrong — and by then it's already been forwarded to the board.
Why “it was right last time” isn't a governance strategy
Treating a correct answer as proof of a correct method is the same mistake as trusting a flaky test because it happened to pass. Operators don't need the agent to be right by construction — that's an unreachable bar for any system reasoning over messy production data. What they need is the ability to check the agent's work the same way they'd check a junior analyst's: read the query, see which tables it touched, see what got filtered out, and see how fresh the underlying data was when the query ran.
Without that trail, every escalation turns into an archaeology project. Someone has to reconstruct, after the fact, what the agent probably did — usually by re-running a similar query by hand and hoping it matches. That's slower than just doing the analysis manually in the first place, which defeats the point of delegating the question to an agent.
What a provenance trail actually has to contain
A useful audit record isn't a log line saying “query executed successfully.” It has to answer the five questions an analyst would ask when reviewing someone else's work: what ran, against what, using what filters, how current was the data, and who or what approved it. In DataAgents, every answer carries a structured record alongside it:
{
"answer_id": "ans_9f21c3",
"question": "What was contribution margin for the DTC channel last week?",
"query": "select sum(net_revenue - cogs - shipping_cost - discount_value) ...",
"source_tables": [
"orders",
"refunds",
"shipping_zones",
"discount_ledger"
],
"rows_scanned": 48213,
"filters_applied": [
"channel = 'dtc'",
"order_date >= '2026-07-13'"
],
"freshness": {
"orders": "12m ago",
"refunds": "12m ago",
"discount_ledger": "3h ago"
},
"model": "gpt-5.2-data-tier",
"model_certification": "tier-1-financial",
"validated": true,
"validation_method": "cross-check against warehouse view v_dtc_margin"
}That record is what makes the answer reviewable instead of just believable. When the discount_ledger row shows a 3-hour-old freshness stamp instead of 12 minutes, an operator immediately knows to hold the number rather than forward it — without needing to understand the underlying pipeline.
The trail is also how you catch drift before it ships
The other reason this matters: provenance isn't just for the answer someone is currently questioning. Stored audit records are replayable. When a schema changes or a new join pattern is introduced, you can re-run last month's questions against the new logic and diff the results against what was actually reported. Divergence shows up as a number, not a hunch — and it shows up before a customer or a board member notices instead of after.
It also changes what a human review actually looks like. Instead of a reviewer re-deriving the number from scratch to sanity-check the agent, they read the trail: the tables, the filters, the freshness stamps. That's a five-minute read instead of a twenty-minute rebuild, and it's the only version of “human in the loop” that scales past the first few dozen questions a day.
An answer is a claim. Claims need receipts.
None of this replaces the work of getting the query right in the first place — certified models, fresh data, and stable schemas are still the foundation. But a system that can only assert an answer, without showing how it got there, is asking for trust it hasn't earned. The fix isn't a smarter model. It's treating every answer as a claim that ships with its own evidence, so the humans downstream can verify it in the time it takes to read a paragraph instead of the time it takes to redo the analysis.