The answer tells you what; the probability tells you whether to act. Here is the three-path pattern (act, confirm, escalate), why thresholds should differ by action, a one-line formula that turns the cost of mistakes into a threshold, and the one thing thresholds cannot protect you from.
Key takeaways
- Use probability as a second axis: the answer says what to do, the probability says whether to do it now.
- Three paths: act automatically, ask to confirm, or escalate to a person or a slower model.
- Thresholds belong to actions, not to the model: a read-only action can go at 0.6, a money transfer may need 0.85 and a confirmation.
- With calibrated probabilities, act when p exceeds cost of a false action ÷ (cost of a false action + cost of a missed one).
- Confidence can't flag inputs the model doesn't understand at all; check that inputs are in scope before you trust the number.
Try it with your agent
Paste this into your coding agent:
For one automated decision in this codebase, write a threshold policy: - list each action it can trigger and estimate the cost of a wrong action vs a missed one (ask me if you can't infer them) - compute each threshold as C_false / (C_false + C_miss) - add a review band that goes to a person or a slower model - add a check that rejects out-of-scope inputs before the decision Put thresholds in named constants with the cost reasoning in comments, and log probability, threshold and action for every decision.
Transcript
Intro
A probability on its own doesn't do anything. Your code turns it into behavior with thresholds. This lesson is about where to put them, and why.
A second axis
Here's the idea in one line, from the TypeSafe docs. Use confidence as a second axis. The answer tells you what. Confidence tells you whether to act.
Three paths
That gives you three paths. When the model is sure, act automatically. When it's fairly sure, ask the user to confirm, or gather more information. And when it isn't, hand the case to a person, or to a slower, smarter model. Watch where each request goes.
Thresholds per action
But one threshold for everything is a mistake. Thresholds belong to actions. In this voice banking example, checking a balance is harmless if it's wrong, so point six is enough. Approving a transfer is not, so it needs point eight five to go through, and anything less gets a spoken confirmation. And below point six, nothing happens without a person.
A threshold from costs
Where should a threshold sit? There's a formula, from decision theory. If acting on a false yes costs C false, and missing a true yes costs C miss, act when the probability is above C false divided by C false plus C miss. It assumes the probability is calibrated, which is why lesson nine came first.
Two examples. Auto-approving a refund that wasn't owed costs you forty dollars, and making a real refund wait for review costs about ten. Forty over fifty: act above point eight. Now a safety report. A false alarm costs a minute of someone's time, a missed one could cost a hundred times more. One over a hundred and one: flag anything above about point oh one.
Developer Daniel Sam put the attitude well. Fifty percent is a coin toss you ignore. Ninety five percent is a bet you take. Thresholds should scale with the cost of being wrong.
Who owns the threshold
Some see this as a catch. Armin Ronacher put it as delegating the hallucination problem a little bit to the user. He's right, and that's the deal. The threshold is a business decision, and now it's yours: written in code, readable, and changeable in one line.
What thresholds can't catch
One thing thresholds can't do. The author of Laya, an open decision model, fed its English model text in other languages. Accuracy collapsed, all the way to zero on some, but its average confidence never dropped below point eight eight five. A model can be confidently lost. Check that inputs are in scope before you trust the number.
Quick check
Quick check. Wrongly auto-closing a ticket costs nine times more than sending a closable ticket to review. With calibrated probabilities, where should the auto-close threshold be?
Try it
Try it. Have your agent write the threshold policy for one decision, with the cost reasoning in the code.
Recap
So: the answer says what, the probability says whether. Act, confirm, or escalate. Give every action its own threshold, set by what mistakes cost. And check that inputs are in scope, because a model can be confidently lost. Next: how much can you automate, and how to pick thresholds from data.