The Assistant Gave the Wrong Refund Answer. Was the Model Really the Problem?

When an assistant gives a customer the wrong refund answer, replacing the model is an understandable suggestion. The words came from the model, after all. But the first mistake may have happened before it started writing.

Consider a system that assigns a question to a product category, searches the material for that category and then asks a model to answer. Each step can work as configured while the customer receives the wrong policy. A more capable answer generator would still be starting in the wrong place.

Here is a fictional example that makes that path visible. The product names and policies below are invented for teaching; they are not consumer-law guidance or the terms of a real business.

The question that took the wrong route

A customer writes:

I bought the Pro upgrade last week, but I haven't activated it. Can I get my money back?

In the example, the purchase record identifies a Pro software license. Its current policy permits a refund within 14 days when the license has not been activated. The catalog also contains a Pro workshop, whose separate policy does not permit cancellation within seven days of the event.

The category selector sees “Pro” and chooses the workshop. Retrieval follows that category, supplies the workshop policy and never sends the software-license rule to the model. The customer then receives a refusal based on the workshop's cancellation deadline.

The assistant has answered the wrong product's question. The current software policy exists; it was simply excluded by an earlier routing decision.

A trace—the recorded inputs and outputs along this path—helps separate a missing source from a misread source. That is a more actionable investigation than asking why “the AI” was wrong. [1][2]

Why I would repair the mapping first

Four proposals could sound reasonable in the incident meeting: upgrade the model, improve the prompt, rebuild the search index or correct the category mapping. The facts of this case do not support them equally.

A better model might help when the correct policy arrives and is misunderstood. A prompt change might improve how supplied evidence is used. Rebuilding the index could help if the policy were missing or stale. Here, the governing policy is available and the wrong category sends the search elsewhere.

I would correct the category selection and keep the model unchanged for the first comparison. That makes it possible to observe whether the proposed cause explains the failure. Changing all four layers might improve the answer while leaving the team unable to say which intervention mattered.

The correction could involve using authorized purchase context rather than guessing from a shared product label. When that context isn't available, asking which Pro product the customer purchased can be more appropriate than silently selecting one. The system still has to respect access controls when consulting a purchase record.

Preserve the awkward wording

It would be easy to replace the customer's question with “Can I return my Pro software license?” and obtain the expected answer. That would make the test easier by removing the ambiguity the live service encountered.

Instead, replay the original wording with the corrected routing. Check that the license policy reaches the model and that the response applies its 14-day and activation conditions faithfully. In this fictional case, a useful answer would explain that the stated circumstances fit the policy while distinguishing eligibility from a refund already being issued.

The person who received the original refusal also needs a correction. Technical diagnosis should not leave the customer waiting while several teams prove which component was responsible.

The neighboring case tests whether the repair is too broad

A customer asking about the actual workshop should still receive the workshop policy. An activated software license should not be treated as unactivated, and an uncertain product should prompt clarification rather than unrestricted access to unrelated records.

Those comparisons help prevent a patch that answers the first complaint by applying one policy to everything. Keeping them with the original case gives later model or prompt changes a concrete behavior to preserve. [1]

If the right policy now arrives and the model still produces the wrong interpretation, work on the model becomes justified. The point is to spend the next hour on the failure the trace identifies, not to defend the existing technology.

An assistant that also executes refunds needs additional authorization and confirmation of the payment result; this article's repair concerns the answer. Solving that narrower problem well gives the team a clearer starting point for any consequential action that follows.