Ask Before Answering: Self-Ask, Clarification, and Assumption Discovery

A user types three words into your assistant. The model returns a confident, well-formatted, entirely wrong answer to a question nobody asked. The user replies, "that's not what I meant," and you go back to editing the system prompt.

That loop is the wrong loop. The failure is not that your instructions were too vague. The failure is that your system made an ambiguity decision silently, at runtime, with no policy governing it. Ambiguity is not a prompt-writing problem you fix upstream once. It is a per-request decision your system has to make, bound, and measure.

This article builds that decision policy: when the model should ask, when it should infer and declare, and when it should just answer.

The Silent Guess Is the Real Failure Mode

Two failure modes sit at opposite ends of the same dial. At one end, the model fills every gap with an invented assumption: scope, format, audience, constraints, all fabricated to make the request complete. At the other end, the model interrogates. Five questions before it does anything, and the user closes the tab.

Most teams fight the wrong one. They see a bad answer and assume the prompt was underspecified, so they add more instructions. But the silent guess is worse than it looks precisely because it is invisible. A fluent, well-structured answer reads as competence. The wrong assumption hides inside the formatting until the user acts on it — books the flight, runs the migration, ships the schema.

The distinction that matters is not "is the prompt vague." It is "what does a wrong resolution cost."

Recoverable ambiguity is cheap. The user reads the answer, sees the wrong interpretation, and corrects it in one turn. Expensive ambiguity is not. If the answer drives a booking, a database schema, a migration, a purchase, or a code change, the correction arrives after the damage.

The invariant the rest of this article builds toward: never resolve ambiguity silently when the cost of a wrong resolution exceeds the cost of one question.

That exchange rate is a property of the task, not of the model. A three-word request for a dinner recommendation and a three-word request to "clean up the users table" carry the same ambiguity and wildly different downside. Your policy has to read the task, not the word count.

Three Moves: Ask, Infer, or Proceed

Before any implementation, fix the vocabulary. At runtime, the system has exactly three actions available.

Proceed. The request is complete enough that any remaining gap is cosmetic or trivially correctable. Answer directly.

Infer-and-declare. The model picks the most defensible interpretation, states it in one line, and answers. This is the middle option most teams skip entirely — they jump from "answer" to "ask" and never build the third path.

Ask. The missing information is user-specific, decision-changing, and not derivable from context or tools.

The trigger for asking is not "the prompt feels vague." It is a sharper test: does the missing slot change the output in a way the user would reject? If yes, and the slot is not derivable, ask. If the change is cosmetic, proceed. If the slot is derivable, infer and declare.

One boundary worth stating plainly: this is a conceptual decision model, not a guarantee about any specific model version. Different models and system prompts shift the default behavior — some lean toward asking, some are explicitly tuned to never ask and instead cover all plausible intents. The policy has to be enforced by instructions and verified by evaluation, not assumed from the model's disposition.

Self-Ask Is Not the Same as Asking the User

Two techniques share vocabulary and get conflated constantly. They solve different problems and carry different costs.

Self-ask prompting has the model state and answer its own follow-up sub-questions before producing a final answer. It targets compositional questions — the kind where the model would otherwise try to answer in one leap and drop a step. The scaffold is structural: an explicit marker for the follow-up question, then its answer, then a clearly delimited final answer that downstream code can parse.

The practical payoff is not just better reasoning. Because the sub-questions are explicit, you can route them. A follow-up question that needs a fact the model does not reliably hold can be sent to a search step or a tool call instead of being answered from parametric memory. The structure turns an internal reasoning step into a routable one.

Question: Who lived longer, X or Y?

Are follow up questions needed here: Yes.
Follow up: How old was X when they died?
Intermediate answer: X was 65.
Follow up: How old was Y when they died?
Intermediate answer: Y was 69.
So the final answer is: Y.

Clarification prompting targets something else entirely: missing user intent, not missing reasoning steps. A model can self-ask perfectly and still answer the wrong question, because self-ask never touches the gap between what the user said and what the user meant.

Failure mode: rendering self-ask output as the user-facing answer. The user does not want to read the model's internal sub-questions. Keep them in a separate channel or strip them before display.

Designing the Clarification Contract

The decision policy becomes implementable when you specify what the model is allowed to ask, how much, and what it must do instead.

Cap the question count. A small fixed ceiling — one to three questions — keeps friction bounded and forces prioritization. An uncapped model will ask about everything it notices, including things that do not matter.

Require specific, answerable questions. A question should be a slot to fill, not an open "can you tell me more." "Which environment — staging or production?" is answerable. "Can you clarify?" is not.

Require a fallback path. If there is no user in the loop — a batch job, an offline pipeline, a latency budget that forbids a round trip — the model must present two or three labeled interpretations with explicit assumptions rather than silently choosing one.

Make the assumption visible. A one-line "I assumed X; say so if you meant Y" converts a hidden assumption into a correctable one. This is the cheapest reliability improvement available, and it costs a sentence.

Separate the ask decision from the answer decision in the control flow. If the ask is buried inside generation, you cannot log it, count it, or tune it. Make it a distinct step.

Handle freshness honestly. When the request depends on facts that may have changed — prices, releases, policies — and no tool is available, prefer a general answer with an explicit freshness caveat over a fabricated specific. Never invent exact figures to fill the gap.

Assumption Discovery: Surfacing What the User Left Out

Most teams hope the model notices gaps. Hope is not a mechanism. Enumerate the slots a request must fill for the task to be executable, then classify each one.

The slots are usually some subset of: goal, audience, scope, format, constraints, success criteria, and user-specific data. For each, assign one of three states.

Only the third category is a candidate. And "candidate" is not "automatic" — it still has to be decision-changing to earn a turn.

Derivable slots should be inferred and declared, never asked about. Asking for something the system could have looked up is the fastest way to make an assistant feel incompetent. If the user's timezone is in their profile, do not ask what timezone they are in.

A short pre-answer pass that lists the missing slots and their impact is cheap and catches the expensive ambiguities before generation commits to an interpretation.

Common mistake: treating every unstated preference as a required question. Most unstated preferences have safe defaults. Only decision-changing ones deserve a turn.

Controlling Friction and Measuring the Policy

Without measurement, clarification behavior drifts. It never stays calibrated on its own; it slides toward silence or interrogation depending on whatever the last prompt edit emphasized.

Track a small set of observable signals:

• Clarification rate — how often the system asks
• Questions per clarification — whether the cap is holding
• User answer rate — whether users actually respond
• Abandonment after a question — whether asking drives users away
• Rework rate — follow-up turns that correct the original answer

The two failure directions have distinct signatures. High rework with a low clarification rate means the model guesses too much. High abandonment with a high clarification rate means it asks too much. You can read which way you are drifting from two numbers.

Build a small labeled set of underspecified requests with the interpretation you would accept, then check whether the policy asks, infers, or proceeds as intended. This does not need to be large. A dozen well-chosen cases will expose a policy that is systematically wrong.

Tune the threshold, not the prose. If the model asks too often, raise the bar for what counts as decision-changing. Adding "be concise" to the prompt changes the wording of the questions, not the decision to ask them.

One honest caveat: clarification quality depends on model version, system prompt, and tool availability. Change any of those and the behavior shifts. Re-run the check after each change rather than assuming the policy still holds.

When Not to Ask

Clarification prompting is the wrong tool in several common situations, and applying it everywhere is its own failure mode.

High-volume, low-stakes requests. When the user wants a fast default and can correct cheaply, asking adds latency and annoyance for no gain. Answer, declare the assumption, move on.

Batch and offline jobs. No user is in the loop. The fallback is labeled interpretations, not questions.

Ambiguity in the world, not in the user's intent. If the missing information is a fact about the world — a current price, a recent release — the fix is a tool call or retrieval, not a question. Asking the user to supply facts your system should look up is a category error.

Questions the user already answered. Re-asking is a state-tracking bug, not a clarification policy. If your assistant asks for the same detail twice in one session, fix the state, not the prompt.

Adjacent techniques solve neighboring problems and should not be absorbed into clarification. Reframing and attention prompting change how the model represents the problem internally. Prompt contracts define what a complete request looks like in the first place. Clarification sits between them: it handles the gap between a request that is complete by contract and a request that is complete in the user's head.

The Decision Rule

On the next request your system receives, classify the missing slot. Given, derivable, or genuinely missing.

If it is genuinely missing and decision-changing, ask one specific question. If it is derivable, infer and declare the assumption in one line. If it is cosmetic, proceed.

Then do the concrete work: write the three-move policy as an explicit instruction block — proceed, infer-and-declare, ask, with the cap and the fallback path spelled out. Run it against a handful of underspecified requests. Log clarification rate and rework rate for a week before you touch the threshold. The policy is not the prompt text. The policy is the decision the system makes, and the only way to know whether it is making the right one is to watch it decide.