Confidence Routing: How to Sell an Outcome Instead of Hours
The old services model bills for effort. To sell the outcome instead, the system has to know when it does not know — and behave differently when it does. A technical look at the layer that makes agents safe to put in production.
Last time I argued that the hardest part of building AI services is making enterprise data legible, and that the agent is the thin, replaceable layer on top of a much harder foundation. This is about the layer just above that one. It is the difference between an impressive demo and something a business will pay for by the result.
Here is the shift underneath all of it. A traditional services business bills for effort: hours, headcount, time and materials. You sell the work. An AI-native services business wants to sell the result instead — the migrated system, the resolved ticket, the validated dataset — and charge for that rather than for the time it took. That is a much better business. It is also a much harder promise to keep, because the moment you are paid for outcomes, every wrong answer is your problem, not the client's.
So the question that decides whether you can sell an outcome is not "how good is the agent on average." It is "what does the agent do when it is wrong, and does it know."
You cannot just ask the model how sure it is
The naive version of confidence is to ask the model: have it rate its own certainty, or read the token probabilities, and route on that. This does not work, and it fails in the most dangerous way, because language models are confidently wrong. Their self-reported certainty is poorly calibrated, and their token probabilities measure fluency, not correctness. A model will happily assign high probability to a smooth, plausible, completely fabricated answer.
Route on that signal and you will auto-approve exactly the errors that look most convincing. The calibration has to come from somewhere outside the model's own opinion of itself.
What confidence actually is in production
We treat confidence as a composite signal, assembled from sources that are allowed to disagree with the model:
A verifier. A second model whose only job is to check the first one's answer against the evidence, prompted to look for reasons it is wrong rather than reasons it is right. Agreement between a generator and an adversarial verifier is a far stronger signal than either alone.
Self-consistency. Sample the answer several times. If the agent lands in the same place across independent attempts, that stability is evidence; if it scatters, that is a flag, no matter how confident any single run sounded.
Grounding. Is the answer actually supported by the records the agent retrieved, or did it drift off the source? An answer that cites and matches real data beats one that merely reads well.
Rule validation. Cheap, deterministic checks the answer must pass: types, ranges, referential integrity, business constraints. These catch a surprising amount of confident nonsense for almost no cost.
None of these is sufficient alone. Combined, they produce a number that means something, because it is correlated with being right rather than with sounding right.
The routing
Once you have a signal you trust, the behavior is simple to state and hard to tune. Three bands:
High confidence — act. The agent completes the work and moves on. No human touches it.
Medium confidence — review. The work is done but held; a person confirms or corrects it before it takes effect.
Low confidence — escalate. The agent stops and hands the problem to someone, usually with a note on what it was unsure about.
I think of the line between act and review as the trust boundary. Everything above it runs as software. Everything below it is still a service delivered by people, with the agent assisting. The whole game is moving that boundary up, safely, over time.
Setting the thresholds
The thresholds are where the engineering lives, because they encode an economic decision, not just a technical one.
Set the act threshold too low and the agent auto-completes work it should have flagged. You get speed, but errors leak into production and you are paying for them. Set it too high and almost everything routes to a human. The system is safe, but it is barely software, and your margins start to look like a staffing agency's. The threshold is the dial between those two failure modes.
You choose the setting with data, not taste. Run the agent against a labeled set where you know the right answers, and at each candidate threshold you can measure two things: how often an auto-approved answer is actually wrong (the error that reaches the client) and how much work is being sent to humans (the cost that eats the margin). That gives you a curve, and you pick the point on it that matches the cost of being wrong in that specific workflow.
That cost varies wildly, which is why there is no global threshold. An agent suggesting a category for an internal ticket can be wrong sometimes; the cost is a small correction. An agent posting a financial transaction cannot; one wrong auto-action can outweigh a hundred needless escalations. Same architecture, completely different boundary, because the asymmetry between a false act and an unnecessary review is different. You tune to the asymmetry.
The human-in-the-loop earns the agent its autonomy
The reviews and escalations are not only a safety net. They are the training signal. Every time a person confirms, corrects, or overrides an answer, you learn whether the confidence score was telling the truth, and you feed that back.
That feedback is what lets the trust boundary move. As the agent accumulates corrected examples on a kind of work, two things improve together: the agent gets better at the task, and the confidence signal gets better calibrated, so you can safely lower the act threshold and let more run as software. The system becomes more autonomous not by decree but by earning it, one verified batch at a time. Week one, most of a new workflow sits in the review band. Month three, the bulk of it is above the trust boundary and a small team handles the long tail.
Why this is what lets you sell an outcome
Bring it back to the business. A client will not pay for an outcome they cannot trust, and they will not trust a system whose failure mode is silent, confident error. Confidence routing is what makes the failure mode safe: the system does the work it is sure about and visibly flags the rest, so the worst case is a review queue rather than a wrong answer shipped at scale. That is a bounded, inspectable risk, which is the kind a business can actually sign off on.
So confidence routing is not really a model feature. It is the thing that turns "an agent that is usually right" into "a service you can put your name on and bill by the result." The data layer makes the agent possible. The confidence layer makes it sellable.
Next in the playbook: the people. When the agent does most of the work and routes the rest, what is the small human team actually for, and how do you organize it — the pod around the fleet.
— Nikhil