The Socratic check
When the model asks before answering.
The cheapest way to double the usefulness of any AI response is to verify its premise. One sharp clarifying question, asked before the model spends a thousand tokens on the wrong answer, costs less than the round-trip of reading an unhelpful reply and re-prompting.
Most products refuse to ask. They've been trained — by roadmap pressure and by the unconscious belief that asking looks like incompetence — to always answer. The better move is the opposite. Ask one question. Make it a good one. Then answer well.
"A clarifying question is a compliment, if it's the right one."
One question, two or three chips, one escape.
The Socratic check is a three-part affordance. A short question that names the exact ambiguity. Two to three tappable chips that resolve it in one click. A subtle escape that lets the user say "skip and guess anyway" — with the model naming its assumption.
The chips are what separate this from every generic "Can you tell me more about your request?" reply. A chip is a pre-committed path. The user taps it once and is back in a responsive product, not an interrogation.
Can you summarize the product launch notes?
Do you mean the April launch or the Q2 go-to-market plan?
The clarifying turn costs one round-trip. A wrong guess costs a session.
Wrong premise, wasted turn.
Every long, confidently wrong AI answer you've ever read started with a misread premise. The model assumed the user meant the April launch when they meant the Q2 plan. The model assumed the team to invite when there are four teams with that name in the workspace. The answer is fine; it's an answer to a different question.
The Socratic check costs one round-trip and saves a session. You're not interrogating the user. You're showing them the fork in the road, and letting them pick.
The clarifier I'd ship.
- Ask only when the cost of guessing is real. A quick factual lookup doesn't need this. A plan, a draft, or anything touching a tool on the user's behalf does.
- Offer a skip. If the user is in a hurry, they should be able to tap past your clarifier — with the model naming the assumption it will make. This is what separates the pattern from a gate.
- Show the source of the ambiguity. Ideally the question is anchored to the part of the prior turn that made it ambiguous. "Your last message mentioned two projects; which one did you mean?" reads as thoughtful. Asking in the abstract reads as evasive.
The performative ask.
Some products have learned to ask a question for the look of thoughtfulness, then ignore the answer and produce a generic reply. This is worse than not asking. It costs the user a turn, adds zero information to the response, and trains the user to skip the clarifier next time.
If you ask, use the answer. If you aren't going to use the answer, don't ask.
What this pattern gets wrong when it gets wrong.
- Confidence theater
- Language or typography that performs certainty beyond what the model actually has.
- Ambiguous state
- Running, done, errored, paused all look the same. The user has to infer from context.
- Implicit refusal
- Declining a request without saying the word no — a vague answer, a pivot, a change of subject.
Three shipping variants worth copying.
- A single short question with two or three tap-answer chips
- A 'skip and guess anyway' escape that names the assumption
- A sidebar note showing which prior turn made the premise ambiguous