What does Two Turns, Then a Human: Writing an AI Handoff Rule mean in practice?
To write an AI handoff rule, Dr. Jonah Tebaa establishes an automated trigger tracked outside the model's confidence rather than relying on soft guidelines. This control requires configuring two parameters: setting a turn threshold, typically two unresolved turns, and scoping intent categories to high-risk areas like billing disputes, delivery exceptions, and account access. An exchange counts as unresolved if a customer repeats their intent, signals dissatisfaction, or experiences stalling without active information gathering.
Somewhere in every AI-handled support conversation there is a second turn, and before that turn ever arrives, someone has to have already decided what the system does if the problem still isn't solved. Not "the agent will use judgment." A specific rule, written down, wired into the system, that fires whether anyone is watching or not. Most operations don't have one. They have a metric on a dashboard and a vague hope that the bot will figure it out.
I wrote a few weeks ago about why a high deflection rate can coexist with a customer who never got helped — the metric only tells you a human was avoided, not that the problem was solved, and containment rate and deflection rate are the same measurement wearing two vendor labels. That piece argued the measurement case. This one is the operating rule that follows from it: if the metric can't be trusted on its own, you need a trigger that takes the decision out of the metric's hands entirely. That trigger has exactly two parameters, and both are choices someone has to make on purpose.
A Soft Guideline Is Not a Rule
Almost every operation I've looked at has some version of a handoff policy already. It usually lives in a document: "if the AI can't resolve the issue, escalate to a human." The trouble is that it's advisory. It depends on the AI correctly recognizing its own failure, in the moment, with no external check. An AI that is confidently wrong will not flag itself as confidently wrong. A policy that only works when the system correctly diagnoses its own limits is not a control — it's a hope with a sentence attached to it.
A rule, by contrast, is enforced by something outside the conversation. The turn count is tracked independently of the model's own confidence. When the threshold is crossed, the handoff happens automatically, not because the AI agreed it should. This is the difference between a guideline and a rule, and it's the whole reason the number moves or doesn't.
Setting the Turn Threshold
The first parameter is how many unresolved turns the system tolerates before it hands off. Two is a defensible default, and it's the number I come back to most often, but the reasoning matters more than the figure.
Set the threshold too high and you are quietly optimizing for the containment number while the customer repeats the same problem three, four, five times before anyone intervenes. The dashboard looks fine. The customer does not feel fine. Set it too low — at one — and you lose the conversations the AI would have genuinely closed on the second exchange, the ones where it just needed one more clarifying answer. You also flood the human queue with cases that didn't need a person, which degrades response time for the cases that did.
The honest way to think about this parameter is as a comparison of two costs: the cost of a wasted turn against the cost of a wasted escalation. A wasted turn costs the customer patience and costs you a slightly worse repeat-contact number. A wasted escalation costs a human agent's time on something the AI would have solved, and it costs queue capacity for someone who actually needs a person. Those costs are not the same size in every category, which is why the threshold shouldn't be a single number applied uniformly — it should vary by what's being asked.
Choosing the Intent Scope
The second parameter is which intents the rule even applies to. This is the part most teams skip, and it's arguably the more important choice. Not every conversation deserves a hard trigger. A customer asking for store hours or an order-status check is not at risk from a slow AI turn — the AI genuinely resolves those, and a forced handoff there just burns human time on something that didn't need it. The rule should be scoped to intent categories where an unresolved exchange is expensive in a way that compounds if it drags on:
- Billing disputes — money and trust are both on the line, and an unresolved billing conversation has a real chance of ending as a chargeback, which costs far more than one early human turn would have.
- Delivery exceptions — a late, lost, or damaged shipment is a real-world event the AI cannot change no matter how many turns it takes; every additional exchange just delays the actual fix a human has to authorize anyway.
- Account access — a locked-out customer cannot self-serve their way out of the problem, and each additional turn increases fraud-risk exposure on top of the frustration.
- Cancellations inside a contractual window — there is usually a deadline attached, and an AI that stalls past it can create a dispute that didn't need to exist.
Everything outside that list can run on a longer leash, or no hard trigger at all. Scoping the rule this way keeps the human queue reserved for the conversations where a delay actually costs something.
Defining "Unresolved"
None of this works unless "unresolved" is itself defined, because a turn counter with no definition of failure will either fire on everything or nothing. In my work, I treat an exchange as unresolved when the customer repeats the same underlying intent in different words, when they show an explicit dissatisfaction signal, or when the AI's last response didn't move the case forward. I do not count a turn where the AI is legitimately gathering information it needs to solve the problem — asking for an order number is progress, not stalling, and a rule that penalizes it will trigger constantly on conversations that were actually going fine. Getting this distinction wrong is the single most common way teams build a handoff rule that either never fires or fires on everything.
In an illustrative composite drawn from patterns I've seen across mid-size regional retail and e-commerce operations, not a specific client or audited engagement, applying an enforced two-turn rule scoped to a short list of high-risk intents moved the repeat-contact rate on AI-touched conversations from roughly 34% down to roughly 14%. The number is a pattern, not a promise. The rule behind it is the part worth building.
