An AI feature should ask a follow-up question when a missing detail could materially change the result, there is no safe and obvious default, and the user can provide the information. If the likely interpretation is clear and the cost of being wrong is low, the feature can often proceed while stating its assumption. If the uncertainty is about what the system knows, or the task needs human authorization, asking the user to clarify is not enough.
That’s a product-design decision, not just a prompting technique. Asking can improve an answer, but it also adds effort and interrupts the task. Research on clarification in language models treats it as a trade-off between the potential benefit of a better result and the cost of another interaction—not as a rule to ask whenever a request is ambiguous (NAACL Findings paper).
First ask: What kind of uncertainty is this?
A request is ambiguous when it could reasonably mean more than one thing. “Show me the best customers” might mean those who spend the most, order most often, or are most likely to buy again. The uncertainty is about the user’s intent.
A different problem arises when the intent is clear but the system lacks the information to do the job. If someone asks, “What did this customer order last year?” and the order history is unavailable, the problem is not ambiguous wording. The AI does not have the needed knowledge.
That distinction matters because a follow-up question can resolve unclear intent if the user knows what they mean. It cannot supply facts the system does not have. In the second case, the product should say what information is missing and offer a useful next step, such as asking the user to provide a record or directing them to a person who can check. Google’s People + AI Guidebook similarly describes explaining when a system cannot provide a reliable result and offering another path forward (Errors + Graceful Failure).
A practical decision rule: ask, assume, or stop
Use three questions to choose a response:
1. Could different interpretations lead to meaningfully different results or actions? 2. Is there a sensible, low-risk default that the user can easily correct? 3. Can the user actually resolve the uncertainty, and is it appropriate for them to do so?
If the difference matters, there is no safe default, and the user can answer, ask a focused question. If one interpretation is likely and a mistake is easy to reverse, proceed with a visible assumption. If the system lacks necessary knowledge, or the next step requires authorization or human judgment, stop or hand off instead.
This is a practical heuristic, not a universal threshold. “Meaningfully different” depends on the task. A slightly different tone in a draft may be easy to fix; a different recipient or payment amount may not be.
Proceed with a stated assumption when the downside is small
Suppose a user asks an AI feature to draft a reply to a customer who wants to know when an order will arrive. If the order details are available and the user has not specified a tone, the feature might draft a concise, polite response using the business’s usual style. It can say, “I’ve drafted this in a neutral, professional tone.” The user can edit the draft before sending it.
The assumption is useful because it keeps the task moving, is visible, and is easy to correct. A hidden assumption is harder to catch: the user may not realize the AI interpreted “friendly” as informal, or “recent customers” as customers from the last 30 days.
A stated assumption should be brief and specific. “I’m assuming you mean customers with an order in the last 30 days” gives the user something concrete to confirm or correct. “I made some assumptions” does not.
Ask when the answer could change the outcome
Suppose a report request says, “Filter out inactive customers.” The definition of “inactive” could change who appears in the report: no purchase in 30 days, no purchase in a year, or no recent account activity. If the report will guide a sales campaign, that distinction may matter.
A useful follow-up names the missing choice: “What should count as inactive: no purchase in 90 days, no purchase in a year, or another period?” This is better than “Can you clarify?” because it points to the decision the system needs.
A good clarification question is tied to a consequential missing detail, answerable by the user, and narrow enough to avoid making them restate the whole task. If several details are missing, ask about the one most likely to change the result first. Asking a long series of questions can turn a quick task into a form.
The timing can also affect the experience. A 2026 study with 30 participants compared asking before generating an output with asking after an initial output, across text and image tasks. The authors reported trade-offs, including greater cognitive effort alongside higher confidence in evaluating reliability. The small study offers a useful reminder that clarification has interaction costs, but it does not establish one best timing for all products or users (Ask Before or After?).
Stop or hand off when a question cannot solve the problem
Imagine an AI preparing a refund. “Refund the customer” may be clear enough as an instruction, but the system might not know whether the order is eligible under the business’s policy. Asking “Do you want me to refund them?” does not establish eligibility. The uncertainty is about the facts or the rules, not the user’s intent.
Or the system may have enough information to prepare the refund but still should not issue it without approval. That is a separate checkpoint.
Clarification asks what the user means. Confirmation asks whether they approve a proposed action. Human approval may be required even after the intent is clear—for example, before sending money, issuing a refund, or sending a sensitive message. A clarification question is not, by itself, a safety control or authorization step.
A product should make these boundaries clear. It might prepare a refund request, explain what information is missing, or send the case to a person for review. It should not disguise an unanswered policy question as a request for the user to repeat their instruction.
Test whether the question earns its interruption
A follow-up is not automatically useful just because it reduces ambiguity. Builders can review a sample of tasks and ask: Did the question change the result? Could the feature have made a safe, visible assumption instead? Did the user answer, abandon the task, or correct the output later?
Track the questions that matter to your workflow, rather than treating a high or low question rate as success on its own. If users repeatedly give the same answer, a sensible default may be better. If a question often prevents a costly misunderstanding, it may be worth the extra step. And if users cannot answer it, the right response may be to improve the system’s information or provide a human handoff.
The useful principle is simple: ask when the user’s answer can change an important outcome; state an assumption when the default is safe and easy to correct; stop when the uncertainty requires knowledge or authority the user’s answer cannot provide.
