How should an AI agent handle uncertainty?

The default behaviour when a system is uncertain is to soften the language: might, generally, in most cases, it appears that. This is the least useful available response. Hedged prose spreads the doubt evenly across a passage in which most of the content is fine, so the reader either discounts everything or, more commonly, reads past it. Nothing has been communicated except unease.

The alternative is to move uncertainty out of the prose and into a named list. Assumptions made, with what each one would change if wrong. Things that could not be established, with what was tried. Places where two sources disagreed, with both readings. These are checkable statements, and each one points at a specific action a reader can take, which is the entire difference between useful and decorative uncertainty.

The most important distinction inside this is between not knowing and not having looked. An agent that reports it could not determine something has said one of two very different things: the information does not exist in what it can reach, or it did not go and find out. Requiring the report to say what was attempted separates these, and it turns out to be one of the most revealing things you can ask an agent to include, because the second case is far more common than the first.

There is a related failure worth naming: the confident bridge. Faced with a gap, an agent frequently fills it with the most plausible value and continues, and the resulting output contains an invented specific presented in the same register as everything around it. This is not solved by asking for more caution. It is reduced by supplying the material and by requiring that any value not present in the sources be marked as supplied by the agent, which makes the bridge visible instead of preventing it — and visible is what you actually need.

Uncertainty about the task is a separate category and should be handled at a different time. If the brief is ambiguous, the useful moment to say so is before the work, not in a note attached to the finished product. A cheap first turn that restates the job as understood and names the ambiguities costs almost nothing and catches the expensive misreadings while they are still free to fix.

Finally, distinguish uncertainty from failure in the reporting, because they need different responses. A run that could not complete because a system was unavailable is a failure and should be retried or escalated. A run that completed while unable to establish two facts is a success with caveats and should be read. Systems that collapse the two into a single status either alarm people over normal caveats or bury genuine failures under them.