Honest Uncertainty
The best agents know what they don't know.
There's a problem with building systems that are supposed to be smart. The smarter they look, the more dangerous they are when they're wrong.
An agent that says "I don't know" doesn't look smart. It looks broken. So you build systems that will always give you an answer, even when they shouldn't. The system becomes confident about things it has no business being confident about. It fills in gaps. It guesses. And because it's an agent (or an LLM, or a model), the guess comes wrapped in a tone that sounds like knowledge.
That's worse than being honest about uncertainty. Much worse.
Why confidence is a trap
Confidence is seductive. When a system gives you an answer without hedging, you want to trust it. The human brain treats confident delivery as a signal of accuracy. We're wired to believe the person who says "I'm sure" over the person who says "I think, but I'm not certain." That wiring made sense when people were making the claims and their reputation was on the line. It breaks down when the confident voice is a system that has no reputation to lose.
When an agent is confident, you're more likely to act on its output. You're more likely to skip the verification step. You're more likely to assume the work is done. And if the confident answer is wrong, you find out too late, after you've already committed to a decision based on it.
Uncertainty, on the other hand, requires work. If an agent says "I'm not sure," you have to decide what to do with that. Do you dig deeper? Do you ask a human? Do you change your approach? You can't just move on. The uncertainty forces you to engage.
That's not a bug. That's a feature.
What honest uncertainty looks like
Honest uncertainty is not the same as low confidence in an otherwise confident answer. Low confidence is "here's my guess, but I'm not very sure." Honest uncertainty is "this is not a domain where I can be sure. Here's what I found, here's what I don't know, and here's why the gap matters."
There's a difference between those two things.
Low confidence in an answer means the system has an answer but doesn't trust its own answer. That's contradictory. If the system doesn't trust the answer, why should you?
Honest uncertainty means the system is telling you: "Here's the shape of the problem. I can see these parts clearly. These other parts are outside my visibility, and I'm flagging that." The human can then make a judgment call. Do the visible parts matter enough to act on? Is the invisible part something you can tolerate not knowing? Can you find the missing information elsewhere?
That's the conversation you want to have.
How Brief approaches this
Brief's output rubric gate runs an LLM evaluation on agent suggestions. That evaluation doesn't just check "is this good?" It checks "does this match the requirements?" The distinction matters. A suggestion can be technically sound but still not match what you asked for. When that happens, the gate can flag it.
But the gate doesn't hide uncertainty when it works. The gate doesn't try to fix the suggestion to make it match. The gate does what an honest system should do: it says "this doesn't fit" and withholds it. However, the gate fails open: if evaluation times out, the budget exhausts, or all passes are skipped, the output ships unchecked and unflagged. That's the honest limitation: the gate is not a guarantee, it's a check that can fail.
The review queue does something similar. It surfaces suggestions for human judgment, but it doesn't present them as "things we're confident you should do." It presents them as "things we flagged for this category that you should look at." The judgment happens at the human layer, where it belongs.
Neither of these is a system saying "I don't know." But both are systems that refuse to pretend to certainty they don't have (when they can check). They flag where the uncertainty is and let the human decide what to do with it. And both are honest about what they cannot guarantee.
That's honest uncertainty in practice.
The cost of false confidence
False confidence costs more than you think. There's the obvious cost: wrong decisions made based on confident wrong answers. But there's also the hidden cost of trust erosion. The first time an agent confidently gives you an answer that turns out to be wrong, you stop trusting the system entirely. You start verifying everything. You second-guess every output. And now the system is slower and more expensive because you don't believe it anymore.
Honest uncertainty doesn't have that problem. If a system says "I don't know" and you find out it was right to say that, you trust the system more. If a system says "here's what I found, and here's what I missed," and the missed part turns out to matter, you respect the system for being honest about the limitation.
The cost of false confidence is your own judgment, deferred to a system you should have questioned. The cost of honest uncertainty is work, upfront, on your terms.
The tradeoff is easy to get wrong, but it's the right one to make. And the systems that get it right are the ones that know their own limits and tell you what those limits are. They don't pretend to certainty. They admit what they don't know. And they let you decide what to do with that honesty.
How would your decisions change if every system you relied on was honest about its uncertainty?
Frequently asked questions
Can't you just give me a confidence score instead? A number between 0 and 1 doesn't actually tell you why the system is uncertain. Is it uncertain because the data is ambiguous? Because the question is outside its training? Because the domain is inherently hard to judge? Different reasons for uncertainty require different responses. Honest uncertainty tells you the reason. A score tells you how much the system doubts itself, which is not the same thing.
Doesn't honest uncertainty slow things down? Yes. The system has to explain what it doesn't know, and you have to decide what to do with that information. That's slower than just taking the confident answer. But the speed of a wrong decision is not the speed you should be optimizing for.
What if I need an answer even if the system is uncertain? Then you make the decision to go with the uncertain answer. You know it's uncertain. You're not being lied to about the confidence level. You can make that choice with your eyes open, and you can plan for the fact that you might be wrong.
Isn't "I don't know" just the system giving up? Not if it explains why. "I don't know the current inventory level because the API returned a timeout" is not giving up. "I can't verify this person's identity because the documentation is ambiguous on this type of credential" is not giving up. Those are honest assessments of what the system can and can't do. Giving up would be pretending to know anyway.
How do you know when to trust honest uncertainty? The same way you know when to trust any system: you test it. You send it problems where you know the answer. You see if it says "I don't know" when it should, and if it explains the gap accurately. If it does, you know it's being honest about what it doesn't know. If it doesn't, you know to verify everything.
← Back to Blog