What are receipts for AI agents, and why audits beat vibes

An agent that can act on the world needs a record that describes more than its conversation. A transcript can show what the model intended. A tool log can show that an endpoint answered. Neither one, by itself, tells an operator whether the requested business outcome happened. A receipt closes that gap with a compact record that can be inspected after the work is done.

The receipt

A receipt is an auditable record for one agent action. It has four fields, and each field answers a different operational question:

• Action identifier: which action is this, and where does it sit in the crew’s run? This can be a stable ID such as publish-8f21, with a link to the preceding draft and the agent run that requested it.
• Cost incurred: what did the action consume? Record model spend, API charges, or another measurable cost in a currency and unit that an operator can total. A zero-cost local spell-check still deserves an explicit zero.
• Outcome assertion: what changed in the world, according to the system that owns the result? This is a claim such as “draft saved as revision 184” or “CMS post is publicly visible at this URL,” not a restatement that a function returned.
• Approval state at the moment of action: was the action allowed in away-mode, approved by a person, rejected, or still waiting at the human gate? Capture the state when the action ran, not the state someone assigns during a later review.

The four fields make a receipt useful on its own and composable with the next receipt. An action identifier gives it a place in a chain. Cost gives a budget cap something to measure. The outcome assertion gives a reviewer something falsifiable to check. Approval state records whether the agent crossed a boundary it was allowed to cross.

What a receipt is not

A receipt is not a chat transcript. A transcript is the sequence of prompts, model messages, tool requests, and model replies. It is useful evidence of reasoning and intent, but it is a poor index for answering “which publication actions cost more than the budget cap?” or “which external commitments ran without approval?” Searching a conversation mechanism by mechanism is not the same as querying an action record.

It is also not a tool-success log. An HTTP client may report a 200 response, and a task runner may mark its step successful because the process exited with code zero. Those mechanisms describe transport and execution. They do not assert that a CMS made a post visible, that an email reached its intended audience, or that a database transaction contained the expected rows. A receipt can cite those logs while recording the stronger outcome assertion separately.

Finally, a receipt is not screenshot-based marketing. A screenshot captures a display at one moment; it does not preserve the action identifier, cost incurred, or approval state, and it is difficult to filter or reconcile. The receipt mechanism is structured data tied to the action and its result. Screenshots can illustrate a result, but they cannot replace the audit trail.

A worked example

Consider an agent asked to prepare and publish a short product note. The work has four actions:

Action	Action identifier	Cost incurred	Outcome assertion	Approval state
Draft content	draft-41	1,200 model tokens	Draft saved as revision 184	away-mode
Spell-check	spell-42	$0.00	184 has no flagged spelling errors	away-mode
Publish to CMS	publish-43	$0.03 API charge	CMS reports the post as published	approved by Maya at 14:03 UTC
Return URL	return-44	80 model tokens	Agent returned https://example.test/notes/receipts	away-mode

The identifiers chain the work: spell-42 points to revision 184, publish-43 consumes the checked revision, and return-44 carries forward the publication result. A reviewer can total the model and API cost, confirm the human approval at the publication gate, and inspect the outcome assertion without reconstructing the whole prompt history.

Now take the failure case. The CMS returns 200 to publish-43, but a moderation rule silently rejects the post. The client has a successful request log, while the CMS has no user-visible page. If the agent records only “publish API returned 200,” it can return a URL that looks plausible and declare success. A proper receipt marks the outcome assertion as “CMS accepted the request, visibility unverified,” or records “not published” after a follow-up visibility check. return-44 must not upgrade an unverified response into user-visible success. The URL is an output; the public page is the asserted outcome.

Why audits beat vibes

A transcript asks an operator to scroll until a suspicious sentence appears. Receipts let the operator filter by cost incurred, action identifier, outcome assertion, or approval state. That difference matters when a fleet has many crews and each crew performs repeated work. A budget-cap review can find every action that approached the cap. An approval review can isolate publication and spending actions that were waiting at a human gate, approved, or rejected.

The same records support away-mode without pretending that autonomy means “no review.” Low-risk steps can run in away-mode, while publication or an external commitment pauses for a human gate. If something goes wrong, the audit starts with the durable record: what the agent did, what it cost, what system outcome it could substantiate, and which approval state applied. That is faster than reading a story after the fact, and it leaves an operator with evidence rather than a feeling that the run probably worked.