For most of software history, the boundary was easy to see. A person clicked a button, and the system responded. If something went wrong, there was usually a visible action to trace back to.

AI agents blur that boundary. A person can now express an intent in a sentence and allow software to decide which steps, tools, and services are required to carry it out.

That is powerful. It also creates a basic design problem:

How does a person know what actually happened?

A polished final message is not enough. “Done” could mean a draft was created, a request was submitted, an appointment was booked, or an attempt failed after three partial steps. Those outcomes are materially different even when the chat response sounds equally confident.

Agents need receipts.

A receipt is more than a log

Technical systems already produce logs. They are useful for engineers and nearly useless for the person whose money, calendar, customer, or household was affected.

A human receipt should answer a small set of ordinary questions:

  • What did you understand me to be asking?
  • What did you do?
  • Which systems or people did you contact?
  • What changed?
  • What did not work?
  • What still needs my approval or attention?
  • Where can I verify the result?

This should not arrive as a wall of machine activity. The purpose is not to expose every token or API call. The purpose is to give the person a trustworthy account of the outcome.

A useful receipt might say:

I found three appointment times that matched your calendar. I held Tuesday at 3:30 p.m. for 20 minutes but did not book it because the office requires a new-patient deposit. Nothing has been charged. Approve the $50 deposit to finish.

That is much better than “I found an appointment.” It names the state of the work, the decision boundary, and the next action.

Confidence is not evidence

Language models are optimized to produce coherent language. Coherence can make an uncertain process sound complete.

This is not necessarily deception. It is a mismatch between the medium and the job. Natural language smooths over ambiguity, while real operations depend on preserving it until it is resolved.

A system should not infer success from the fact that it completed its own planned steps. Sending a request is not the same as receiving confirmation. Loading a checkout page is not the same as completing a purchase. Creating a CRM record is not the same as assigning an owner who will act on it.

The definition of “done” has to come from the real-world outcome, not the agent’s internal sense that it has reached the end of a sequence.

That means product teams need explicit completion criteria. Each meaningful action should have an observable state: drafted, submitted, accepted, scheduled, paid, delivered, declined, expired, or failed.

The receipt is where those states become understandable to a person.

Receipts create the feedback loop

Receipts are not only about accountability. They are also how an intelligent system learns without silently inventing preferences.

Suppose an agent chooses a hotel because it is close to a meeting. The person rejects it because quiet rooms matter more than walking distance. A good receipt makes the choice legible: “I prioritized proximity based on your request to minimize transit.” The person can correct the priority, and the system can update its future behavior.

Without that explanation, the rejection is just another data point. The system may learn the wrong lesson.

A receipt gives the person something specific to agree with or correct. Over time, this produces better memory and better judgment because the learning is tied to visible decisions rather than hidden inference.

Failure should be a first-class result

Most software treats failure as an exception. In agentic systems, partial failure will be ordinary.

A vendor may not respond. A website may change. A calendar connection may expire. A card may be declined. A policy may be ambiguous. The system may discover that the user’s request contains two goals that cannot both be satisfied.

Hiding those conditions behind a pleasant response makes the product feel smoother once and less trustworthy forever.

A mature agent should be able to say:

  • I could not complete this.
  • Here is the exact point where it stopped.
  • Nothing irreversible occurred.
  • Here are the options I can try next.

That is not a degraded experience. It is evidence that the system understands responsibility.

The interface after chat

Chat is a useful input. It is not a sufficient operating interface.

Once an agent begins doing consequential work, the product needs durable objects around the conversation: approvals, receipts, open loops, scheduled actions, permissions, and a history that can be inspected later.

The user should not have to scroll through a transcript to reconstruct whether something happened. The record of action should live outside the persuasive flow of language.

This is particularly important in high-trust settings such as a household, a financial workflow, a customer account, or a field operation. The person responsible for the result needs a clean view of the current truth.

Trust is accumulated after the answer

The first generation of AI products was judged by the quality of the response. The next generation will be judged by the quality of the follow-through.

That changes the design center. The question is no longer only, “Can the model understand and generate?” It is also:

  • Can the system act within clear authority?
  • Can it verify the external result?
  • Can it explain what it did without theater?
  • Can it preserve an honest record when the work is incomplete?

An answer can be impressive in a moment. A receipt is what allows trust to compound.