Should agent accountability be designed for end users instead of engineers?

The AI UX Playground glossary defines an action receipt as "a plain-language record of what an agent did, when, and with what permissions, like a bank notification, not a server log." The entry treats the explanation of agent behavior as a consumer-facing design object rather than a technical artifact: where a server log is written for an engineer debugging a system, a receipt is written for the person who delegated the task, in the register of a notification they already trust from everyday financial apps.

The glossary frames the receipt alongside two other trust-and-control terms it defines in the same list: capability disclosure, "telling users. In plain language. What an AI feature can and cannot do before and during use." and explainability, "how clearly an AI product shows why it produced an answer: sources, reasoning steps, confidence, or feature influence." The action receipt sits downstream of both. Capability disclosure and explainability operate before or during an agent's run; the receipt operates after it, as the record a user consults once the action is already done. The bank-notification analogy does real work in the definition: it specifies an audience (the person who delegated the task, not the person operating the system) and a format (plain language, scoped to what permissions were used) that a generic activity log does not promise.

This complements How can users verify what an AI agent actually plans to do?, which argues that establishing common ground with an agent requires verifying both its plans and its actions, not just stating goals to it. The glossary's receipt names one concrete artifact for the after-the-fact half of that verification, formatted for a non-technical reader rather than a developer console. It also extends the over time phase of How should AI systems be designed across different interaction phases?, which calls for giving users controls and learning from their behavior across sessions without naming a specific transparency artifact for that phase; the action receipt is one candidate for filling that gap concretely. An Should agent autonomy be a continuous slider or fixed levels? setting that lets an agent execute without approval raises the stakes of what a receipt needs to report, since there was no confirmation step before the action took effect.

The glossary entry is a definition, not a study: it does not report that receipts were tested with users, that they measurably improve trust or task accuracy, or how a receipt should be surfaced in an interface (inline, in a dedicated log view, or as a push notification). It also leaves open what a receipt should do when the permissions it is meant to record are themselves ambiguous or contested at the time of the action. The implication the excerpt supports is narrower: that the design community now treats an agent's accountability trail as something to compose in plain, consumer language for the delegator, not that doing so is sufficient to resolve agent trust on its own.