안티 패턴: 감정 및 확신 점수

When you build a Claude agent that handles real users, one question dominates: when do we hand off to a human?

A seductive idea appears early: "Let the model tell us how it feels." Ask Claude to rate its own confidence 1-10, or run a sentiment classifier on the customer's tone, and escalate when the number crosses a line.

It feels data-driven. It is actually one of the most common anti-patterns on the certification exam. This lesson shows you why, and what to do instead.

Escalation should fire on observable, verifiable facts about the conversation, not on a vibe.

The exam recognizes exactly four good escalation triggers:

• Explicit human request — the user asks for a person. Escalate immediately.
• Policy gaps — the situation falls outside what the agent is allowed to resolve.
• No progress after attempts — repeated tool calls or turns yield nothing.
• Threshold violations — a concrete, defined limit is crossed (e.g. refund amount).

Each of these is grounded in something you can point to in the transcript or the data.

Now the flip side. The exam lists triggers you must never use as the basis for escalation:

• Sentiment analysis — escalating because the message "sounds angry."
• Model self-rated confidence — a 1-10 score Claude assigns to itself.
• Untrained classifiers — ad-hoc mood/intent detectors with no validated ground truth.

These share one fatal flaw: they are not grounded in verifiable state. They are guesses about an internal feeling, dressed up as a metric.

A self-rated 1-10 confidence score has no calibration. The model is not measuring anything external — it is producing a plausible-looking number on demand.

The same answer might get an 8 in one phrasing and a 4 in another. The score does not correlate reliably with correctness, so an escalation threshold built on it is arbitrary noise.

Contrast this with a real reliability practice from the fact sheet: field-level confidence calibrated on a labeled validation set before automating. Calibration against ground truth is rigorous; a model grading its own homework is not.

Sentiment-based escalation routes on the customer's mood instead of their request. That is the wrong variable.

A calm user may have a hard, out-of-policy problem that genuinely needs a human. A frustrated user may have a trivial, fully solvable request. Mood and resolvability are not the same axis.

Worse, naive sentiment detection is itself an untrained classifier — brittle to sarcasm, politeness, and phrasing. You would be stacking one unreliable signal on top of another and calling it a policy.

Emotion is not irrelevant — it is just not an escalation trigger. The exam prescribes a specific three-step pattern for an upset user:

• Acknowledge the emotion.
• Propose a concrete solution.
• Escalate only if the request is reiterated — i.e. the user explicitly insists or asks for a human.

So you respond empathetically and try to solve the problem first. The handoff happens on the explicit reiterated request, which is a verifiable event, not on the sentiment score that detected the frustration.

The reliable way to escalate is to wire it to concrete state and explicit thresholds, enforced where it matters.

In the Customer Support scenario, you expose an escalate_to_human tool alongside get_customer, lookup_order, and process_refund. The model decides to call it based on the four good triggers — not on a mood reading.

For anything with financial, legal, or safety consequences, you do not trust the prompt alone. You enforce it deterministically.

Why a hook and not a sentence in the system prompt?

The fact sheet is blunt about this: hooks are 100% deterministic; prompts are ~90% probabilistic. When a wrong escalation (or a missed one) has financial, legal, or safety consequences, ~90% is not good enough.

A self-rated confidence threshold lives entirely inside the probabilistic layer — it can drift, be re-rated, or be talked around. A threshold violation enforced by a hook (e.g. refund > $500 always routes to a human) is a guarantee. Reserve hard code for guarantees; keep model-driven judgement for everything softer.

"No progress after attempts" sounds fuzzy but is actually concrete: it is grounded in observable loop state, not feelings.

You count real attempts — tool calls that returned no usable result, turns with no forward movement. That is a fact about the transcript, the same way stop_reason is a fact about the response.

Critically, note the difference from the anti-patterns: an iteration cap here is a safety net for a genuinely stuck loop, never a confidence dial. You are escalating because nothing worked, which you can prove, not because the model rated itself unsure.

A frequent trap: treating an empty or ambiguous result as "the model is unsure, so escalate."

The fact sheet draws a sharp line. Distinguish:

• an access FAILURE (the lookup errored — maybe retry the transient fault locally), from
• a valid EMPTY result (the query ran fine; there are simply no matches).

And for ambiguity — multiple customer matches — the correct move is to ask for more identifiers, never guess, and never escalate on a fabricated confidence drop. The right signal is the structured outcome of the tool, not a sentiment or self-score wrapped around it.

An architect-grade escalation policy reads like this:

• Escalate on explicit human request, policy gaps, no progress after attempts, and threshold violations — all verifiable.
• For upset users: acknowledge, propose a solution, escalate only on reiteration.
• Enforce consequential thresholds with hooks, not prompt text.
• Never route on sentiment, a self-rated 1-10 confidence, or an untrained classifier.

The throughline: escalate on facts you can point to, and reserve deterministic code for the guarantees that matter.

A scenario-style question on escalation design.

Key takeaways:

• Escalate only on verifiable triggers: explicit human request, policy gaps, no progress after attempts, threshold violations.
• Never escalate on sentiment, a model self-rated 1-10 confidence score, or untrained classifiers — they are not grounded in real state.
• For emotion: acknowledge → propose a solution → escalate only if the request is reiterated.
• Distinguish an access failure from a valid empty result; for ambiguous matches, ask for more identifiers, don't guess.
• Enforce consequential thresholds with hooks (deterministic), not prompts (~90%). Reserve hard code for guarantees.

Design escalation around facts you can point to — and you will pass both the exam and production.