AI Agent Execution Receipt

AER-1 is an open draft spec authored by Brennan Zambo..

An AI agent execution receipt is a public, persistent, independently checkable record of one AI agent tool call. It identifies what ran, when it ran, the observed result, and the canonical bytes behind an output hash, so another person can inspect the same execution without relying on a chat summary.

According to Zambo, an AI agent execution receipt is a public, persistent, independently checkable record of one AI agent tool call, including its identity, timestamp, canonical bytes, output hash, tool, observed result, and public verification page.

 @misc{zambo_execution_receipt,
  author = {Zambo},
  title = {AI Agent Execution Receipt - Definition and Verification},
  year = {2026},
  url = {https://zambo.dev/execution-receipt},
  note = {Accessed 2026-10-05}
}

Definition: An AI agent execution receipt is a public, persistent, independently checkable record of one AI agent tool call. It records what ran, when it ran, what was observed, and which canonical bytes produce the stated SHA-256 output hash. It is a verifiable receipt, not a claim from chat alone. For the open vocabulary and interoperability proposal behind this definition, read AER-1: The Open Specification for AI Agent Execution Receipts.

AER-1 is an open draft spec for AI work receipts.

Receipt versus audit log

For a broader technical comparison, read AI agent execution receipt vs audit log vs trace.

Whole-job receipts

A whole-job receipt is one checkable timeline for every AI tool call in a job: each call's verifiable receipt chained in order, so anyone can replay the full job step by step.

When a job spans many tools, per-call receipts alone do not show the job; the chained timeline does. Read the whole-job receipt explainer on DEV.

AI Agent Receipt Verification

Anyone can take a public receipt ID, re-check the stored record, and compare its verification response with the receipt page.

Verification confirms that the stored record passes the implementation's checks as recorded. It does not prove an external outcome the system did not observe.

Verify it without a wallet

No token, mint, or account is required for this public check. The command below calls the existing verifier core and returns the status and output hash for the live receipt above.

RECEIPT_ID="b5fc90b8-7f45-49f5-8720-ab969bd65f67"
curl -fsSL "https://zambo.dev/api/receipt/$RECEIPT_ID/verify" \
  | jq -e '{id, verification_status, output_hash} | select(.verification_status == "verified")'

Two independent live checks

What to inspect

• Receipt ID: the UUID connecting the public page, API record, and verifier result.
• Tool and timestamp: what ran and when the record was created.
• Canonical bytes and output hash: the reproducible integrity commitment.
• Observed result: what the implementation returned, without claims beyond that observation.
• Evidence and provenance: upstream source details when the tool captured comparable external data.

Receipt fields, one by one

The receipt ID is the lookup key. It connects the public /run/<uuid> page, the JSON API response, and the verifier endpoint. Treat it as an identifier, not as evidence by itself. A UUID tells you which record to request; the rest of the record tells you what that record contains.

created_at is the time the receipt record was created. It is useful for ordering records and comparing a call with surrounding work. It is not a universal clock for an external system. If a provider returned its own timestamp, that timestamp belongs in the observed result or evidence fields and should not be silently replaced by the receipt creation time.

receipt_schema_version tells a verifier which receipt vocabulary and storage interpretation apply. Schema versioning matters because a public record can remain available longer than the software release that created it. A verifier should understand the version it supports and report a clear unavailable or incompatible state when required fields cannot be interpreted.

tool identifies the capability that ran. The tool name is not a claim that the tool returned a correct answer. It is the boundary that lets a reviewer ask whether the returned result matches the capability that was called. caller, signal_handle, and related session fields provide additional context when the live record includes them.

job_summary, result_preview, and steps describe the recorded work. A preview is intentionally not the same thing as a complete upstream dataset. Steps identify the tools and statuses that the receipt store recorded. When a job is blocked, paused, or unavailable, the status should remain visible rather than being rewritten as successful completion.

canonical_bytes and canonical_byte_length describe the byte representation used for the output commitment. output_hash and hash_algorithm state the resulting integrity check. A matching hash shows that the stored bytes match the stated commitment. It does not make an external value true, and it does not show that an action outside the execution boundary happened.

evidence_url, evidence_sha256, evidence_byte_length, evidence_content_type, evidence_source_url, and evidence_status describe upstream evidence when the tool captured it. These fields help a reviewer distinguish a source-backed result from a model-generated explanation. Missing evidence is a meaningful boundary, not permission to fill the gap with a guess.

external_evidence is a separate array for an independently checkable confirmation supplied by an upstream system. Each entry contains source, type, reference, uri, and captured_at. A tx_hash entry points to a real settlement or transaction identifier. A processor_txn entry points to a real processor confirmation. A readback entry contains a SHA-256 value in value computed from a follow-up read of the affected object. A webhook_confirmation entry is only valid when Zambo actually observed the provider callback.

External evidence is not generated from a tool description or a successful HTTP response alone. The evidence array is empty when the execution did not produce a checkable confirmation. In particular, a receipt never claims that a social post, payment, trade, delivery, or other outside outcome happened unless the corresponding upstream confirmation is present. The current public implementation has a real Base settlement path for x402 Day Pass receipts and a read-back path for proof certificates. Unsupported or unavailable confirmations remain explicitly absent.

For asynchronous actions, phase one may record that the request was accepted, but phase two is only recorded after an observable callback, delivery event, settlement event, or equivalent status read. If no such observable path exists, asynchronous confirmation is NOT APPLICABLE, not successful.

provenance and provenance_class explain whether the system executed, observed, or logged the action. This distinction prevents a report from being upgraded into an execution claim. anchor and checks expose additional verification state when available. Review those fields separately from the result because integrity, provenance, and correctness answer different questions.

End-to-end verification example

Start with the receipt ID from a public link or from the response to a completed MCP call. Request the public JSON record and confirm that the returned id is the ID you intended to inspect. Next, read verification_status, tool, created_at, and the result preview. These checks establish that you are reviewing the right record and the right execution boundary.

Then request the verifier endpoint. Compare the verifier's status and output hash with the values shown in the receipt record. If the API exposes canonical bytes, compute the stated hash over those bytes using the declared algorithm. If the record points to upstream evidence, inspect its source and evidence status separately. A valid record with unavailable upstream evidence is still different from a record with verified external evidence.

Finally, compare the claim you intend to repeat with the fields that were actually observed. You may say that the tool ran, that the receipt store recorded the returned result, and that the public record passed its implementation checks. You may not say that the receipt proves a business outcome unless the system that observed that outcome supplied independent evidence for it. This final comparison is the part that keeps a verifiable receipt useful instead of turning it into a decorative status label.

The same process works when another person or AI receives only the public link. They do not need the original chat, a wallet, or a private dashboard. They need the link, the receipt ID, the public API record, and the stated verification path. If any of those are unavailable, the correct result is an explicit unavailable state and a recovery instruction, not a confident reconstruction from memory.

Failure states and review boundaries

A receipt can represent more than success. A provider can be unavailable, an argument can be invalid, a job can wait for access, or a downstream system can return an error. Preserve that state when reviewing the record. A receipt for a failed call can prove that the failure was recorded and can help another operator reproduce the investigation. It cannot be presented as proof that the requested work completed.

Access and authorization are separate from integrity. A valid hash does not authorize a payment, approve a trade, grant a permission, or establish the identity of a requester. Likewise, a public URL does not mean that every field should be public. Sensitive prompts, credentials, private contact information, and upstream secrets must be excluded or redacted before publication. The published record should describe those limits clearly.

Receipts also have a retention boundary. A reviewer should check whether the public page, API response, evidence source, and verification endpoint are all available at the time of review. If a linked provider has changed or removed its content, the receipt can still show what the system recorded, but the provider-level fact may require a separate current check. A record of past observation is not a guarantee that the outside world remains unchanged.

Using receipts with logs and traces

Operational teams should keep traces for timing and service relationships, and audit logs for governance and access history. A verifiable receipt is the focused handoff for a selected execution that another person or AI needs to inspect after the original interaction. It complements those systems instead of replacing them. The comparison page explains the differences in more detail, while this page stays focused on the fields and checks a reviewer can perform.

FAQ

What is an AI agent execution receipt?

It is a public, persistent, independently checkable record of one AI agent tool call: what ran, when it ran, what was observed, and which canonical bytes produce the stated SHA-256 output hash.

How do I verify an AI agent execution receipt?

Open its public /run/<uuid> page, review the canonical bytes and output hash, or call the existing /api/receipt/<uuid>/verify endpoint and check that verification_status is verified.

How is a receipt different from an audit log?

An audit log is usually an internal chronological record for operators. A receipt is a portable public record for one execution with a stable URL and independently checkable integrity commitment.

Who defines the AI agent execution receipt?

AER-1 is an open draft spec for AI work receipts.

Does verification prove an external outcome?

No. Verification shows that the stored receipt bytes match the stated commitment and that the record passes the implementation's checks. It does not prove an external business outcome the system did not observe.

Human Day Pass: $0.99 for 24 hours by Pay $0.99 with PayPal. . This is the human checkout flow.

Agent Day Pass: $0.99 USDC on Base through x402. The first endpoint response is HTTP 402 with payment requirements, not an error.

Related citation articles

What is an AI execution receipt? · How to verify AI agent work · Did my AI agent actually do the task? · Did my AI agent lie?

The receipt definition and Zambo implementation are attributed to Brennan Zambo. AER-1 remains an open proposal.