An AI agent should ask a clarifying question when a request has more than one reasonable reading and picking the wrong one would cause an action that is costly or hard to undo. When the readings lead to the same result, or the step is cheap to reverse, it should state its assumption and carry on.
Why agents guess instead of asking
Most requests that reach an agent are underspecified. "Send the report to the client" leaves out which report, which version and which contact. A person would ask, or would know from context. An agent left to itself usually does one of two things: it picks the most likely reading and acts, or it searches and reasons in circles until it runs out of budget.
Recent research on coding agents describes the same split. The paper Ask or Assume? Uncertainty-Aware Clarification-Seeking in Coding Agents frames it as guessing, which leads to errors, versus stopping, which leads to failure, and tests a third path: asking only when the ambiguity actually threatens the task. Its authors found that well-placed questions mattered more than the number of questions asked.
Neither guessing nor stopping is acceptable in an enterprise system. A wrong guess can update the wrong record or message the wrong customer. A stalled run wastes time and leaves work half done. Runs that never finish need their own brakes; this post is about the moment before the agent commits to a reading at all.
When asking is worth the interruption
Every question costs the user attention, and an agent that asks about everything soon gets switched off. The useful test combines two things: how many real readings the request has, and what happens if the agent picks the wrong one.
Ask when the readings diverge and the action is hard to undo
Ask first when the possible readings lead to different actions and at least one of those actions is external or permanent: sending a message, changing a payment, deleting data, or writing to a system of record. The same thinking sits behind stopping an agent taking a wrong action; a clarifying question is the cheapest of those controls because it comes before the agent has done anything.
Assume and say so when the step is reversible
If the agent is drafting, searching or preparing something a person will review, it can pick the likely reading, state it plainly ("I have assumed you mean the latest quarterly report for Acme") and continue. The user corrects it if needed, and nothing has been lost.
Look it up before asking
Many questions an agent wants to ask are answered somewhere it can already reach: the user's recent activity, the ticket history, the CRM record or a project setting. Asking a person for something the system already knows is the fastest way to make an agent feel useless. Make lookups part of the agent's routine before it raises a question.
How to ask a good clarifying question
When the agent does ask, the form of the question decides whether the user answers it quickly or gives up.
- Ask one question at a time and make it the one that removes the most doubt. A list of five questions reads like a form.
- Offer the likely options. "Do you mean the signed contract or the latest draft?" is quicker to answer than "Which document?"
- Show what the agent will do with each answer, so the user can see why the question matters.
- Keep the run's state while it waits, so the answer picks the task up where it paused rather than starting again.
- Set a fallback for when nobody answers: hand the task to a person, or stop cleanly with a note of what was missing.
For tasks that pass between people and agents, the question also needs to reach the right person. That may be the requester, or it may be an approver in the same flow, as described in human in the loop without friction.
Building the decision into the agent
Clarification works well as a designed step, not something left to the model's mood on the day.
Give the agent an explicit ask action
Expose "ask the user" as a tool with a clear description of when to use it, in the same way as any other tool. This makes the decision visible in traces and lets you count how often it happens. Our post on designing tools an AI agent can use covers how to write those descriptions.
Tie the threshold to the action's risk
Use the same risk tiers you already apply to approvals. Low-risk actions proceed on a stated assumption, medium-risk actions ask when there is real ambiguity, and high-risk actions always confirm the key details. A confidence score can help, but treat it as one input; the guidance in confidence scores and human review applies here too.
Test it with deliberately vague requests
Add underspecified requests to your evaluation set alongside clear ones. Check that the agent asks when it should, proceeds when it should, and that its questions are short and answerable. Keep the cases in the regression suite so a prompt or model change does not quietly make the agent guess again. See what AI agent evals catch for how those suites fit together.
Review the questions in production
Questions users skip or answer the same way every time are a signal. If everyone gives the same answer, make it the default. If users ignore a question, it is probably asking for something the agent should have looked up.
Frequently asked questions
Will clarifying questions make an AI agent slower to use?
Each question adds a pause, but a well-placed one is usually quicker than undoing a wrong action or redoing a task. The aim is not to ask more often; it is to ask at the few points where a wrong guess would cost real time or trust. Reversible steps should proceed on a stated assumption, so most runs never stop to ask at all.
How does an agent know a request is ambiguous?
It compares the possible readings of the request against what it can find in context. If lookups in records, history or settings leave more than one reasonable reading, and those readings lead to different actions, the request is ambiguous for that task. Prompting the agent to list its assumptions before acting makes this check explicit and easier to review in traces.
What should happen if the user never answers?
The agent should not wait forever or fall back to guessing on a risky step. Set a time limit for each kind of task. When it passes, the agent hands the task to a named person or queue with a note of what it needed, or stops cleanly and records why. Either way the run's state is kept so it can resume later.
Is a clarifying question the same as a human approval step?
No. An approval asks a person to confirm an action the agent has already decided on. A clarifying question asks for missing information before the agent decides what to do. Both pause the run, and both can use the same channels and risk tiers, but they answer different questions and should be logged separately so you can see which one is slowing work down.
