Solving the provenance challenge in finance AI agents
Coding agents got good remarkably fast, and I think there's an under-appreciated reason why: software comes with verification oracles.
When an agent writes code, it doesn't need us to simply trust that the code works. It can compile it. Run the type checker. Execute tests. Run CI. Observe runtime failures. Software doesn't have perfect oracles, but it has unusually rich ones. That creates a powerful loop:
generate → execute → verify → correct
And that loop is a big part of what makes autonomous coding agents viable.
Now try the same thing in finance. Ask an AI agent:
"What was my gross margin last quarter?"
A general-purpose model can read some transactions, do arithmetic in its context window, and confidently return a number.
But where is the compiler? A hallucinated code function fails immediately. A hallucinated tax liability might fail six months later, when an assessment notice arrives.
That is the provenance problem I've been thinking about while building finance agents at TrackBooks: how does a financial answer prove where it came from? How do we make sure the same underlying data and accounting rules produce the same answer every time?
My current design bet is that finance isn't actually oracle-poor. It is oracle-fragmented.
The oracles already exist. The P&L engine knows how revenue and expenses are classified. The balance-sheet engine knows how accounts roll up. The ageing engine knows which invoices are outstanding. The reconciliation engine knows whether two sets of records agree.
The mistake is asking the language model to recreate these systems inside its context window.
So in our architecture, the model does not perform authoritative accounting computations. It does something narrower. It understands the question. It decides which instruments to use. It calls them. It chains their outputs when necessary. And it explains the result. The tool, not the model, becomes the unit of trust.
1. Report engines are the strongest tools
The highest-confidence tools simply expose the same deterministic engines that already produce financial reports: P&L, balance sheet, cash flow, receivables ageing, payables ageing.
If the agent answers a question using one of those tools, there is no separate "AI version" of the number. It is using the same computation path as the underlying accounting system. That matters. The model can misunderstand a question. It can choose the wrong tool. It can explain something badly. But it should not be inventing a second implementation of accounting logic.
2. Finance also needs its equivalent of grep
Coding agents don't spend all their time compiling. They spend enormous amounts of time searching: grep, find, read.
Finance agents need the same second layer, because no fixed report engine can answer every possible business question.
Our answer is guarded, read-only SQL over curated financial views. The agent can search transactions, compare periods, inspect parties, identify unusual movements, and combine those results with the deterministic reporting tools.
The hierarchy is deliberate: report engines first; guarded retrieval for the long tail. If a trusted engine already knows the answer, use it. If it doesn't, give the agent safe instruments for investigating the underlying data.
3. Every tool should carry its own evidence
This is where provenance becomes more than simply "the AI used a tool." A trustworthy financial result should be able to carry things such as:
- the source data or records used
- the accounting period
- filters and parameters
- the data snapshot
- the tool or engine version
- reconciliation information where applicable
That gives us three separate properties:
- Deterministic computation. Accounting logic runs outside the model.
- Provenance. We can trace where the answer came from.
- Reproducibility. The same data, rules, parameters and versions should reproduce the same result.
None of those guarantees that software can never contain a bug. But they make financial answers inspectable, testable and auditable in a way that arithmetic generated inside an LLM simply isn't.
4. Writes need a different contract
Reading financial data is one thing. Changing it is another.
When our agents begin creating journal entries, bills, reconciliations or other financial actions, those will also be tools, but with a human explicitly built into the contract. Something like:
propose → explain → approve → revalidate → execute → audit
The agent proposes the action. A human approves it. The system re-checks that the underlying state has not changed. The deterministic tool executes it. The audit trail records what happened.
So the rule becomes: reads require provenance; writes require provenance plus authorisation.
The interesting part is how this architecture compounds. Every new tool converts another category of questions from "the model worked it out" to "a deterministic system computed it."
At the same time, every improvement in foundation models makes the agent better at understanding questions, selecting tools, chaining them, investigating exceptions and explaining results. Those two improvements are largely independent. More verified tool coverage raises trust. Better models raise orchestration intelligence.
So that's my current thought process and roadmap for finance agents: keep building tools. The models will keep getting better at playing them.
I suspect this pattern extends well beyond finance: law, tax, medicine, compliance. Any domain where getting the answer wrong doesn't immediately throw an exception.
The interesting question may not be "how do we make the model know the domain well enough?" It may be "how much of the domain can we turn into instruments that carry their own proof?"