Originally published at Trida AI.
"Where did nineteen days come from?"
Picture a routine review. An agent has summarised a supplier's documents and put a lead time at nineteen days. The number looks ordinary, sitting in a tidy paragraph next to two others nobody questions. Then someone asks which document said nineteen, and the room goes quiet. The trace shows the searches, the reads, a long generation. What it cannot show is which passage that one number rested on. Nobody kept the connection between the claim and its source.
Most agent systems keep a good record of the run and a poor record of the answer.
A trace answers a different question
A trace is an operator's record. It tells you the order of operations, what each call received and returned, where the time went. The OpenAI Agents SDK traces runs this way by default: generation spans hold the model's inputs and outputs, function spans hold a tool call's arguments and its result, and you can turn that capture off because the contents may be sensitive. Useful, and necessary. Also not the reader's question.
The reader's question is narrower and ruder: this sentence, the one I am about to act on: what is it standing on? A trace can help an engineer reconstruct an answer after the fact, the way a flight recorder helps investigators. A receipt is the thing you hand over at the time, before anyone has to reconstruct anything.
The idea is old. The W3C PROV family modelled provenance as entities, activities, and agents: a thing, the process that produced it, and whoever bears responsibility for that process. Agent answers fit that shape well. The claim is the entity. The retrieval is the activity. The system that served the answer is the agent who stands behind it.
Attach the receipt to the claim
Answer-level citations are where good intentions go soft. A paragraph ends with two links, and the reader guesses which link supports which sentence, or whether either supports the number in the middle. Receipts earn their name at claim level: one claim, one record, four fields.
The source, named exactly — the document, the record, the tool result, not "the database". The passage inside it, located so a person can land on it: a page range, a character range, a row key. The time it was read, because sources change and a receipt from March should not underwrite a claim made in November. And the claim itself, stored as written, so a later edit cannot borrow a receipt issued for different words.
Some of this machinery now ships with the models. Claude citations return structured objects rather than prose promises: the cited text, which document it came from, and a location that is a character range for plain text, a page range for a PDF, or a block range for custom content. That is the right shape. It is not, on its own, a guarantee. Anthropic's own guidance for extracting fields this way ends with an instruction to check that each field has a value and at least one citation, because the API guarantees neither. The check is yours to run. A claim that comes back without a receipt has to go somewhere you decided in advance: held for a person, rewritten to say less, or dropped. What it cannot do is ship wearing the same confidence as its supported neighbours.
One claim's path through the system: the tool result is stored as a receipt before the answer is written, and a checker holds any claim that arrives without one.
Receipts have to survive the machinery around the answer, too. Summaries compress, handoffs pass context along, and both are fine places for a source to fall off a claim. Pass receipt identifiers along with the text they support, the way you would pass a primary key, and let the checker follow them back to the stored passage. If the passage cannot be opened, the claim is unsupported again.
What the reader actually sees
One short answer, three claims: two carry receipts a reader can open, and the third, which had no receipt for its date, was rewritten to say only what its source supports. Example content, invented for illustration.
Notice what changed for the third claim. It was not deleted, and it was not left standing on a plausible tone of voice. It shrank to fit its evidence. That is most of the daily value here: receipts rarely expose a dramatic fabrication. They expose the sentence that drifted a little further than its source, the figure that was true of last quarter, the commitment a document mentioned as a possibility and the answer repeated as a plan.
Where receipts run out
They only cover claims that come from somewhere. A recommendation, a judgment, a forecast — these rest on reasoning, and dressing them in citations borrowed from nearby facts would be worse than leaving them bare. Mark them as the system's judgment and let the reader price them that way.
Coverage costs, too. Claim-level checking adds a pass to every run, the receipt store becomes one more system holding possibly sensitive passages, and a team that demands receipts for trivia will train its agents to write answers with no checkable claims in them at all. Receipts belong where a reader will act: figures, dates, commitments, statuses. The rest can travel lighter.
And a receipt proves where a claim came from, not that the source was right. A wrong document produces a perfectly valid receipt. That still helps: the argument moves from "the agent said so" to the document itself, in one click, and the document can be fixed at its root.
Keep the passage, not a pointer to it. Attach it to the claim, not the answer. Hold the claim that arrives without one. Three dull rules, and the question at the top of this post — where did this come from — gets an answer in seconds instead of a reconstruction project.
Work with us
If your agents produce answers your team cannot check without replaying the whole run, the missing piece is a receipt layer, not a longer trace. Bring the answers your readers act on through Trida AI's intake and we will work out which claims need to carry their sources with them.
Top comments (0)