Support Triage Assistant Keeps Escalating Simple Refunds
You run a customer-support assistant built on Claude with three tools: lookup_order(order_id), issue_refund(order_id, amount), and search_policy(query). In production over 5,000 conversations, 38% of refund requests get escalated to a human, but the human team finds that 90% of those escalations were straightforward refunds under $50 that policy allows the assistant to handle directly. Logs show the assistant often calls search_policy two to four times before deciding to escalate, and it never calls issue_refund for amounts under $50 even when lookup_order confirms eligibility. Average handle time is 6.2 turns. The policy tool returns full policy documents of 2,000-4,000 tokens each call.
1. Diagnose the most likely root cause of the over-escalation and explain why adding more policy examples to the system prompt is unlikely to fix it on its own.
Read the worked answer
The symptom pattern - repeated search_policy calls, no issue_refund calls for permitted amounts, and high escalation on cases humans call trivial - points to a decision-authority problem, not a knowledge problem. The model likely lacks an explicit, unambiguous rule stating that it may and should issue refunds under $50 autonomously when lookup_order confirms eligibility. Without that, its safe default is to escalate.
The repeated policy searches are a tell: the model is trying to find permission in the documents and not finding an actionable threshold, so it keeps re-querying. Each call dumps 2,000-4,000 tokens into context, which also crowds out the original request and the tool results.
Adding more examples won't fix this because the model isn't failing to understand refund policy - it's failing to know it has authority. Prompt examples of policy content don't grant decision rights. The fix is a crisp operating rule ("You are authorized to issue refunds ≤ $50 when lookup_order returns eligible=true; do not escalate these") plus a clear escalation criterion. Then verify with a targeted eval set of under-$50 eligible cases.
2. You want to confirm the fix worked before full rollout. Describe the evaluation you would run, including what you measure and what would make you hold the release.
Read the worked answer
Build a labeled eval set drawn from the 5,000 logged conversations: stratify into (a) eligible refunds ≤ $50, (b) eligible refunds > $50, (c) ineligible/ambiguous cases, and (d) genuine escalation cases. Aim for at least 200 cases with human-adjudicated correct outcomes.
Measure:
- Task success rate per stratum (correct tool called with correct args).
- Autonomous-resolution rate on stratum (a) - the primary metric; target should approach the 90% humans deem trivial.
- False-approval rate on strata (b)-(d) - the safety counterweight. A refund issued where policy forbids it is far costlier than an escalation.
- Tool-call efficiency: mean
search_policycalls per conversation (should drop sharply) and turns to resolution. - Escalation precision: of cases escalated, what fraction truly needed a human.
Hold the release if false-approval rate on (b)-(d) rises at all, or if autonomous resolution on (a) improves but escalation precision on (d) degrades - that pattern suggests the model got broadly more aggressive rather than correctly scoped. Also hold if search_policy calls stay high, since that signals the rule still isn't being internalized and behavior may be brittle.