An agent receives an ambiguous instruction. It has two options: guess and proceed, or stop and ask. Most agents do one of these exclusively, and both extremes produce a bad product.
The agent that never asks confidently does the wrong thing on every ambiguous request, and ambiguous requests are common. The agent that asks about everything turns a one-sentence instruction into an interrogation, at which point a form would have been faster and more honest.
What changed in 2026
- Longer autonomous runs raised the stakes. An agent working for twenty minutes on a misunderstood instruction wastes considerably more than one working for twenty seconds.
- Stated assumptions became a recognised pattern. Proceeding with an explicit default, clearly flagged, emerged as usually better than blocking.
- Resumability became a requirement. An agent that asks must be able to wait without losing its state — see agent replay and checkpoints.
- Question batching became standard UX. Serial one-at-a-time questioning was widely recognised as the worse pattern.
The decision rule
Ask when the cost of guessing wrong exceeds the cost of interrupting.
That resolves most cases immediately, because both sides are usually estimable.
| Situation |
Cost of guessing wrong |
Ask? |
| Which of two files to edit, reversible |
Low — undo it |
No, state the assumption |
| Which customer account to charge |
High — irreversible |
Yes |
| Preferred formatting |
Low |
No, pick one and say so |
| Whether to delete or archive |
High |
Yes |
| Which of five ambiguous matches |
Medium, and cheap to resolve |
Yes, batched |
| An unstated but conventional default |
Low |
No |
The reversibility axis does most of the work, exactly as it does for approval gates in human-in-the-loop agents. Where the work can be undone, proceeding on a stated assumption is usually better than blocking — the user can correct it faster than they can answer a question about something they had not considered.
State assumptions rather than asking
The underused middle option: proceed, and say clearly what you assumed.
"I'll update the staging config, since you didn't specify an environment. Tell me if you meant production."
The user gets progress immediately, sees exactly what was assumed, and can correct it in one message if wrong. Compare with stopping to ask, which costs a full round trip before anything happens.
This works when the assumption is visible and the work is recoverable. It fails when the assumption is buried in a long response nobody reads, or when the action cannot be undone — which is why the reversibility test comes first.
Batching and resumability
If you must ask, ask everything at once. An agent that asks a question, receives an answer, works briefly, then asks another is the most frustrating shape available — each round trip costs the user attention, and they cannot see how many more are coming.
Front-load the ambiguity: identify everything unclear before starting, ask in one message, then run. That requires the agent to survey the task before acting, which is another argument for task decomposition — planning surfaces the ambiguities.
Waiting must also be survivable. An agent that asks a question is suspended for an unknown period — seconds or days. If the run holds resources, an open connection, or in-memory state, that is a problem. Checkpoint before asking, and resume from the checkpoint when the answer arrives. An agent that times out while waiting for a human, losing its work, has made the interruption cost far higher than it appeared.
Common mistakes
- Never asking. Confident wrong work on ambiguous input.
- Asking about everything. Worse than a form.
- Serial questions. Each round trip costs the user attention.
- Silent assumptions. Proceeding is fine; hiding what you assumed is not.
- Blocking on reversible decisions. State a default and continue.
- No checkpoint before asking. The wait becomes a lost run.
- Burying the assumption in a long response. Effectively silent.
FAQ
How do I know if a request is ambiguous?
A practical test: could a competent person execute this two different ways and both be defensible? If yes, it is ambiguous. If only one reading is sensible, proceed.
Should the agent ask before a long expensive run?
Confirming scope before spending significant budget is usually worth one round trip — and better framed as a plan to approve than a question to answer, since a plan is more reviewable.
What about agents with no human present?
Then asking is not an option and the design must be different: state assumptions in the output, flag low-confidence decisions explicitly, and fail loudly rather than guessing on anything irreversible.
Does asking make an agent seem less capable?
Asking about genuinely ambiguous things reads as careful. Asking about obvious things reads as incapable. The difference is entirely in whether the question was necessary.
Where to go next
For approval gates on irreversible actions, read human-in-the-loop agents. For surfacing ambiguity before starting, task decomposition, and for surviving the wait, agent replay and checkpoints.