PTN—12

Follow-up questions

When a request underdetermines the task, ask one specific clarifying question — with tappable answers — instead of guessing.

Every ambiguous prompt forces a choice: guess, or ask. Guessing is cheap for the machine and expensive for the person — a confident answer to the wrong question costs a full round trip to diagnose, correct, and retry. A follow-up question spends five seconds of the user’s attention to buy back that entire loop. The pattern is not “ask more questions”; it is asking exactly one, at exactly the moment the ambiguity would otherwise become a wrong answer.

The craft is in the question’s shape. “Can you clarify?” is a non-question — it hands the ambiguity straight back and makes the person do the diagnostic work the system should have done. A good follow-up is specific and closed: it names the fork the system actually hit — “Summarize for the customer, or for the internal team?” — and offers the plausible answers as one-tap options. The options themselves are capability disclosure: they show the person which distinctions the system can act on.

What happens after the answer matters as much as the question. Fold the reply into a restated plan — “Right: a customer-facing summary, two paragraphs” — so the person can confirm the system heard them before effort is spent. And keep the original request visible throughout; a clarifying exchange that scrolls the prompt away forces people to hold their own intent in working memory while answering questions about it.

The discipline is restraint. A follow-up question is an interruption, and its exchange rate flips with stakes: before a twenty-minute research run it is the only respectful design, before a one-line answer it is pure friction. Systems that interrogate every request train people to dread the question; systems that never ask train people to write defensive, over-specified prompts. The mature version asks rarely, asks well, and demonstrably uses the answer.

Anatomy

Fig. 01 — Follow-up questionsLive specimen

Book a maintenance visit for Harrison Heating & Air next week.

Their Marsh Creek agreement covers two systems. Which is this visit for?

An ambiguous request answered with one closed clarifying question, tappable options, and a restated plan.

1Persistent original request. The prompt stays visible while the question is asked, so the person never answers from memory.
2Closed, specific question. The question names the actual fork and offers options — never a generic “can you clarify?”.
3One-tap answer chips. Suggestion chips make answering as cheap as the question was to read.
4Restated plan. The answer is folded into a restated plan before work starts, proving the system heard it.

When to use

The request is ambiguous in a way that materially changes the output, and the fork is nameable.
The downstream work is expensive enough that a wrong guess wastes real time or money.
Users routinely get answers to a different question than the one they meant.
The plausible interpretations are enumerable — a closed question with options beats an open one.

Design considerations

01Ask only when the answer would change the output; clarification as ritual teaches people to ignore it.
02Make the question closed and specific — name the fork, offer the plausible answers as chips.
03Always include a typed-answer escape alongside the chips; the options scope the question, not the reply.
04Cap it at one round; a second question is a sign the first was badly chosen.
05Restate the resolved request before executing, so confirmation is a glance, not an audit.
06Let people skip the question and run the raw request — the impatient path must stay open.

Pitfalls

✕The interrogation: clarifying questions on trivial requests, adding a form to what should be a sentence.
✕“Can you provide more details?” — an open non-question that returns the ambiguity to sender.
✕Asking, then ignoring: the person picks an option and the output shows no trace of it, which poisons every future question.
✕Questions whose options overlap or omit the person’s actual intent, forcing a lie to get past the gate.

In the wild

ChatGPT: Deep research asks a short round of scoping questions — angle, depth, constraints — before committing minutes of paid compute to a brief.
Claude: Claude Code surfaces clarifying questions during planning when a task is underdetermined, resolving the fork before any files change.
Perplexity: Pro searches interject a clarifying question with selectable options when a query is ambiguous, narrowing scope before sources are pulled.