Give the customer the reasons that actually decided the outcome, taken from the record, in plain words: the rule that applied, the facts it was applied to, what they can do next, and how to reach a person. Do not ask the model to invent an explanation after the event. If the record cannot produce real reasons, the decision should not have been automated.
Why can't the agent just explain itself?
It can produce fluent text about why it acted, but that text is generated, not retrieved. It may cite a reason that sounds right and was not the one that mattered. For a customer who was refused a refund or had a payment held, a plausible but wrong explanation is worse than none: it misleads them about what to fix.
The real reasons sit in the record of the decision: which bound decided, which facts it read, which rule applied. We argue in the audit trail should explain the decision, not just log it that this record should be built so it can be explained, from the start.
What are the practical steps?
- Record decisions in explainable form. For each verdict, store the deciding rule in plain language as well as code, and the facts it was applied to.
- Map rules to customer wording. Compliance and the process owner approve a customer-facing sentence for each rule. "Refunds above 100 are reviewed by a person" rather than "limit_refund_tier2".
- Draft from the record. The agent drafts the explanation by filling the approved wording with the facts from the record. It does not compose reasons freely.
- Check sensitive cases. Explanations for refusals with significant effects, such as credit decisions, go to a person before sending.
- Offer a route to a person. Every explanation says how to challenge the decision and reach someone who can change it.
- File the explanation. What was sent, to whom, and the record it came from.
What may the agent do, and what stays with a person?
| Situation | The agent | A person |
|---|---|---|
| Routine decision, low effect (e.g. delivery date) | Explains directly from the record | None |
| Refund or fee refused under policy | Drafts and sends the approved explanation | Handles challenges |
| Payment held for checks | Explains that it is held and what happens next, without revealing fraud rules | Releases or refuses it |
| Credit declined | Drafts the reasons from the record | Reviews and sends; handles appeals |
| Account restricted for financial crime reasons | Nothing beyond a holding message | Decides what can lawfully be said |
The last row matters. Some decisions cannot be fully explained to the customer, because doing so would tip off a suspect or reveal how fraud controls work. The agent must not improvise there.
What do the rules require?
Requirements depend on the decision and the market. In the EU and UK, GDPR Article 22 and its UK equivalent give people rights around decisions based solely on automated processing with legal or similarly significant effects, including obtaining human intervention and contesting the decision. In the US, ECOA and Regulation B require specific reasons when credit is denied, including when a model is used. Under the EU AI Act, Article 50 requires that people are told when they are interacting with an AI system. Our guide on explaining a credit decision to an applicant with an AI agent applies this to lending.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
A worked example
Take an online retailer's support agent that refused a customer's request to refund a sofa returned after 40 days. The record shows the verdict was refused, the deciding bound was the retailer's limit (returns accepted within 30 days for large items), and the facts were the delivery date and the return request date.
The agent drafts: "We can't refund this order automatically because large items can be returned within 30 days of delivery, and this sofa was delivered on 2 March and the request came on 11 April. If there's a reason the return was late, such as a fault, reply here and a member of our team will review it." The customer replies that the sofa was faulty from the start. A person reviews and approves the refund.
Which controls make explanations trustworthy?
- Reasons come from the record, never composed freely.
- Approved wording per rule, reviewed by compliance.
- Human review for significant decisions before the explanation goes out.
- A real route to a person who can change the outcome; see how to stop an AI agent from overriding a person's decision for keeping that route effective.
- Reconstruction on demand. If a customer complains, staff can rebuild the decision; see reconstructing an AI agent's decision from the record.
The topic guide, agent governance is a bound, not a model, explains why the verdict, not the model's narrative, is the explanation.
Questions people ask
Should the customer be told an agent made the decision?
Yes. Telling people when they are dealing with an AI system is required in some regimes and good practice everywhere. It also sets up the route to a person.
What if the decision was made by several rules at once?
Give the deciding one first, then any others that would also have applied. The record names which bound decided.
Can the agent explain why it flagged a transaction?
Partly. Our answer on whether an AI agent can explain why it flagged a transaction covers what can be said and what must stay internal.