If an agent surface ships on this site or inside a client workflow, the run needs a receipt.
A receipt does not prove the answer is correct. It proves there is a record of what ran, which model was used, which tools were called, how many tokens moved through the system, when it happened, and whether a human reviewed it.
That is the difference between a claim and an inspectable system.
What a receipt proves
An agent receipt is a provenance record. It answers the questions a serious operator asks after an automated system does work.
- Which agent ran?
- Which model route did it use?
- Did it call tools?
- Did it finish, fail, refuse, or time out?
- How expensive was the run?
- Was a human review required?
- Can we connect the output back to the run without exposing private content?
Those questions matter because agent failures are rarely dramatic. A draft looks fine until a source is missing. A lead summary looks useful until a field came from stale CRM data. A browser task looks complete until the agent skipped the final confirmation.
Receipts make those failures easier to find.
The fields we record
The current receipt schema is intentionally narrow. It stores provenance while excluding private content by default.
The important line is the last one. Raw prompts, outputs, and user-provided content do not belong in a public receipt. The hash lets us prove that a run happened without turning private context into marketing material.
What a public receipt can show
The public version should be safe enough for a marketing site and specific enough to prove the claim. These examples show the shape, not raw client records.
That is enough for a visitor to see that the system ran. It also respects the client. The receipt proves the path without turning private context into a public sample.
Public versus client receipts
A public receipt should be compact. Visitors need the basic proof: model, status, tool count, timestamp, and review state.
A client receipt can go deeper. It can show token counts, cache tokens, latency, the tool-call count, the reviewer, and the private context the client is already allowed to see.
An internal audit view can include operational fields such as IP hash, error status, budget flags, and failed write attempts.
That separation keeps the trust layer useful without making every run a spectacle.
What happens when a receipt is missing
The policy is simple: do not turn an agent claim into public proof unless the run can be traced.
If the receipt is missing, the copy should say less. It can say the workflow is planned, mocked, scaffolded, or manually reviewed. It should not imply a live agent completed work that cannot be inspected.
That constraint is good for the brand. It keeps the site honest while the agent surfaces mature.
Receipts still need review
A receipt records what happened. A human still decides whether the output is useful, safe, and worth showing.
That is why the receipt schema pairs well with approval gates. The agent can draft, summarize, gather, or test. The system records the run. A person approves the business action.
Run this next
Pick one workflow where an agent already drafts or summarizes work. Write down the six fields you would need to defend that output later: model route, prompt hash, tool count, status, reviewer, and final artifact link.
