What is an agent receipt?
A record of one action an agent took, carrying enough of the outside world in it that somebody else can check the claim without trusting you.
Updated 2026-08-31
The short definition
An agent receipt is a record of a single action an AI agent took against an external system, written at the moment the action was taken, and carrying that external system’s own identifier for the result.
The last clause is the whole thing. Without it you have a log line: a sentence your system wrote about its own behaviour. With it you have a pointer at something in somebody else’s system, which they can open without believing a word you say.
The analogy is deliberate. A shop receipt is not valuable because it says a purchase happened. It is valuable because it carries a transaction number the bank also has. Two independent records that agree is a different kind of evidence from one record asserting confidently.
What a receipt has to carry
Four things, and dropping any of them changes what the record can settle.
The action, specifically. Not "notified the customer" but "sent an email to this address with this subject". Vague records fail exactly when someone disputes the specifics.
The actor, and whose authority it acted under. An agent acting as a service account and an agent acting as a named person are different facts, and only one of them answers who approved this.
The time it was written, which should be the time it happened rather than the time somebody assembled a report.
The destination system’s identifier. A message id, a ticket key, a row id, a transaction reference. This is what turns your assertion into a pointer.
A receipt Claritty writes carries the provider identifier only when the provider returns one under a name the capture layer recognises. It has more than once returned an id under a name we did not know, leaving a row that is true and useless. That is a real limit, not a hypothetical.
What a receipt is not
A receipt is not proof the action was correct. It records that an email was sent, not that sending it was a good idea. Those are different arguments and conflating them is how "we have an audit trail" comes to mean "we are behaving well".
A receipt is not proof the action still stands. Things get deleted, reversed, and superseded. A receipt written on Tuesday describes Tuesday.
A receipt is not, on its own, tamper-evident. If it lives in a table somebody can edit, it is worth what that person’s access is worth. Chaining records so each covers the one before it fixes this, and is a separate mechanism from the receipt itself.
And a receipt is not proof that nothing else happened. It attests to one action. Whether it attests to ALL the actions depends entirely on whether every side effect crosses one place that records it — which is an architectural property, not a feature you can add later.
Why the identifier is the expensive part
Almost every agent platform can produce the first three fields. They come free with structured logging. The fourth is where the work is, because every provider returns its identifier differently, under a different name, in a different shape, and some return nothing useful at all.
So capturing it is not one feature. It is one small piece of work per integration, repeated, with no demo value and no marketing surface. That is why the field is often missing, and why its presence is a reasonable proxy for whether a vendor has done the unglamorous half of the job.
Questions
Is an agent receipt the same as a trace?
No. A trace records what happened inside your process — model calls, tool calls, timings. A receipt records what happened outside it, and carries the outside system’s identifier. Traces are better for debugging. Receipts are better for disputes. Most teams want both.
Does a receipt prove the agent had permission?
Only if it records whose authority it acted under, and only as well as your authorisation records themselves. A receipt that says an action was taken as "the automation" answers what happened but not who allowed it.
How long should receipts be kept?
Longer than your observability retention, because audit questions arrive on a slower clock than incidents. It is worth checking the retention window on whatever holds them before assuming a record will be there when it is asked for.
Related
A log says what happened. An audit trail survives someone doubting it. The gap between those two is where most agent evidence fails.
Most of these are excellent at tracing. Tracing and proving are different jobs, and the difference only shows up when someone disputes a record.
Three words used as synonyms in AI governance copy. They describe different guarantees, and one of them is usually a claim nobody can support.
Applicable since 2 August 2026. It is narrower than most coverage suggests, and the first useful question is whether it applies to you at all.
Three verdicts, the fields each carries, and the precedence that decides whether a record can point at anything at all. Read out of the code, not illustrated.
Look at what a real run leaves behind
Building an automation is free and it runs on your own data, so you can read its records before deciding whether any of this holds up.
Start freeOr read how the records work first.