Escalation and ambiguity resolution

• Good triggers: an explicit request for a human, a policy gap or exception, inability to make meaningful progress.
• Complexity by itself is not a trigger; if the tools and policy cover it, resolve it.
• An explicit request for a human is honored at once, with no investigation first.
• Frustration is acknowledged and met with a fix when the issue is within reach; escalate only if the customer repeats the request.
• Sentiment scores and the model's self-reported confidence are poor proxies for case difficulty.
• When a lookup returns several matches, ask for another identifier; never choose by a heuristic.
• Escalation rules belong in the system prompt as explicit criteria with a few examples of escalate-versus-resolve.

• Write explicit escalation criteria with few-shot examples.
• Recognize policy silence (for example a competitor price match when policy only covers your own prices) as a reason to escalate.
• Handle multi-match lookups with a clarifying question.
• Balance a first-contact-resolution target against an explicit request for a person (the request wins).

• "Angry customers should be escalated." Mood does not track difficulty.
• "Route on the model's confidence score." The score is uncalibrated and misses the hard cases it is confident about.
• "Try to resolve first, always." Not when the customer has explicitly asked for a person.

Options that add infrastructure (classifiers, confidence gates) before the prompt has clear criteria, and options that extend policy by analogy. The proportionate answer is usually criteria plus examples, and the safe answer on a policy gap is to escalate.

• 1.4Workflow enforcement and handoff
• 4.2Few-shot prompting
• 5.5Human review and calibration