What uncertainty looks like for an AI agent
Understanding how AI agents handle uncertainty starts here: uncertainty is not a rare edge case for an AI agent, but its normal working condition. An agent that books travel, answers customer questions, or operates a software tool rarely starts with everything it needs, and the information it does have is often ambiguous, stale, or partly wrong.
That uncertainty takes several distinct forms, and telling them apart matters because each one calls for a different response. First, instructions are often ambiguous or underspecified: a request to “book the cheapest flight” leaves open which dates, airports, and trade-offs the user actually means. Second, data can be missing, stale, or conflicting, when a tool returns an old record, two sources disagree, or a field is simply blank. Third, observations of the environment can be noisy or partial, so the agent sees only part of what is going on. Fourth, the outcomes of multi-step actions are unpredictable: each step can succeed on its own terms and still lead to the wrong overall result, because a small error early in a chain compounds before anyone notices it.
An agent that treats all of these as the same problem will respond badly. Retrieved context can supply missing details and resolve apparent ambiguity, but it cannot decide a user-owned choice; likewise, a missing fact is not solved by asking the user a question they cannot answer. So retrieve available context first, then ask when a consequential choice remains for the user. The first job of a capable agent is therefore to notice which kind of uncertainty it faces, and how much it matters for the next step.
How AI agents handle uncertainty in practice
At a high level, AI agents handle uncertainty through a loop with four stages: detect, represent, reduce, and act. The agent first detects that information is missing, ambiguous, or conflicting instead of silently assuming it. It then represents that doubt in a form it can reason with, such as a probability or a ranked list of hypotheses. Next, it tries to reduce the uncertainty where reduction is possible, by asking a question, retrieving a document, or calling a tool. Finally, it acts under whatever uncertainty remains, choosing an action whose cost fits the level of doubt: a reversible step, a hedged answer, or an escalation to a human.
The loop repeats. Every answer, tool result, or user reply is new evidence, and the agent updates its beliefs before the next step. That updating is what separates an agent that copes with uncertainty from one that merely guesses once and presses on.
Consider a generic example. A support agent is asked to refund an order, but the order number is missing and the customer’s message mentions two different products. A poor agent picks the more likely product and processes the refund. A better agent detects the gap, checks the customer’s recent orders through its tools, and if both products still look plausible, asks one targeted question — which order, this one or that one — before touching any money. The question is worth asking precisely because the answer changes the action. If the difference had been harmless and reversible, the agent could instead have proceeded with a stated assumption and let the user correct it.
Representing uncertainty: probabilities, confidence, and calibration
To reason about doubt, an agent needs a representation of it. Probabilistic reasoning represents uncertainty as follows: instead of holding a single answer, the system holds a distribution over possible answers, each with a likelihood. Bayesian inference is the classic way to update that distribution. The agent starts with a prior belief, based on what it knew before, and revises it as new evidence arrives, giving more weight to hypotheses the evidence supports and less to those it contradicts. A medical example often used to explain the idea is a diagnostic system that revises the probability of a condition as each test result comes in; the same pattern applies when an agent revises the probability that a user meant one airport rather than another as more context arrives.
Uncertainty itself comes in two kinds, and the distinction is practical. Epistemic uncertainty comes from lack of knowledge, and it shrinks as the agent gathers more data or better models. Aleatoric uncertainty comes from inherent randomness in the world, and no amount of extra data removes it. An agent should spend effort reducing the first kind and budgeting for the second, not the other way round.
Confidence scores are the most visible form of this representation, and also the easiest to misuse. A confidence score is not automatically a probability. A classifier can report high confidence without actually being right that often in comparable cases, and language models are notorious for speaking with equal fluency whether they are reciting an established fact or inventing one. That is why calibration matters: a well-calibrated system is right about as often as its confidence implies. Checking calibration means comparing predictions against outcomes over many cases, not trusting a single confident-sounding answer. Token probability, the likelihood a model assigns to the next word, is a still weaker signal — it measures how plausible a continuation sounds, not whether the claim it makes is true.
Gathering missing information: questions, retrieval, and tools
Representing uncertainty is only half the job. Wherever possible, an agent should actively reduce it before acting, and it has three main ways to do so.
The first is asking. A useful clarifying question is tied to a decision: it names the missing detail and why it matters. “Should the report cover this month or the last 30 days?” changes the next action; “Can you tell me more?” usually does not. The rule that follows from this is simple to state and hard to follow in practice: ask when the unresolved information could change the next answer, tool call, or side effect, and when the person being asked actually owns the missing choice. Do not ask merely because more context would be interesting, and do not ask for a fact the agent could retrieve itself. Some research-agent designs even cap clarification turns, so that asking does not become a substitute for doing the work — one published blueprint, for example, allows a maximum of three clarification rounds before the agent must proceed with a plan.
The second way is retrieval. When a fact exists in a document, a database, or another system, the agent should look it up rather than reconstruct it from memory. Grounding answers in retrieved sources, with citations the user can check, can reduce invented facts. Retrieval has its own limits, though: a related but irrelevant passage can mislead, and a stale record can mislead just as confidently as a guess. Cross-checking sources against each other, and preferring the most current and authoritative one, is part of the work, not an optional extra.
The third way is tool use and testing. An agent can call an API, run a query, check a calendar, or try a reversible action in a safe environment and observe the result. Each observation is evidence that can update the distribution of possibilities, reducing uncertainty when it is informative and reliable — though new evidence can also expose conflicts or additional unknowns. Knowing when to stop gathering matters too: each extra lookup costs time and patience, and beyond a point adds little.
Deciding and acting under uncertainty
Eventually the agent must act with uncertainty still present, and how it acts should depend on the stakes. Low-stakes, reversible actions can proceed on a reasonable assumption, stated openly so the user can correct it. High-stakes or irreversible actions — sending money, deleting data, changing a production system — warrant a different default: confirm first, use a fallback, or hand off to a human.
Planning under uncertainty means planning with contingencies. Rather than committing to a single long chain of steps, an agent can choose the step that keeps the most options open, prepare a fallback for the most likely failure, and check its progress after each step so that a wrong turn is caught early. In everyday agent work, the equivalent is simpler: do the reversible step first, verify, and only then do the irreversible one.
Selective prediction gives this a formal shape. A system that can abstain — refusing to answer, or escalating to a human, when its certainty is below a threshold — aims to be right more often on the answers it does give, but that benefit must be validated against observed outcomes: it depends on the uncertainty signal being well calibrated and the threshold being set appropriately, not on abstention alone. Abstention should not be read as failure. It is a deliberate outcome that prevents insufficient evidence from triggering an action, and it is especially important in high-stakes domains such as medicine, law, and finance, where a confident but wrong answer is worse than an honest admission of doubt. The threshold itself is a design decision: it should reflect the cost of being wrong, not just the model’s confidence.
Finally, acting under uncertainty is also how an agent learns. Outcomes feed back into the next decision. A question that resolved an ambiguity, a tool result that contradicted an assumption, or a correction from the user can narrow uncertainty next time — provided the agent records what happened and updates its beliefs, rather than starting each task from scratch — but learning from recorded outcomes is conditional, not automatic, and depends on the evidence being reliable and the updates being checked.
Communicating uncertainty honestly
How an agent talks about uncertainty is part of handling it. An agent that hides its doubt misleads the user into trusting an answer more than the evidence warrants. An agent that hedges everything, on the other hand, is useless: a reply full of “maybe” and “possibly” gives the user nothing to act on.
The useful middle ground is specific. The agent should surface its confidence where it matters, name the sources its answer rests on, and distinguish what is known from what is inferred and what is simply unknown. “I found two orders matching your description; I refunded neither, because the amounts differ” is more useful than either a silent guess or a vague warning. Where an answer rests on an assumption, the assumption should be stated, so the user can spot it and correct it.
This is also where abstention becomes a communication choice, not just an internal one. Saying “I don’t know” — and, ideally, saying what would be needed to know — is professional, not evasive, provided the system treats it as a legitimate outcome rather than a failure to be trained away. Making the pass option visible, and making “I don’t know” an acceptable result, is what allows honest communication to survive contact with real users.
Common mistakes and limits
The most common mistake is treating a confident tone as evidence. Fluency is not reliability, and a well-written paragraph can be entirely invented. Readers evaluating an agent’s output, and builders evaluating an agent they operate, should ask for sources, check the reasoning, and be suspicious of answers that are confident precisely where the evidence is thinnest.
The second mistake is filling gaps silently. When an agent invents a missing name, date, or number instead of flagging the gap, the error can be concealed and its correction delayed. A system that never says “I don’t know” has not eliminated uncertainty; it has hidden it, and hidden uncertainty can turn a small gap into a costly action.
The third group of mistakes is about balance: over-asking, under-asking, and calibration drift. An agent that asks the user about every detail can frustrate its user, and an agent that never asks risks guessing wrong on decisions that matter. And calibration can drift when the operating data or tasks change, so thresholds should be rechecked against observed outcomes rather than left unexamined.
Finally, there is a hard limit no technique removes. Uncertainty handling cannot create information that does not exist. No amount of probabilistic reasoning, retrieval, or clarification can answer a question whose answer is nowhere to be found and no one can supply. The honest endpoint of the loop is sometimes not an answer but a clear statement of what is missing, what was tried, and what would resolve it. An agent that can reach that endpoint gracefully — without inventing, stalling, or misleading — is handling uncertainty well, even when it cannot answer the question.
