Your agent didn't misunderstand you. It guessed — confidently, silently, and wrong. That's the real failure mode of ambiguous requests: not a crash, not an error message, but a perfectly executed wrong task.
Tool-calling agents "often fail when user instructions are ambiguous or incomplete, leading to incorrect invocations and task failures." The booking goes through, the email gets sent, the wrong file gets summarized — and the agent reports success with total confidence. That's worse than failing loudly. A loud failure gets fixed; a confident wrong answer gets trusted.
The four ways requests go vague
Ambiguity isn't one problem, it's four:
- Vague specs — "find me a good restaurant." Good by what measure, for whom, where?
- Missing parameters — "book a meeting for tomorrow." With whom, at what time, on which calendar?
- Hidden assumptions — the user assumes the agent knows which report, which account, which project. It doesn't.
- Conflicting constraints — "send the email now and wait for my approval before sending it." Both can't be true, and the agent has to notice.
The killer detail: a request can look complete to the user and still be underspecified to the agent. "Summarize the report" is a normal sentence. Which report, how long, for whom — all unspoken, because to a person the context feels obvious.
Models are bad at admitting they're guessing
Here's the uncomfortable part. When a required parameter is missing, a language model often hallucinates the missing argument rather than flagging it. And high confidence in an interpretation is not evidence the interpretation is correct — models can be confident and wrong at the same time.
Research makes it worse: models often recognize ambiguity when explicitly asked to judge a question, yet in normal question-answering they overwhelmingly default to direct answers instead of asking. Retrieved context even deepens the gap — it improves answerability while making models less likely to ask a clarifying question. The model looks smarter and gets dumber about its own ignorance.
The design lesson is blunt: do not rely on the model to volunteer its uncertainty. Build the harness so the decision is explicit — the model can ask, or its deviations get logged — instead of leaving the choice to chance.
Ask one question, not twenty
When the agent does ask, how it asks matters as much as whether it asks. Three rules:
- Ask about the highest-impact unknown. Clarification is a value-of-information problem: the detail whose absence causes the greatest avoidable loss. Asking about everything isn't thorough; it's expensive. In a 456-session study, assistants that asked more informative questions got users to the right answer with fewer questions, less time, and lower cost.
- Offer options or a default, not an open-ended question. Claude Code's AskUserQuestion tool renders two to four discrete options plus "Other" — and its own guidance is the boundary: use it only when blocked on a decision that is genuinely the user's to make.
- Confirm back before acting. "So you want the Friday flight, refundable, under $400?" Confirmation is cheap; rework is not.
The real rule: what does being wrong cost?
Sometimes asking is worse than acting. The decision rule is the cost of being wrong — and whether the default is supported by context the user already gave.
Take "book a flight to Paris next week": clarify when the answer changes the booking entirely; assume when the mistake is cheap and reversible (search Friday flights, hold a refundable itinerary, state the assumption, let the user correct it in one message); escalate when the fare is non-refundable business class, because a wrong guess there is high-cost and irreversible.
Frameworks make this concrete rather than vibes-based. The OpenAI Agents SDK pauses a run on tool approval and resumes from serialized state. LangGraph interrupts mid-run and waits — indefinitely — for a human to resume it. But that "indefinitely" is a warning, not a feature: an unanswered interrupt waits forever, holding whatever the run was in the middle of. Any system that pauses for humans needs a reminder workflow and a sweeper for stuck approvals, or approvals become the place where work silently dies.
And the escalation triggers should be explicit, not vibes: the action is irreversible or high-cost, the agent has already failed to clarify the same point, or policy says a person must decide. Anthropic's Barry Zhang puts it plainly: "If a mistake is high-stakes and hard to detect, autonomy becomes a liability."
The cheapest ambiguity is the one that never arrives
Structured input — forms, pickers, constrained fields instead of a blank text box — removes whole classes of missing parameters before the run starts. Examples show the agent what a complete request looks like. Memory and retrieved context fill gaps the user shouldn't have to repeat. Task decomposition turns one giant ambiguous ask into small, checkable steps.
The point isn't to make agents ask more questions. It's to make the ask-act-escalate decision deliberate instead of accidental — because right now, most agents are deciding by defaulting to "act," and acting on a guess they never told you about.
Go deeper
Read the full article on Agentic Affairs: Ambiguous User Requests: When AI Agents Ask, Act or Escalate
Originally published on Agentic Affairs (https://agentic-affairs.com)
Top comments (4)
The conflicting constraints example, send now and wait for my approval, is the one that fails most quietly. A rule that helps: anything irreversible defaults to ask, anything reversible defaults to act and report. Ambiguity costs much less when the wrong guess can be undone.
That's a clean way to put it — and it maps exactly onto the cost-of-being-wrong rule in the piece. The part I'd underline is 'act and report': the reporting is what makes the reversible guess cheap, because the user can correct it in one message instead of discovering it later. Do you treat 'report' as a log entry, or something the user actually sees in the moment?
The cost-of-being-wrong rule is the part that sticks with me. It is a much better test than asking whether the request was "clear enough" in the abstract — clear enough for what, and what happens if the guess is wrong?
Hidden assumptions are the ones I run into most outside software. Someone says "send the contract" and means a specific version to a specific person, and none of that was in the sentence. The agent guessing confidently is worse than it stopping to ask.
I also liked the point about structured input. A good tool should not hand someone a blank box for a high-stakes action and then blame them for being vague. Narrow the choices first, then let the agent move fast on the low-risk parts.
Exactly — 'clear enough' is meaningless until you attach the stakes to it. Your 'send the contract' example is the perfect case: the sentence looks complete, and the missing version and recipient only surface when the agent has to act. And yes on structured input — a blank box for a high-stakes action is the tool outsourcing its own job back to the user. Where do you draw the line, though — when the hidden assumption only becomes visible after the action, is that a case for a good undo, or for asking first?