What an AI agent should do when it lacks information
By Precipitate · 17 October 2026
An AI agent that hits a gap in what it knows has two real options: proceed on a visible assumption, or stop and ask. The right choice depends on what the missing fact controls, not on how confident the model sounds. A guess that only changes formatting is cheap to undo. A guess that picks the wrong customer or approves a refund that was never authorized is not, and that gap is where trust in the system is won or lost.
Guessing is the default, and that's the risk
Most agents built to work around incomplete data do not stop and wait. Zilliz's explainer on how AI agents handle incomplete information describes the default toolkit: Bayesian networks to estimate a missing value from related fields, or patterns borrowed from similar users' past behavior to fill a gap in preference data. That works well in a recommendation engine, where a wrong guess means a mediocre suggestion. It works differently in a business where the missing field is an account number or a dollar figure on an invoice. Which gap you are filling changes what a wrong guess is allowed to cost.
The problem is not that agents guess. It is that they often guess silently. An agent that infers the likely vendor on a late invoice and books the payment without flagging that inference has made a decision no human saw. Nothing in the log distinguishes a confirmed match from a guess, until the wrong vendor gets paid. How to tell an AI agent is failing quietly covers this exact failure mode: the system never crashes, it just drifts off course without announcing it.
A fact question is not a permission question
Digital Applied's guide to agent clarification draws a distinction worth keeping separate in any workflow: a fact question asks what is true (which order, which record), while an authority question asks whether the agent may act on it. Collapsing the two produces a misleading interaction. A customer who confirms an account number has not thereby approved a refund against it, in the same way that supplying an email address is not a request to send anything to it.
The fix is to store the two decisions separately rather than treat confirmation of one as permission for the other. A target record can be settled while the action built on it stays a draft waiting for a yes. Neither decision should wait on the other, and neither should be inferred from the other. How to set limits on what an AI agent can do alone is the place to define that boundary before the agent hits a gap, not while it is mid-task guessing at both at once.
When to proceed and when to stop
Not every gap deserves a question. Digital Applied's framework asks a simpler thing first: does the missing answer decide which path the task takes, or just how it looks? An agent drafting a customer update can usually pick a standard structure and leave it easy to edit later, because a wrong guess there costs a few minutes of rewriting. An agent choosing between two matching customer records, or about to send that draft to someone, faces a different case: the wrong pick changes whose data moves or who receives a message. The format question is reversible in minutes. The record question is not, once the agent has already acted on the wrong one.
A useful habit is to write out what each possible answer would lead to before the agent acts. If every plausible answer lands on the same safe next step, let the agent proceed and make the assumption visible. If the answers diverge into different records or different recipients, that is the point to stop. Logging which happened, a stop to ask or a flagged assumption, is the job of an audit trail. What audit trails an AI agent should leave behind covers what that record needs to include; without it, nobody can tell afterward which gaps got handled which way.
Why a quiet wrong guess costs more than a slow right one
Owner-operators tend to measure an automation by speed: did it answer fast, did it finish the task. That measure rewards the wrong behavior here. An agent that pauses to confirm a shipping address looks slower on paper than one that guesses and moves on. We would rather an agent ask too often in its first month than guess wrong once with a customer's money involved, and that trade-off only works if someone can see which one happened. Slow and right beats fast and wrong exactly once, and after that it is hard to get a customer to trust the fast version again.
The imputation side of this carries a related warning. Xenonstack's write-up on missing-data imputation in Databricks pipelines separates missing values into three types, data missing completely at random, missing at random, and missing not at random, because applying one fix to all three biases the result. The operational version of that caution is simpler: not every gap in a business workflow is the same kind of gap, so a blanket rule of always ask or always assume will handle some of them badly. What is missing, and what depends on it, has to decide the response each time.
A check you can run this week
You do not need a vendor dashboard to run this check. Pull the last ten runs of any automation that touches customer data or money. For each run where information was missing or ambiguous, check what the log shows: did the system ask, did it make a visible assumption, or did it guess silently and move on? If you cannot tell which of the three happened, that is the finding, not that the agent guessed, but that nobody could check it afterward. Count how many of the ten runs you cannot classify. That count is your actual exposure, not an estimate of it.
Sources
Want this answered for your own business?
Get a straight answer →