An agent finishes a task. The trace is green. Every span succeeded, the model wrote a tidy summary of what it did, and the run is marked complete. Now ask the only question that matters to the business: what changed, and is it right?
You have not answered it. You have answered a different question, and the difference is the whole problem.
A tool call returns success when the system on the other end accepted the request. That is a fact about a message. It is not a fact about the world.
What a successful call actually tells you
Strip it back. A 200 on an API call, a committed database write, a tool result the model can read — each of these says that at one moment a request was well-formed enough to be accepted by something. It carries no information about four things a company cares about.
It does not say the change persisted. Accepted is not committed, and committed is not durable. A queued write, an optimistic acknowledgement, a job that a downstream worker will pick up and reject an hour later: all of these look identical to the agent at the moment of the call.
It does not say the change happened once. Agents retry. Frameworks retry. Networks make a call look like it failed when it succeeded, and the safest-seeming response to ambiguity is to try again. Two invoices paid is a worse outcome than none paid, and the trace looks the same either way unless something is deliberately watching for it.
It does not say the change was the one intended. The call went to a record. Which record? An agent that resolves “the Acme invoice” to an identifier has made a decision, and a successful write to the wrong identifier is a successful write.
And it does not say the change was allowed. Systems of record accept plenty of things that a company’s own policy forbids. The ledger will happily take a payment above a threshold that nobody approved.
Where success and truth come apart
Four patterns account for most of the distance between a green trace and an accurate statement about the business.
The write that gets undone. A record is created, then a validation rule, a workflow, an approval queue or a nightly job reverses it. The agent’s call succeeded at the moment it was made and the effect no longer exists. Nothing in the agent’s own history will ever learn this.
The partial completion. Real work is rarely one call. Raise the credit, notify the customer, close the ticket, post the journal. If the third call fails after the first two succeeded, the run is marked failed and the world has still moved. A failed run is not a no-op, and treating it as one is how companies end up with half-finished work nobody is looking for.
The duplicate. Retries without a deduplication key are how one action becomes two. This is old news in payments engineering and entirely new to a lot of agent tooling, where the retry sits in a framework that has no idea what the call meant.
The silent disagreement. The agent thinks it set a status to approved. The system of record shows approved by a different actor, at a different time, with a different reason code, because a rule rewrote it on the way in. Both statements are true. Only one of them is what the company will be audited on.
Traces answer the engineer’s question, not the controller’s
Observability tooling is good and everyone building agents should have it. Spans, token counts, latencies, error rates and replayable traces are how you debug a system you cannot see inside.
But a trace is a record of what your software did. The question a controller, an auditor or a regulator asks is what your company did, and those are not the same object. A trace proves the call was made. It cannot prove the invoice is paid, because the invoice does not live in the trace. It lives in the system of record, which has its own view, its own rules and its own opinion about what happened.
This is why “we have full observability on our agents” is not an answer to “show me what the agents did to the general ledger last quarter”. The first is engineering telemetry. The second is a business fact that has to be established against the system that holds it.
Reconciliation is the missing step
The step that closes the gap is boring and unglamorous, which is probably why it keeps getting skipped. You state the intended change before acting, observe the actual change afterwards from the system of record itself, and compare the two.
Doing that honestly means being specific about four things.
The intent, in the system’s own terms. Not “pay the invoice” but the document identifier, the amount, the currency, the bank account, the posting date and the version of the record the decision was made against. Vague intent cannot be reconciled, because there is nothing precise to compare the outcome to. This is the same precision that makes an approval bound to parameters meaningful rather than decorative.
The observation, from the source, not from the actor. The agent’s account of what it did is testimony. The system of record’s change feed, event stream or read-back is evidence. Where the two are the same object you have proved nothing, which is why the observation has to come through a path the doer does not control.
A window, because systems are not instant. Batch posting, overnight jobs, replication lag and approval queues all mean the observed state a second after the call is not the final state. A reconciliation that checks immediately and declares success is measuring the write buffer.
A verdict that includes “unknown”. Matched, mismatched, and not yet observable are three different outcomes and the third is the most important one to keep. A system that collapses “I could not check” into “fine” is worse than one that does not check at all, because it produces confident records that are wrong.
Why this cannot be bolted on later
You can add tracing to a running system in an afternoon. You cannot add reconciliation to one, because reconciliation needs something that only exists at the moment of the decision: the stated intent, in the system’s own identifiers, tied to the record version it was made against.
If that was never captured, there is nothing to reconcile against afterwards. You can go and look at the general ledger and see a payment. You cannot establish which agent decided on it, under whose authority, against which version of the invoice, or whether the amount that landed is the amount that was approved. The only honest answer available later is a reconstruction, and a reconstruction is not evidence.
That is why Ayion Meru captures the intent first and treats the observed change as a separate, independent fact. Every consequential action is declared before it is taken, the change is observed from the system of record afterwards, and the comparison — including the mismatches and the ones that could not be observed at all — is written to an append-only ledger. It is also why an evidence pack contains reconciliation results rather than run logs. A log says the software ran. A reconciliation says the business is in the state somebody signed for.
Green traces are a fine thing to have. They are not proof, they were never designed to be proof, and the moment an agent is allowed to move money, change a record or make a commitment, the distinction stops being academic.