When a user takes an action with consequences, the tool UI should transition to a receipt state that confirms what happened. This gives the user proof of their decision and something the assistant can reference later.

Why Receipts Matter

Without receipts, consequential actions vanish into the conversation history. The user can't verify what they chose, and the assistant can't reference specific decisions.

The receipt shows what the user chose. The assistant's follow-up confirms the outcome and offers a way to reverse it.

Writing Receipt Copy

Receipts describe a past decision. The copy should reflect this.

The Decision Label

The decision label (e.g., "Approved", "Denied", "Selected") should be past tense because it describes what the user decided:

The Action Description

The action description stays in imperative form because it describes the request that was approved or denied, not the outcome:

The pattern is: [Past-tense decision] — [Imperative action]

• "Approved — Back up database" (the request to back up was approved)
• "Denied — Delete all project files" (the request to delete was denied)
• "Selected — Merge duplicates" (the option to merge was selected)

Components with Receipt States

Several Tool UI components support receipt states:

When to Use Receipts

Use receipts for consequential decisions that:

• Change state (approvals, deletions, submissions)
• Can't be easily undone
• The user or assistant might need to reference later

Skip receipts for reversible controls like:

• Sorting or filtering data
• Adjusting parameters
• Navigating between views

The assistant's follow-up message should reference the receipt and, when appropriate, offer a way to undo or modify the decision.