What Should a System Do When It Is Only 60% Sure?

Most AI features return an answer and hide how confident they were. The useful design question is what the product does differently at 60% than at 95%.

Published 2026-10-19 ยท 5 min read

What Should a System Do When It Is Only 60% Sure?

The Label Without The Doubt

A model looks at a user's behaviour and returns a label: likely to cancel, ready to buy, confused by this step. The product receives the label and acts on it.

What usually gets lost on the way is how sure the model was. Internally there was a number. By the time the result reaches the product, it has become a plain statement, and a statement gets treated as a fact.

This is where many AI features go wrong. The model was not badly trained. The product simply responds to a weak guess with the same force it would give to a strong one.

Confidence Changes The Right Action

Take one inference: this person seems unsure about a plan upgrade.

At very high confidence, a direct response is reasonable: show the comparison they keep going back to. At moderate confidence, the same response might be right or might be an interruption, so a lighter touch fits better: make help easy to find and do not push. At low confidence, the honest move is to do nothing and keep observing.

The inference is the same in all three cases. The right action is different in each, and the only thing that distinguishes them is the number the product threw away.

Four Responses, Ordered By Certainty

A simple way to design for this is to give the product more than one way to respond:

1. Act. High confidence, and the action is cheap to reverse. Do it.

2. Offer. Moderate confidence. Make the option visible and let the person choose it.

3. Ask. Uncertain, and being wrong would be costly. A short question is better than a wrong assumption.

4. Wait. Low confidence. Collect more signal before doing anything.

For products with a human team behind them there is a fifth: hand over. Some situations are both uncertain and high-stakes, and those belong with a person.

The Cost Of Being Wrong Matters As Much

Confidence alone does not set the threshold. The cost of a mistake does.

Reordering a help menu on a 60% guess is harmless. If it was wrong, nobody notices. Changing a price, blocking a transaction, or sending a message that reveals an inference about someone is different. For those, 60% is far too low, and even 90% deserves care.

So a threshold is specific to an action. A product should hold a different bar for each thing it can do, set by how reversible the action is and who bears the cost when it is wrong.

What This Looks Like In An API

For a system that supplies behavioural context to other systems, this has a practical consequence: confidence must be part of the response, next to every inference, in a form the consumer can use.

A context object that says "state: comparing options" is less useful than one that says the same thing with a confidence level and the window of evidence behind it. The second lets the consuming application, agent, or decision engine choose how much weight to give it.

This is how Fluence returns context: each trait, state, and intent carries its confidence, and the consuming product stays in control of what to do with it.

A Check For Your Own Product

Pick one AI-driven behaviour in your product and ask three questions:

  • Does the product know how confident the model was, or only what it concluded?
  • Is there more than one possible response, or is it act-or-nothing?
  • What happens to the person on the other side when the guess is wrong?

    • If the answers are "only the conclusion", "act-or-nothing", and "we have not checked", the next improvement is probably not a better model. It is a product that knows what to do with doubt.

    See how behavioural context is returned by the API.