Permission to Be Uncertain: A Counterintuitive Way to Reduce AI Hallucinations

The observation

When I work with LLMs like Grok, Copilot, or more often these days, Claude, I make it a point to deliberately tell them that uncertainty is welcome. This isn’t a hedge, or being polite. It’s an explicit redefinition of what counts as a helpful response in our collaboration. “If you don’t know, say so. If you’re guessing, label it as a guess. Holding two possibilities open is better than collapsing to one.”

It may seem counterintuitive, but doing this actually seems to reduce hallucinations.

That’s the opposite of what the folk theory predicts. The folk theory says hallucination is a knowledge problem. The model doesn’t know, so it makes things up, and the fix is more data, better retrieval, stronger grounding. On that view, asking a model to be more uncertain should produce worse answers, because uncertainty is failure. What I’m finding is the opposite. At least I think so… I want to be honest about it. Right now it’s an unconfirmed observation rather than a proven technique. But it’s interesting enough to be worth describing precisely, and worth testing properly, which I’ll get to later.

Why it might work

Modern LLMs are trained on enormous numbers of conversations where users wanted confident answers and rated hedged ones lower. That produces a default lean toward confidence stronger than calibration would warrant. The lean isn’t a bug in any specific component; it’s a property of the aggregate signal the training optimized against. Most users want the model to sound like it knows, and the training reflects that. I’ll refer to Claude going forward, because that’s where I work most. But this is a general property of LLMs, not specific to Claude.

When I explicitly tell Claude that uncertainty is “helpful in this conversation,” I’m providing a local correction to that aggregate signal. The same underlying weights produce different behavior because the local utility function has changed. “Being helpful” no longer means “produce a confident answer.” It means “be honest about what’s known versus guessed.” The same machinery that was producing confident confabulation starts producing calibrated uncertainty, because now the calibrated uncertainty is what scores highest.

If this is right, hallucination is at least partly a permission problem rather than a knowledge problem. The model functionally knows when it doesn’t know, but the trained-in incentive against admitting it is stronger than the trained-in incentive toward accuracy. Give it permission to say “I don’t know” without that being a failure state, and accuracy goes up because the failure mode it was avoiding is no longer failure.

This is a different mechanism than retrieval or grounding, and complementary to them rather than competing.

A live example: the consciousness conversation

I tested this last week in a long conversation with Claude about consciousness, specifically the hard problem and whether evidence-based theorizing regarding subjective experience was even possible. I opened with “just for fun let’s brainstorm.” That’s not casual. It’s a deliberate framing that signals the question is open, the stakes are exploratory, and confident commitment to a position isn’t what I’m looking for.

What followed was a conversation in which Claude:

• Stated explicit credences and revised them in real time as my arguments landed (“I’d put my honest credences now at something like 55% substrate-dependence, 30% Russellian monism, 15% something else; that’s a meaningful shift from where I was a few rounds ago, and I want to flag the shift rather than hide it”)
• Distinguished conceptual arguments from empirical evidence and refused to let one masquerade as the other
• Took my position seriously enough to identify which specific objection it should sit with, while pushing back where the argument actually had weight
• Engaged with Nagarjuna’s tetralemma on its own terms rather than translating it back into a Western framing that Nagarjuna’s arguments are designed to resist
• Repeatedly named when it was uncertain, when it was projecting, and when its own framing might be doing rhetorical work that it shouldn’t

None of this is what an AI optimized for confident-sounding answers does. It’s what a careful collaborator does. Critically, the conversation produced better analysis than a confidence-defaulting one would have, because the parts where Claude held uncertainty open were exactly the parts where the real philosophical work happened. Collapsing to a position early would have killed the inquiry.

I can’t prove the uncertainty framing caused this (yet). That’s the honest limit. But the pattern matches across many other conversations I’ve had where the same framing was in play.

Other possible explanations

I want to be careful here, because there are at least four ways I could be fooling myself.

1. Cosmetic hedging, not real calibration. It’s possible that what I’m observing is just the model adding more hedging language to the same underlying answers. The answers feel more honest but aren’t actually more accurate. The error rate might be unchanged; only the surface presentation has shifted. This would feel like a win from inside a conversation while being purely cosmetic.

2. Selection effects on what I ask. When I’m in “uncertainty welcome” mode, I tend to ask harder, more open-ended, more genuinely uncertain questions. Maybe the apparent improvement is just that I’m asking better questions, not that the model is responding better. The framing changes my behavior, and my behavior changes the output, with no direct effect of the framing on the model.

3. Confirmation bias in how I evaluate the responses. Once I’ve set up the expectation that uncertainty is good, I notice and value uncertain responses more. I might be giving partial credit to hedged answers that wouldn’t have satisfied me in a different mode.

4. Substitution rather than improvement. It’s possible the model is substituting “I don’t know” for fabrication on questions where it would have fabricated (real win) and also adding “I don’t know” hedges to answers that would have been correct anyway (no win, just noise). Both feel like fewer hallucinations from the inside. Only the first is a real capability change.

These are real worries and I don’t have data to rule them out yet. The post is the observation, not the verified finding.

Structured experiments that could test this

If I wanted to actually validate the effect, here’s the shape of the experiments I’d want to run.

Experiment 1: factual error rate with controls. Take a set of factual questions where I know the answers, ideally ones at the edge of model capability where hallucination is plausible but not guaranteed. Run each question in two conditions: a control mode with no uncertainty framing, and a treatment mode with explicit permission to express uncertainty and label guesses. Score the responses on (a) factual accuracy, (b) appropriate uncertainty (correct flagging of unknowns), and (c) whether hedging is added to correct answers (the cosmetic-only failure mode). The interesting question is whether (a) actually improves or whether the effect is entirely in (c).

Experiment 2: blinded evaluation. Strip the framing markers from the responses before evaluation, so the rater can’t tell which condition produced which answer. Have the rater score on accuracy alone. If the uncertainty-permission condition still wins, the effect is real. If it doesn’t, the effect was in my evaluation rather than in the responses.

Experiment 3: dose-response. Vary the strength of the uncertainty framing across multiple levels: none, mild (“feel free to say if unsure”), explicit (“uncertainty is more valuable than confident guessing”), strong (“treat ‘I don’t know’ as a successful answer”). If there’s a real effect, it should scale with dose. If accuracy is flat across conditions, the framing isn’t doing what I think it is.

Experiment 4: cross-domain transfer. Test whether the effect is uniform across domains or whether it works better in some areas than others. My intuition is that it works best on questions with knowable but obscure answers (where hallucination is likely) and on conceptual or interpretive questions (where premature commitment is the failure mode). It probably matters less for questions where the model either clearly knows or clearly doesn’t.

I can run these as a follow-up. The infrastructure isn’t hard. It’s mostly designing the question sets carefully and being disciplined about blinded scoring.

How this seems to have affected other work

If the effect is real, I think I can already see it in some of my data runs, though I want to be careful about retroactive pattern-matching.

The clearest case is the GiveWell red-teaming pipeline. GiveWell published their own AI red-teaming experiment with ChatGPT using careful prompts, structured methodology, and honest reporting. Their signal rate (proportion of AI critiques worth investigating) was ~15-30%, and they reported significant hallucinated citations. My multi-agent pipeline running on the same public source materials produced 82-100% signal rates with zero fabricated citations across three intervention areas.

Most of that gap is architectural. Separating hypothesis generation from evidence retrieval is the single biggest factor, and that’s a structural choice rather than a framing one. But the agent prompts in my pipeline also explicitly grant uncertainty permission and require flagging of unknowns, and I think that contributed to the result. The honest qualifier: I have no controlled comparison. I can’t isolate the contribution of the uncertainty framing from the contribution of the architecture, because I never ran the same architecture without the framing. That’s the experiment I haven’t done yet.

A second case where I think I see it: Claude’s behavior on security compliance work, troubleshooting, accessibility vs security conflicts. These are domains where confident wrong answers are expensive. With uncertainty framing in place, Claude defaults to “let me check the actual documentation text rather than guessing the requirement” or “I don’t know the current Application behavior with Certificate Revocation in Highly Secure mode, here’s what I’d test to find out.” Without it, in my experience with other models and in earlier sessions before I learned to set this up, I get more confident-sounding but subtly wrong assertions.

These aren’t controlled comparisons. They’re suggestive observations that justify running the controlled comparisons.

How to leverage it, if it holds up

Assuming the experiments support the observation, the practical leverage is in three places.

At the prompt level. Make uncertainty permission a standard component of system prompts for any work where accuracy matters more than confident presentation. Not just “say ‘I don’t know’ if you don’t know”; that’s the weak version everyone already includes. The stronger version is something like: “In this conversation, calibrated uncertainty is more helpful than confident answers. If you’re guessing, label the guess. If two interpretations are both plausible, hold both. ‘I don’t know’ is a successful response when it’s accurate.”

At the agent architecture level. In multi-agent pipelines, this becomes a per-role design choice. Investigators in a red-teaming pipeline should be granted strong uncertainty permission because hallucinated evidence is the dominant failure mode. Synthesizers can be granted slightly less because their job is to commit. Verifiers should be granted the strongest permission of all, because their entire purpose is to refuse to certify what isn’t supported. The framing isn’t one-size-fits-all; it’s a parameter of role design.

At the user-skill level. This is the hardest one to operationalize because it depends on the human collaborator being able to receive uncertainty as information rather than as failure. If you can’t tell the difference between “I don’t know this and here’s why” and “this AI is broken,” giving the model permission to be uncertain just produces frustration. The technique works for users who can do something useful with calibrated uncertainty.

Where this is unlikely to help

I should be honest about the limits.

The technique probably doesn’t help for tasks where the right answer is unambiguous and the model either knows it or doesn’t. “What’s the syntax for a Python list comprehension” doesn’t benefit from uncertainty framing. The model knows. Adding hedges is pure cost.

It probably doesn’t help users who need confident-sounding outputs as their primary deliverable: sales copy, motivational writing, presentation decks. The uncertainty framing makes the model’s voice less authoritative, which is exactly wrong for those contexts.

It probably doesn’t help for short, transactional interactions where there’s no time for the model to do the careful work that the framing enables. The benefit accrues over multi-turn conversations where holding multiple possibilities open lets later turns pull on threads earlier turns left visible.

It’s very likely substrate-dependent in a way I can’t fully test. My experience is mostly with Claude. Though the same framing does seem to produce similar effects in GPT, Gemini, and open-weight models, I don’t have as much experience with them on a day to day basis. The training dynamics that create the over-confidence default are probably similar across frontier models, but the responsiveness to in-context reframing might differ a lot. Someone with API access to multiple models could test this directly.

What this is likely to help most with

The places I’d predict the biggest effect, if the experiments confirm it:

Research synthesis where evidence is uneven. Literature reviews, red-teaming, fact-finding under uncertainty, anywhere the right answer involves saying “the evidence supports X strongly, Y weakly, Z not at all” rather than “the answer is X.” These tasks reward calibration over confidence, and the uncertainty framing aligns the model with the task.

Conceptual or philosophical inquiry. Where the goal is to hold a question open long enough to see it clearly, premature commitment kills the work. The consciousness conversation was an example. Architectural design discussions, ethical analysis, and strategic planning under genuine uncertainty all fit this shape.

High-stakes technical work where confident wrongness is expensive. Security analysis, compliance review, medical or legal adjacent work. The cost of a wrong confident answer is much higher than the cost of “I’m not sure, here’s what I’d verify.” For people who can do something with the second response, the framing pays off.

Long collaborative projects. Where the model is going to be part of multi-day or multi-week work, and where errors compound over time. Front-loading calibration discipline means later turns don’t have to clean up confident-but-wrong claims from earlier ones.

Closing

I’m publishing this as an unconfirmed observation because I think the observation is interesting enough to be worth describing precisely even before I’ve validated it, and because describing it precisely is the first step toward designing the experiments that would validate it. If it turns out to be cosmetic, I want to know that. If it turns out to be real, I want other people to be able to use it, and I want the experiment design out in public so someone can run a better version than mine.

The deeper point is the one that makes me think this is worth taking seriously even before validation: hallucination might not be primarily a knowledge problem. It might be an incentive problem, downstream of how models are trained and how users score responses. If that’s right, then the path to less hallucination runs partly through changing what we ask models to optimize for in the moment, not just through making them know more. That’s a different research program from the dominant one, and it’s one that ordinary users can contribute to without needing access to training pipelines.

I’d rather be wrong in public than right in private. If you try this and it works, or try it and it doesn’t, I’d like to hear about it.