The Threshold Is a Price, Not a Percentage

have a line like ESCALATION_THRESHOLD = 0.90. Above it, the agent acts. Below it, a human gets pinged.

It’s simple. It’s tunable. It lets everyone feel like autonomy is under control.

But it’s not the right solution.

The fix isn’t a better number. The fix is noticing that the escalation threshold was never a percentage in the first place. It’s a price.

Start with the wrong question

Most teams ask a capability question. Can the agent write the SQL? Can it issue the refund? If yes, let it run.

But being able to do something and deciding to do it alone are different issues. The second is really about the decision itself: What does a mistake cost, and what does it cost to involve a human instead?

That’s the real choice. If the agent acts, you risk the cost of a mistake. If you escalate, you pay for a human’s time, whether the agent was right or not.

Put numbers on it and the comparison is almost embarrassingly simple. One assumption first: the human gets escalated tickets right. We’ll relax that later. For now, act alone when:

(1 - p) * cost_of_error  <  cost_of_escalation

where p is the probability the agent is correct. Rearranged, escalate whenever:

p  <  1 - (cost_of_escalation / cost_of_error)

That value on the right is the real threshold. Notice what it depends on. Not the model. Not a policy from a workshop. Just a ratio between two costs. If errors are cheap, the threshold is lower and the agent can act more often. If errors are expensive, the threshold is higher, and even a confident agent should ask for help.

A fixed cutoff assumes that ratio is the same for every decision the agent will ever face. That’s rare.

This approach is based on Chow’s rejection rule from 1970, which is the foundation of today’s learning-to-defer research. Old ideas age well when they’re right.

Two tickets

The easiest way to show it: support-ticket triage. An agent reads incoming tickets and either resolves them or routes them to a person. The numbers here are invented for the argument, but they hang together.

A routine refund request. Small amount, clear policy. If the agent botches it, the cleanup is a follow-up ticket and a goodwill credit. Call it £15. Escalating burns about three minutes of a specialist’s time. Call that £4.

The threshold comes out at 1 minus 4/15. About 0.73.

So if the agent is 90% confident, it should clearly act. Escalating would spend £4 to avoid only £1.50 of expected error. When you say it out loud, no one would make that trade, but a fixed cutoff does it automatically all day.

Now a possible account takeover. A customer reports a password change they didn’t make. If the agent treats this as routine, the downside isn’t a credit. It’s fraud loss, remediation, regulatory exposure, a customer who never comes back. Put a conservative £2,000 on it. Escalation still costs £4.

The new threshold is 1 minus 4/2000, or 0.998. In practice, this means you should always escalate. At 90% confidence, letting the agent act alone risks £200 in expected cost, compared to just £4 to escalate. It’s fifty times cheaper to hand it over.

Same agent. Same 90%. Opposite correct answers. The 90% rule says act in both cases, and in the second one it quietly burns £196 per ticket to save someone three minutes.

That observation usually lands in conversation.

One honest wrinkle. The example assumes the agent knows which ticket it’s holding. In real triage, that’s the uncertainty. If the agent is 90% sure a ticket is a routine refund, part of the remaining 10% could be a takeover in disguise. So weight the error cost across what the ticket might be, not what it probably is. When in doubt, price it as the worst plausible class. Cheap-looking tickets are exactly where expensive mistakes hide.

The catch

All of that arithmetic leans on one assumption. When the agent says 90%, it’s right about 90% of the time.

That’s calibration, and it’s not the same thing as confidence. Confidence is a number the model emits. Calibration is whether the number means anything.

Feed that into the rule and watch it break. If stated 0.95 really means 0.70, your expected error cost is six times what the arithmetic claims. The threshold you priced so carefully is fiction. You’re not managing risk anymore. You’re laundering it through a number that looks like a probability but isn’t one.

So before any of this, check the number. Log every decision with its stated confidence. Bucket by confidence band, per decision class. Compare stated against realised accuracy in each bucket. If the agent says 90% and hits 78%, you’ve found your correction: map one to the other before anything touches the threshold. Isotonic regression or Platt scaling will do the fitting.

Two details bite here. Agents are often worst calibrated on the rare, high-stakes class, precisely because it’s rare. That’s the class carrying your extreme threshold, so a global average hides the failure that matters. And the map drifts as ticket mix shifts, so re-measure it on a schedule. The technique matters less than the habit. Until you’ve measured the gap, no threshold has earned your trust.

The rule in code

Here it is as a teaching toy. A few lines to make the structure visible, not something I’ve built or shipped.

def should_act_autonomously(stated_confidence: float,
                            cost_of_error: float,
                            cost_of_escalation: float,
                            calibrate) -> bool:
    """
    Teaching toy: act alone or escalate, by expected cost.

    `calibrate` maps stated confidence to a measured
    probability of being correct, built from logged
    decisions and realised outcomes.
    """
    p_correct = calibrate(stated_confidence)

    expected_cost_of_acting = (1 - p_correct) * cost_of_error
    expected_cost_of_asking = cost_of_escalation

    return expected_cost_of_acting < expected_cost_of_asking

There’s nothing fancy inside the function. What really matters is how you choose the three inputs. That’s where your effort should go, rather than arguing about whether the magic number should be 0.85 or 0.92.

Where the numbers get messy

Two factors make the inputs more complicated.

Escalation cost isn’t just minutes times salary. Escalations pile into a queue, and queues congest. Worse, over-escalation trains reviewers to rubber-stamp. Send someone forty routine refunds an hour and within a week they’ve stopped reading them. A human who approves everything isn’t a control. It’s a ritual. So the marginal escalation costs more than it looks, and the gap widens with volume.

And remember the assumption we parked earlier: the human gets it right. Often they don’t. Give the specialist an error rate h and the rule becomes act when (1 − p) × error cost is less than escalation cost plus h × error cost. Usually h is small enough to ignore. On genuinely ambiguous tickets it isn’t, and it tilts the threshold back towards the agent. That surprises people.

Neither of these issues changes the overall approach; they just affect the numbers. That’s the benefit of using a numerical method.

Doing this for your own agent

The procedure is short.

First, group the agent’s decisions into classes where the cost of a mistake is about the same. For example, put refunds in one class and security incidents in another. If you can’t estimate the cost of a mistake for a class, it’s not ready for autonomy yet. In fact, figuring this out is a valuable part of the process.

Then price each class. Talk to the people who clean up the mess, not just the people who built the agent. Finance and support ops know these numbers better than engineering does, and they’re usually delighted someone finally asked.

Also, estimate the cost of escalation, including the effects of congestion and rubber-stamping.

Use the corrected probability in your rule, not the raw score.

Last step: derive the threshold per class from the cost ratio, and let it move when costs move. A new fraud pattern raises the price of a security mistake, so that threshold rises with it. No meeting required, because it’s derived rather than decreed.

In the end, your agent will have several thresholds, not just one. It will have more autonomy where mistakes are cheap, and much less where mistakes are costly. The model and the comparison stay the same.

And that’s the honest answer to the question everyone starts with. “How confident should my agent be before it acts alone?” can’t be answered, because it’s underspecified. “What does a wrong call cost here, and what does asking cost?” can. Set the threshold as a price. The percentage sorts itself out.