AI agents face ambiguous user requests every day: a vague instruction, a missing detail, a contradiction the user never noticed. What an agent does next — ask a question, act on an assumption, or hand the task to a human — decides whether the work succeeds or fails quietly. This article explains how AI agents handle ambiguous or incomplete requests, from spotting the gap to clarifying well, acting safely under uncertainty, and knowing when to escalate.
The stakes are real. Research on tool-calling agents finds that they “often fail when user instructions are ambiguous or incomplete, leading to incorrect invocations and task failures.” The failure is not usually dramatic. It is an agent booking the wrong thing, calling the wrong tool, or completing the wrong task with total confidence.
What ambiguity looks like in practice
Ambiguity in a user request takes a few recurring shapes. Consider three illustrative cases — supplied by this article, not drawn from the research: vague task specifications such as “find me a good restaurant,” incomplete parameters such as “book a meeting for tomorrow,” and implicit assumptions about what the system can do. A fourth shape shows up constantly in real deployments: conflicting constraints, where the request asks for two things that cannot both be satisfied — “send the email now and wait for my approval before sending it,” or “schedule the meeting for 9am in London and 9am in New York at the same time.” The four shapes are this article’s explanatory framework, not a taxonomy from the research.
A request can also look complete to the user and still be underspecified to the agent. “Summarize the report” is a normal sentence, but it leaves open which report, how long the summary should be, and who it is for. The user knows the answers; they simply never said them, because to a person the context feels obvious. The agent has no access to that unspoken context, so it must either recover it or guess it.
Why ambiguous user requests are hard for agents
An agent cannot act without concrete parameters. A tool call needs a date, an amount, a destination, a file path. When the request does not supply one, the agent has two options: ask, or fill the gap itself. Every gap it fills is a guess, and in a multi-step plan those guesses compound — a wrong assumption in step one becomes the foundation for steps two through ten.
The deeper problem is that models are bad at admitting they are guessing. When faced with incomplete information, language models often hallucinate the missing arguments rather than flagging them, which leads to incorrect tool invocations. And a model can be confident and wrong at the same time: high confidence in an interpretation is not evidence that the interpretation is correct.
There is also a documented gap between recognizing ambiguity and acting on it. In a study of clarification behaviour, models often identified ambiguity when explicitly asked to judge a question — yet in normal question-answering they overwhelmingly defaulted to direct answers instead of asking. Retrieved context made the gap worse: it improved answerability while making models even less likely to ask a clarifying question. The practical lesson for builders is a design recommendation, not an empirical necessity: do not rely on the model to volunteer its uncertainty. Design the harness so the decision is explicit — allow the model to ask clarifying questions, or log its deviations — rather than leaving the choice to chance.
How agents detect ambiguity
Detection starts with the tools. Each tool an agent can call has a schema: required parameters, allowed values, dependencies between them. Comparing a request against those schemas is the cheapest ambiguity check available — if a required parameter has no value and no sensible source, the request is incomplete, and the agent knows exactly which piece is missing.
A more principled approach separates two kinds of uncertainty. Specification uncertainty is about what the user wants; model uncertainty is about what the model predicts. A recent research formulation, structured uncertainty, works directly over tool parameters and their domains, and uses the expected value of perfect information to decide which question is worth asking and when to stop asking. The reported results are striking: an agent using this approach achieved 7–39% higher coverage on ambiguous tasks while asking fewer clarification questions, and uncertainty-guided training lifted accuracy on a when-to-call benchmark from 36.5% to 65.2% on a 3-billion-parameter model and from 36.7% to 62.9% on a 7-billion-parameter model.
Other signals matter too. A request that admits several equally plausible interpretations is ambiguous even if every parameter looks filled. And a contradiction — between the stated constraints and what the agent retrieves from context — is a strong signal that something in the request is wrong, not just missing.
The clarification playbook: asking the right question
When an agent does ask, how it asks matters as much as whether it asks. Three rules cover most cases.
First, ask one focused question about the highest-impact unknown. Clarification is a value-of-information problem: the assistant should acquire the information whose absence causes the greatest avoidable loss. Asking about everything is not thorough; it is expensive. In a preregistered study of reference-image matching — 456 interactive sessions across 76 human participants — assistants that asked more informative questions helped users match the reference image with fewer questions, less total interaction time, and lower cost. That is one experiment in one setting, not a general result across agent workflows, but the design inference travels: a question that recovers the highest-value missing detail is worth more than several low-value ones.
Second, offer options or a recommended default instead of an open-ended question. Claude Code’s AskUserQuestion tool is built on exactly this pattern: it renders a question with two to four discrete options, always including an “Other” choice for free text, and the answer comes back as structured data the agent acts on directly. The tool’s own guidance states the boundary clearly: “Use this tool only when you are blocked on a decision that is genuinely the user’s to make: one you cannot resolve from the request, the code, or sensible defaults.” A maximum of one to four questions per call keeps the exchange bounded.
Third, confirm the understanding back to the user before acting on it. A short restatement — “So you want the Friday flight, refundable, under $400?” — catches misreadings that a silent assumption would have carried into execution. Confirmation is cheap; rework is not.
Acting under uncertainty: safe defaults and reversible steps
Sometimes asking is worse than acting. If the cost of being wrong is low, the mistake is easy to correct, and the default is supported by context the user has already given, the agent should proceed on that default and say what it assumed. Without a context-supported default, preparation is fine but committing is not: search, draft, and hold the purchase until the missing details or an approval arrive. The same request can be handled three ways, and the differences show the decision rule at work. Take “book a flight to Paris next week”:
- Clarify: the agent asks which day and which airport, because the answer changes the booking entirely.
- Assume: the agent searches Friday flights, holds a refundable itinerary, and states the tentative choice — “I found a Friday 09:10, refundable — shall I book it?” — obtaining the missing details before purchasing, so the user can correct it in one message.
- Escalate: the agent asks for approval before charging a non-refundable business-class fare, because the cost of a wrong guess is high and irreversible.
The rule is the cost of being wrong — and whether the default is supported by context. A default the user has already signalled, with low consequences and an easy correction, is safe to act on and disclose. Without that support, preparation is fine but committing is not. High stakes and hard to reverse means stop and ask. Doing the reversible part of a task first — drafting, searching, preparing — while the risky part waits for confirmation is the same principle applied across a plan.
Frameworks give this pattern a concrete shape. In the OpenAI Agents SDK, a tool declares that it needs approval, the run pauses, and the application approves or rejects before anything executes. In outline, the flow looks like this:
# Fragment: approval flow in the OpenAI Agents SDK
result = await Runner.run(agent, "Tell order 4182 their refund is approved.")
if result.interruptions:
state = result.to_state() # serialized, resumable later
for item in state.get_interruptions():
if approved(item):
state.approve(item)
else:
state.reject(item, rejection_message="Ask finance first.")
result = await Runner.run(agent, state)The paused run is plain data, so it can wait as long as the application keeps it — minutes or days — and resume from exactly where it stopped.
When to escalate to a human
Escalation is the third strategy, and it needs explicit triggers rather than vibes. Three are reliable: the action is irreversible or high-cost, the agent has already failed to clarify the same point, or a policy says a person must decide. Anthropic’s Barry Zhang puts the underlying test simply: “If a mistake is high-stakes and hard to detect, autonomy becomes a liability. Read-only access and human-in-the-loop are real mitigations.” The same talk’s first test for building an agent at all is whether the task is ambiguous enough that you cannot pre-map the decision tree — ambiguity is the reason the agent exists, not a defect in it.
OpenAI’s guidance draws the same line: “Pause ambiguous or high-risk actions for explicit human approval before the tool runs.” In LangGraph, the mechanism is an interrupt: a node calls interrupt() with a question, the graph saves its state through a checkpointer, and the run waits — indefinitely — until a human resumes it with Command(resume=…). On resume, the interrupted node restarts from its first line — anything before the interrupt() call runs again — and this time interrupt() returns the supplied resume value instead of pausing. In outline:
# Fragment: asking a human mid-run in LangGraph
def review_node(state):
decision = interrupt({
"question": "Refund order 4182?",
"options": ["Approve", "Reject"],
})
# the graph pauses here; on resume, this node restarts from its first line and interrupt() returns the human's answer
return {"decision": decision}
# Later, on the same thread:
result = graph.invoke(Command(resume={"decision": "Approve"}), config)One production warning matters here: an unanswered interrupt waits forever, holding whatever the run was in the middle of. Any system that pauses for humans needs a reminder workflow for pending approvals and a sweeper for expired and stuck ones, or approvals become a place where work silently dies.
Design patterns that reduce ambiguity before it happens
The cheapest ambiguity to handle is the one that never reaches the agent. Structured input — forms, pickers, and constrained fields instead of a blank text box — removes whole classes of missing parameters before the run starts. Examples in the prompt show the agent what a complete request looks like, and sensible defaults mean the common case needs no clarification at all.
Memory and retrieved context fill gaps the user should not have to repeat: which project, which account, which preferences. Task decomposition helps too — breaking a large request into steps surfaces the missing information early, while it is still cheap to ask, instead of halfway through execution.
And the field is starting to measure this properly: the structured-uncertainty research reports evaluation results for its own approach — SAGE-Agent’s coverage gains on ambiguous tasks and the When2Call accuracy improvements. But whether benchmark results like these transfer to production decisions is still an open question, and a framework choice should not rest on benchmark numbers alone.
Common mistakes and limits
The most common mistake is over-asking. An agent that fires a clarification question for anything mildly ambiguous turns a five-minute task into a five-round interview, and users stop answering. AskUserQuestion’s design reflects this: it exists for genuine forks with real consequences, not for every small uncertainty. The research agrees — clarification should happen only when the answer will meaningfully change the decision.
The second mistake is silent guessing: acting on an assumption without disclosing it. When the guess is wrong, the user discovers it late, in the output, instead of early, in a question. Surfacing the assumption costs one sentence; hiding it costs the task.
The final limit is worth stating plainly. Ambiguity handling clarifies how to reach the user’s stated goal; it does not fix a wrong goal. If the user asked for the wrong thing, no amount of careful clarification will produce the right outcome — the agent will simply execute the wrong plan more precisely. Recognizing that case, and saying so, is itself a form of handling ambiguity.
Handled well, ambiguity is not a failure mode. It is the normal state of a request from a human who knows what they want but has not said all of it. The agents that work best are not the ones that guess fastest; they are the ones that know which gaps matter, ask about exactly those, act safely on the rest, and hand off the moment the stakes exceed their authority.
