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)