Quick answerAnswer a curious 'why did you say that' with a short, honest, one or two sentence account of the main factor behind the response, not a full reasoning trace and not a deflection. Most customers asking this question are not contesting a decision or building a case, they are curious in the moment, and a brief, genuine answer satisfies that curiosity better than either an evasive non-answer or an overwhelming dump of internal reasoning steps that reads as more confusing than transparent.
This is a different moment than an affected customer disputing a decision
A customer wanting to know why the agent made a specific decision that affected them is a higher-stakes moment: something happened to that person, a charge, a denial, a change, and they need a real accounting of the specific factors behind it, potentially including a path to dispute it. This post is about a different, much more common moment: a customer mid-conversation, nothing adverse has happened to them, who simply asks something like "how did you know that" or "why did you phrase it that way" out of ordinary curiosity.
Treating both moments identically leads to two different failure modes. Treating the curious question with the same weight as a formal decision dispute produces an over-engineered response that feels bureaucratic for a casual question. Treating a genuine decision dispute as casual curiosity under-serves a customer who actually needed a real accounting.
Why brief and honest beats both extremes
Companies tend to default to one of two bad answers here. The evasive default, "I'm just an AI assistant, I don't have a way to explain that," is technically dodging a question the system usually can answer at some level, and it reads to customers as either unhelpful or hiding something, neither of which is accurate but both of which erode trust. The opposite default, walking through a full internal reasoning trace unprompted, buries a casual question in detail nobody asked for and often exposes internal system mechanics that were never meant to be customer-facing content.
The middle path works better than either: name the one or two main factors that actually drove the response, in plain conversational language, and stop there. If the customer wants more depth after that, they will ask a follow-up, and the agent can go one level deeper at that point, rather than front-loading everything into the first answer.
Where the line is: how much depth is appropriate by default
Default depth should cover the primary input or reasoning factor, what specific thing in the conversation or the customer's data led to this particular response, without exposing implementation detail like model names, prompt structure, or internal confidence scores. Those details are not what a curious customer is actually asking for, and surfacing them by default adds noise without adding the kind of understanding the customer wants.
When curiosity turns into something that needs the heavier process
If a follow-up question reveals the customer is not just curious but actually contesting or disputing what the agent did, treat that as a handoff point into the decision-explanation process rather than continuing with the lightweight conversational answer. The signal to watch for is the customer describing an actual negative outcome or asking how to change or appeal what happened, not just how it happened.
This is not the auditor-facing bar either
Explaining an AI agent's reasoning to an auditor or a skeptical enterprise buyer is a formal, documentation-grade explainability requirement aimed at a professional evaluator, with a completely different depth and format than a conversational answer to an end customer. Do not build one system to serve both audiences with the same output, the auditor's bar is much higher and the casual customer's bar is much lower, and forcing one format to serve both under-serves at least one of them.
FAQ
What if the honest answer would reveal something the company would rather not surface, like an A/B test the customer is in? Being in a test does not require naming it as such, but the answer given should still be genuinely accurate to what drove that specific response, not a fabricated explanation designed to hide the real one. Honesty about the reasoning factor and disclosure of internal experimentation infrastructure are separate questions.
Should the agent ever say "I don't know why I said that"? Only if it is true. If the system genuinely cannot reconstruct the reasoning behind a given response, saying so honestly is better than fabricating a plausible-sounding explanation, but this should be rare enough to flag internally as a logging gap when it happens, not treated as an acceptable steady state.
Does this apply the same way across every channel, voice and text alike? The content of the answer should be consistent, but on voice the response needs to be even more concise than on text, since a customer cannot skim a long spoken explanation the way they can skim a written one.