{"course":{"slug":"building-with-ai","title":"Building with AI","url":"https://addaly.com/learn/building-with-ai","level":"intermediate","track":"build"},"lesson":{"slug":"asking-instead-of-guessing","title":"Asking instead of guessing: clarifying questions, slot filling and when a form beats a chat","url":"https://addaly.com/learn/building-with-ai/asking-instead-of-guessing","position":46,"of":80,"minutes":8,"answer":"A model's default is to resolve ambiguity by guessing, so decide explicitly when a missing detail changes the action and cannot be safely defaulted, ask then, one question at a time.","keyIdea":"A model's default is to resolve ambiguity by guessing, so decide explicitly when a missing detail changes the action and cannot be safely defaulted, ask then, one question at a time, and otherwise state the assumption aloud, and recognise that fixed, structured input is a form's job, not a conversation's."},"body":{"format":"markdown","text":"## The model's default is to answer\n\nAsk a model to \"book a flight to Delhi\" and it will pick a date. Ask for \"a summary\" and it will pick a length. The model resolves every ambiguity by choosing the most probable interpretation and proceeding, because that is what it was trained to do, and in a chat about films that is harmless. In a system that acts (books, sends, deletes, spends) a guess is an action taken on a decision the user never made.\n\nThe opposite failure is just as real. An assistant that asks three questions before doing anything is abandoned. Every question costs a turn, and a share of users leave at each one.\n\n## When to ask\n\nA rule that survives contact with real products: ask when the missing information changes the action, cannot be defaulted safely, and costs the user less to answer than to correct afterwards. All three. If the date is missing from a flight booking, ask. If the cabin class is missing, default to economy and say so: \"I've assumed economy; tell me if not.\" The stated assumption is the tool that keeps the question count down without silently deciding for people.\n\n## Slot filling\n\nThe old technique from telephone menus is still the right one for structured tasks. Define the slots the action needs (origin, destination, date, passengers) and mark which are required. On each user message, run a structured-output extraction that fills whatever slots are present. Then ask for what is missing, and confirm before acting.\n\n```python\nREQUIRED = [\"origin\", \"destination\", \"date\", \"passengers\"]\nslots = extract(conversation, schema=FlightRequest)   # partial JSON allowed\nmissing = [s for s in REQUIRED if slots.get(s) is None]\nif missing:\n    ask_for(missing[0])            # the most consequential first, one at a time\nelse:\n    show_confirmation_card(slots)\n```\n\nAsk one thing per message. A message with four questions gets one answered, and the other three are asked again, which is worse than asking them in order.\n\n## The form-versus-chat decision\n\nHere is the thing a chat-first mindset misses. If the input is always the same five fields, a form is faster to fill, validates as you type, works with a screen reader, remembers the last values, and never misunderstands \"next Tuesday\". Chat is a worse interface for structured input, and dressing a form up as a conversation is a common way to make a product slower.\n\nChat wins when the input is open-ended, when the fields vary by situation, or when the user does not know what the fields are and needs to be walked to them. The strongest pattern is often both: the user types freely, the extraction fills a form that is visible on screen, and the user corrects the form directly rather than arguing with the assistant. The form is the contract; the chat is the way in.\n\n## Confirm before anything irreversible\n\nThe human-in-the-loop lesson in the agents module set the principle; here is its shape in a conversation. Before the action, show the parsed intent as a card, not as prose: \"Book: Mumbai to Delhi, 14 October, 2 adults, economy. Confirm?\" A card can be read in one glance and edited in place. A paragraph that restates the same thing is skimmed and approved without being read. Log the card as shown, because when a user says \"that is not what I asked for\", the card is the record of what they approved.\n\n## Measure it\n\nThree numbers tell you whether the balance is right. The clarification rate: the share of requests that trigger a question. Above roughly a third, either the extraction is weak or the product is asking for things it could default. The correction rate: how often a user changes the confirmation card or the answer. High corrections with low clarifications means the assistant is guessing too much. And abandonment after a question: what share of users leave without answering. That last number is the cost of asking, and it is usually higher than teams expect.\n\n## The wording\n\nQuestions should be short and specific. \"Which date?\" beats \"Could you please provide some more details about your preferred travel date so that I can assist you better?\": by six words that carry no information and a tone that reads as a form letter. Where the answer is one of a few options, offer them as buttons; a tap is cheaper than a sentence, on a phone especially."},"check":{"question":"A booking assistant is redesigned to always ask for cabin class, meal preference and seat position before searching flights. Completion rates fall sharply. What principle was violated?","options":[{"text":"The questions were asked in the wrong order; date and destination should come before preferences, and reordering them would restore completion.","correct":false,"tempting":"Order matters, but the failure here is that three questions were asked at all for details that could have been defaulted."},{"text":"Ask only when a missing detail changes the action and has no safe default; these did, and every question costs abandonment.","correct":true},{"text":"The assistant should have used a form for all fields instead of asking in chat.","correct":false,"tempting":"A form suits fixed structured input, but the core error is asking for information that needs no answer, in any interface."},{"text":"Clarifying questions should be batched into one message so the user answers all three at once.","correct":false,"tempting":"Batching tends to get one of three answered; it does not reduce the cost of asking unnecessary questions."}]},"prev":{"slug":"memory-across-sessions","title":"Memory across sessions, and what a user must be able to see","url":"https://addaly.com/learn/building-with-ai/memory-across-sessions"},"next":{"slug":"the-chat-interface-honestly","title":"The chat interface: the controls that are load-bearing","url":"https://addaly.com/learn/building-with-ai/the-chat-interface-honestly"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Asking instead of guessing: clarifying questions, slot filling and when a form beats a chat', in Building with AI. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/building-with-ai/asking-instead-of-guessing (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Asking instead of guessing: clarifying questions, slot filling and when a form beats a chat","courseTitle":"Building with AI","module":{"index":5,"slug":"conversation-memory-and-the-interface","title":"Conversation, memory and the interface"},"answer":null,"keyIdea":"A model’s default is to resolve ambiguity by guessing, so decide explicitly when a missing detail changes the action and cannot be safely defaulted, ask then, one question at a time, and otherwise state the assumption aloud, and recognise that fixed, structured input is a form’s job, not a conversation’s.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"the-model-s-default-is-to-answer","runs":[{"text":"The model’s default is to answer"}]},{"t":"p","runs":[{"text":"Ask a model to “book a flight to Delhi” and it will pick a date. Ask for “a summary” and it will pick a length. The model resolves every ambiguity by choosing the most probable interpretation and proceeding, because that is what it was trained to do, and in a chat about films that is harmless. In a system that acts (books, sends, deletes, spends) a guess is an action taken on a decision the user never made."}]},{"t":"p","runs":[{"text":"The opposite failure is just as real. An assistant that asks three questions before doing anything is abandoned. Every question costs a turn, and a share of users leave at each one."}]},{"t":"h2","id":"when-to-ask","runs":[{"text":"When to ask"}]},{"t":"p","runs":[{"text":"A rule that survives contact with real products: ask when the missing information changes the action, cannot be defaulted safely, and costs the user less to answer than to correct afterwards. All three. If the date is missing from a flight booking, ask. If the cabin class is missing, default to economy and say so: “I’ve assumed economy; tell me if not.” The stated assumption is the tool that keeps the question count down without silently deciding for people."}]},{"t":"h2","id":"slot-filling","runs":[{"text":"Slot filling"}]},{"t":"p","runs":[{"text":"The old technique from telephone menus is still the right one for structured tasks. Define the slots the action needs (origin, destination, date, passengers) and mark which are required. On each user message, run a structured-output extraction that fills whatever slots are present. Then ask for what is missing, and confirm before acting."}]},{"t":"code","lang":"python","label":"Python","text":"REQUIRED = [\"origin\", \"destination\", \"date\", \"passengers\"]\nslots = extract(conversation, schema=FlightRequest)   # partial JSON allowed\nmissing = [s for s in REQUIRED if slots.get(s) is None]\nif missing:\n    ask_for(missing[0])            # the most consequential first, one at a time\nelse:\n    show_confirmation_card(slots)"},{"t":"p","runs":[{"text":"Ask one thing per message. A message with four questions gets one answered, and the other three are asked again, which is worse than asking them in order."}]},{"t":"h2","id":"the-form-versus-chat-decision","runs":[{"text":"The form-versus-chat decision"}]},{"t":"p","runs":[{"text":"Here is the thing a chat-first mindset misses. If the input is always the same five fields, a form is faster to fill, validates as you type, works with a screen reader, remembers the last values, and never misunderstands “next Tuesday”. Chat is a worse interface for structured input, and dressing a form up as a conversation is a common way to make a product slower."}]},{"t":"p","runs":[{"text":"Chat wins when the input is open-ended, when the fields vary by situation, or when the user does not know what the fields are and needs to be walked to them. The strongest pattern is often both: the user types freely, the extraction fills a form that is visible on screen, and the user corrects the form directly rather than arguing with the assistant. The form is the contract; the chat is the way in."}]},{"t":"h2","id":"confirm-before-anything-irreversible","runs":[{"text":"Confirm before anything irreversible"}]},{"t":"p","runs":[{"text":"The human-in-the-loop lesson in the agents module set the principle; here is its shape in a conversation. Before the action, show the parsed intent as a card, not as prose: “Book: Mumbai to Delhi, 14 October, 2 adults, economy. Confirm?” A card can be read in one glance and edited in place. A paragraph that restates the same thing is skimmed and approved without being read. Log the card as shown, because when a user says “that is not what I asked for”, the card is the record of what they approved."}]},{"t":"h2","id":"measure-it","runs":[{"text":"Measure it"}]},{"t":"p","runs":[{"text":"Three numbers tell you whether the balance is right. The clarification rate: the share of requests that trigger a question. Above roughly a third, either the extraction is weak or the product is asking for things it could default. The correction rate: how often a user changes the confirmation card or the answer. High corrections with low clarifications means the assistant is guessing too much. And abandonment after a question: what share of users leave without answering. That last number is the cost of asking, and it is usually higher than teams expect."}]},{"t":"h2","id":"the-wording","runs":[{"text":"The wording"}]},{"t":"p","runs":[{"text":"Questions should be short and specific. “Which date?” beats “Could you please provide some more details about your preferred travel date so that I can assist you better?”: by six words that carry no information and a tone that reads as a form letter. Where the answer is one of a few options, offer them as buttons; a tap is cheaper than a sentence, on a phone especially."}]}],"check":{"question":[{"text":"A booking assistant is redesigned to always ask for cabin class, meal preference and seat position before searching flights. Completion rates fall sharply. What principle was violated?"}],"options":[{"text":[{"text":"The questions were asked in the wrong order; date and destination should come before preferences, and reordering them would restore completion."}],"correct":false,"tempting":[{"text":"Order matters, but the failure here is that three questions were asked at all for details that could have been defaulted."}]},{"text":[{"text":"Ask only when a missing detail changes the action and has no safe default; these did, and every question costs abandonment."}],"correct":true,"tempting":null},{"text":[{"text":"The assistant should have used a form for all fields instead of asking in chat."}],"correct":false,"tempting":[{"text":"A form suits fixed structured input, but the core error is asking for information that needs no answer, in any interface."}]},{"text":[{"text":"Clarifying questions should be batched into one message so the user answers all three at once."}],"correct":false,"tempting":[{"text":"Batching tends to get one of three answered; it does not reduce the cost of asking unnecessary questions."}]}],"order":[0,2,3,1],"why":null},"prev":{"slug":"memory-across-sessions","title":"Memory across sessions, and what a user must be able to see","minutes":10},"next":{"slug":"the-chat-interface-honestly","title":"The chat interface: the controls that are load-bearing","minutes":9}}}