Building a support triage agent that categorizes and routes tickets is a well-understood problem at this point — the harder, more consequential design decision is the escalation logic: precisely when the agent should stop and hand a ticket to a human rather than handling it or drafting a response itself. Get this boundary wrong in one direction and customers with real, urgent problems get stuck in an automated loop; get it wrong in the other direction and human agents are swamped with tickets the system could have handled safely, defeating the purpose of building the agent at all.

Escalation isn't one rule -- it's several, stacked

A common mistake is building a single escalation rule (usually a confidence threshold on the model's categorization) and assuming that covers it. In practice, real escalation logic needs several distinct triggers, because there are several genuinely different reasons a ticket needs a human, and a single confidence score doesn't capture all of them.

Low confidence in categorization is the most obvious trigger — if the system genuinely isn't sure what a ticket is about, it shouldn't guess and proceed as if it were sure. But this alone misses tickets the system is confidently wrong about, which is arguably the more dangerous failure mode.

Explicit signals of urgency or distress need their own detection, independent of category confidence — language indicating a customer is very upset, mentions of anything safety-related, anything suggesting a legal or regulatory concern. A ticket can be confidently and correctly categorized as "billing dispute" while also containing clear signals that this specific customer needs a human's judgment immediately, and a system that only checks categorization confidence misses this entirely.

Category-based hard rules, independent of confidence. Certain categories should always escalate regardless of how confident the system is — anything involving a safety issue, a legal threat, a request to delete personal data, a payment dispute above a certain dollar value. These are policy decisions, not confidence calibration problems, and they should be encoded as explicit rules rather than left to the model's judgment about whether escalation is warranted.

Important

The most reliable escalation design treats "should a human handle this" as several independent checks that each can trigger escalation on their own, rather than a single blended score. A ticket that passes the confidence check but trips an urgency-language check should still escalate — averaging these signals into one score, rather than treating any one of them as sufficient on its own, is how genuinely urgent tickets slip through a system that looked well-calibrated in testing.

The cost of getting escalation wrong is asymmetric

Failing to escalate a ticket that needed a human (a false negative on escalation) is a much more expensive mistake than escalating a ticket that didn't strictly need one (a false positive). An unnecessarily escalated ticket costs a few minutes of a human agent's time reviewing something the system could have handled. A ticket that should have escalated and didn't can mean a distressed customer stuck in an automated loop, a safety issue that went unaddressed, or a legal matter handled by a system with no authority or training to handle it appropriately. This asymmetry should directly inform where you set thresholds — when genuinely uncertain, the system should lean toward escalating, not toward handling it confidently.

Testing the escalation boundary specifically, not just overall accuracy

When evaluating a support triage agent, don't just measure overall categorization accuracy — specifically test the escalation boundary against a set of real historical tickets that should have escalated (urgent, safety-related, legally sensitive) and confirm the system actually flags them. This is a different, more targeted test than general accuracy, because a system can have excellent overall categorization accuracy while still missing the smaller number of high-stakes tickets that the escalation logic exists specifically to catch — and those are exactly the tickets where a miss is most costly.

Designing the handoff itself, not just the decision to hand off

Escalation isn't just a binary decision — the quality of the handoff matters enormously for how effectively the human agent can actually help. A well-designed escalation includes a summary of what's already been established (what the customer's issue actually is, any relevant account context, why the system flagged this for escalation specifically), so the human agent isn't starting from zero. A poorly designed escalation just dumps the raw ticket on a human queue with no context, which negates much of the efficiency benefit the system was supposed to provide even for the tickets it does hand off correctly.

Monitoring the escalation rate over time as its own signal

Track your escalation rate as a specific metric, separate from overall system accuracy, and watch for meaningful shifts. A rising escalation rate might mean the system is being appropriately cautious as it encounters new ticket types it wasn't tuned for — a healthy signal that the escalation logic is working as designed rather than falsely handling things it shouldn't. A falling escalation rate deserves scrutiny too: it could mean the system has genuinely improved, or it could mean escalation triggers have quietly stopped firing correctly, which is exactly the kind of regression the evaluation discipline discussed elsewhere is meant to catch.

The AI-Powered Customer Experience Engine includes a full worked example of building this exact escalation logic, including a checklist of the specific urgency and risk signals worth detecting independently, and a testing methodology focused specifically on the escalation boundary rather than general system accuracy.