5.2 Escalation & Ambiguity Resolution

A reliable agent isn't one that tries to handle everything — it's one that knows its limits and hands off at the right moment. Task Statement 5.2 is about escalation: deciding when an agent should resolve a request itself versus pass it to a human, and how to handle ambiguous situations like not being sure which customer you're talking to. Get escalation wrong in either direction and you fail: escalate too eagerly and you frustrate customers with needless handoffs; escalate too rarely and the agent bungles cases it should have passed on.

The reason this is hard is that the OBVIOUS escalation signals are the wrong ones. It feels natural to escalate when a customer sounds frustrated, or when the agent feels unsure. But — as you'll see — those signals are unreliable proxies for whether escalation is actually warranted. The signals that DO warrant escalation are more specific, and learning to distinguish them is the heart of this lesson.

There are three valid triggers for escalation and two tempting-but-unreliable ones. Plus a specific ambiguity case — multiple customer matches — that has a clear right answer. Let's separate the real signals from the false ones.

Escalation is warranted in exactly three situations, and each has a nuance. FIRST, an explicit customer request for a human — and this one you honor IMMEDIATELY, without first trying to investigate or resolve. If someone says 'I want to speak to a person,' attempting to handle it yourself anyway is the wrong move; escalate at once. SECOND, a policy exception or GAP — crucially, this means the policy is SILENT or ambiguous on the customer's specific request, NOT merely that the case is complex. If your refund policy addresses your own-site prices but says nothing about matching a competitor's price, that's a policy gap: escalate, because there's no answer for the agent to apply.

THIRD, an inability to make meaningful progress — but with a condition: the agent should have demonstrated a real attempt first, not given up prematurely. 'I tried X, Y, and Z and none resolved it' is a valid escalation; 'this seems hard, escalating' is not. The distinction between these three valid triggers and the two false ones (next) is exactly what the exam tests.

Now the false signals, both of which feel intuitive and both of which the exam flags as wrong. The FIRST is sentiment-based escalation: detecting that a customer is frustrated and escalating on that. The flaw is that frustration does NOT equal complexity. A customer can be furious about a dead-simple problem the agent can fix in one step — escalating just because they're upset wastes a human and delays the easy fix. Conversely, a calm customer can have a genuinely complex policy-gap case. Sentiment is orthogonal to whether escalation is actually warranted.

The SECOND false signal is self-reported confidence: having the model rate its own confidence and escalate when it's low. You've met this calibration problem in Domain 4 — model self-confidence is poorly calibrated, so it's an unreliable trigger. The agent is often confidently wrong on hard cases (so it WON'T escalate the ones it should) and hesitantly right on easy ones. Routing escalation on a miscalibrated signal escalates the wrong cases.

There's a useful nuance that combines sentiment with the valid triggers: if a customer is frustrated but the issue is within the agent's capability, the right move is to ACKNOWLEDGE the frustration and RESOLVE it — escalating only if the customer then REITERATES that they want a human. So sentiment isn't ignored entirely; it's just not, by itself, an escalation trigger. An explicit human request from the start, though, escalates immediately regardless of sentiment.

A specific ambiguity case has a clear right answer the exam tests: when a customer lookup returns MULTIPLE matches (two people with the same name, say), what should the agent do? It must ask for ADDITIONAL IDENTIFIERS — an email, an order number, a postal code — to disambiguate. It must NOT pick one by a heuristic like 'the most recent' or 'the most active account,' because guessing wrong means acting on the wrong person's account — a serious privacy and correctness failure. When identity is ambiguous, ask; never guess.

Finally, the meta-lesson for FIXING poor escalation behavior. If an agent's escalation calibration is off — say it resolves only 55% of cases first-contact, escalating easy ones while bungling hard ones — the best fix is the cheapest effective one: add EXPLICIT escalation criteria plus few-shot examples to the system prompt, demonstrating when to escalate versus resolve. This is prompt optimization, and you try it BEFORE building heavier machinery like a sentiment model or a trained classifier. It's the same 'explicit criteria + few-shot first' instinct from Domain 4.1 — sharpen the prompt before adding infrastructure.

The 5.2 traps test the valid-vs-unreliable triggers, the ambiguous-match rule, and the prompt-first fix. The signature scenario: an agent at 55% first-contact resolution escalates straightforward cases while mishandling complex ones.

You now know the three valid triggers, the two unreliable ones, the ambiguous-match rule, and the prompt-first calibration fix. The exercise has you encode escalation criteria and test the tricky boundary cases.

Escalation is about handing off to humans well. The next lesson, 5.3, is about handing off ERRORS well — how failures should propagate through a multi-agent system so the coordinator can recover.