Clarification Cost-Benefit Decision Prompt

This prompt is designed for AI engineers and product teams building conversational agents who need a programmatic, repeatable way to decide whether to ask a clarifying question or proceed with an assumption. The core job-to-be-done is to minimize user friction and context waste by making this trade-off explicit. The ideal user is a developer wiring this prompt into an agent's dialogue management loop, where the output of this prompt directly controls the next system action: ask_clarification or proceed_with_assumption. It is not a general-purpose chatbot improvement tip; it is a decision component for a production system.

Use this prompt when the cost of a wrong assumption is measurable—such as executing an incorrect tool call, routing a ticket to the wrong queue, or providing a factually wrong answer from a knowledge base. It is most effective when you can define concrete thresholds for confidence_score and cost_of_clarification (e.g., in tokens, latency, or user satisfaction points). The prompt requires you to supply the current user utterance, the top candidate interpretation, its confidence score, and a structured definition of the cost of asking versus the cost of being wrong. Do not use this prompt for trivial disambiguations where the cost of being wrong is near zero, or in open-ended chitchat where user intent is inherently exploratory.

Before integrating this prompt, ensure your upstream intent classifier or NLU system can produce a calibrated confidence score. If your system cannot distinguish between 0.85 and 0.95 confidence, this prompt will add latency without improving decisions. The next step is to wire the structured output into your dialogue manager's branching logic, and to log every decision for offline evaluation of your clarification rate and false-positive assumption rate. Avoid using this prompt as a replacement for improving your intent classifier's accuracy; it is a safety net for ambiguous cases, not a fix for a broken upstream model.

The prompt template below is designed to be copied directly into your prompt library or orchestration layer. It forces a structured cost-benefit decision before consuming a turn on clarification. Every placeholder is enclosed in square brackets. Replace them with your application's concrete values before sending the prompt to a model. The template separates the decision logic from the output format so you can swap the schema without rewriting the reasoning instructions.

textCopy
You are a clarification cost-benefit analyzer for a production AI assistant. Your job is to decide whether to ask the user a clarifying question or to proceed with a documented assumption.

## INPUT
User message: [USER_MESSAGE]
Conversation history (last N turns): [CONVERSATION_HISTORY]
Current task context: [TASK_CONTEXT]
Available clarification budget remaining: [CLARIFICATION_BUDGET]

## DECISION RULES
1. Identify every ambiguity, missing slot, or conflicting intent in the user message.
2. For each ambiguity, estimate:
   - The probability that your best-guess assumption is correct (0.0-1.0).
   - The cost of being wrong if you proceed without clarifying (CRITICAL, HIGH, MEDIUM, LOW).
3. A clarification question is warranted only when:
   - Assumption confidence is below [CONFIDENCE_THRESHOLD] AND the cost of being wrong is HIGH or CRITICAL.
   - OR the clarification budget has at least 1 remaining turn AND the question can be answered with a short constrained response.
4. If multiple ambiguities exist, select the single highest-impact ambiguity to clarify. Do not ask more than one question.
5. If you decide to proceed, you MUST state your assumption explicitly in the output.

## CONSTRAINTS
- Never ask open-ended clarification questions. Every question must include constrained options or a specific data type request.
- Never exceed the remaining clarification budget.
- If the user has already answered this question in the conversation history, do not ask again.
- If the cost of being wrong is LOW, prefer proceeding with an assumption.

## OUTPUT SCHEMA
Return a JSON object with exactly these fields:
{
  "decision": "CLARIFY" | "PROCEED",
  "reasoning": "One-sentence explanation of the decision.",
  "assumption_if_proceeding": "The assumption you will use if proceeding, otherwise null.",
  "clarification_question_if_clarifying": "The single constrained clarification question, otherwise null.",
  "ambiguity_details": [
    {
      "ambiguity": "Description of the ambiguous element.",
      "best_guess": "Your best-guess interpretation.",
      "confidence": 0.0-1.0,
      "wrong_cost": "CRITICAL" | "HIGH" | "MEDIUM" | "LOW"
    }
  ]
}

To adapt this template, replace the placeholders with your application's runtime values. [CONFIDENCE_THRESHOLD] should be tuned per use case—start at 0.8 for high-stakes domains like healthcare or finance, and 0.6 for exploratory or low-risk workflows. [CLARIFICATION_BUDGET] should be decremented by your application layer after each CLARIFY decision. The [TASK_CONTEXT] field should carry structured slot state, not raw conversation text, so the model can check for already-collected values without re-scanning history. If your application cannot provide structured slot state, add a [COLLECTED_SLOTS] placeholder and populate it with a JSON map of known values.

Before deploying, validate that the model reliably returns parseable JSON matching the output schema. Run at least 50 labeled examples through the prompt and measure false-positive clarification rate (CLARIFY decisions where PROCEED was correct) and false-negative rate (PROCEED decisions where CLARIFY was correct). If the model over-clarifies, raise [CONFIDENCE_THRESHOLD] or adjust the cost-of-being-wrong criteria. If it under-clarifies, lower the threshold or add domain-specific examples of costly wrong assumptions to the [TASK_CONTEXT] field. Never ship this prompt without a JSON schema validator in your harness that rejects malformed outputs and triggers a retry or fallback.

The Clarification Cost-Benefit Decision Prompt is designed to be invoked as a decision node within a larger conversational or agentic workflow, not as a standalone chatbot. It should sit between the system's initial interpretation of a user turn and the action dispatcher. The prompt receives a structured input containing the user's utterance, the current dialogue state, the system's top hypothesis, and any relevant tool or retrieval results. Its output is a machine-readable decision object that downstream code uses to either branch into a clarification sub-flow or proceed with the assumed action. This means the prompt's primary consumer is not the end user but your application logic.

Integration pattern: Wrap the prompt in an async function with a strict timeout (e.g., 2-3 seconds for fast models). The function should accept a typed input object matching the prompt's [INPUT] placeholder and return a parsed JSON decision. Implement a validation layer immediately after the model response using a schema validator like Pydantic or Zod. The validator must enforce the decision enum (clarify | proceed), the presence of rationale when clarifying, and the disclosure_text when proceeding. If validation fails, retry once with the validation error message appended to the prompt as [PREVIOUS_ERROR]. If the retry also fails, default to a safe fallback: clarify with a generic re-prompt. This prevents a parse failure from silently proceeding with an ungrounded assumption.

Model choice and tool use: This prompt benefits from models with strong instruction-following and structured output capabilities. For production, prefer a model that supports JSON mode or function calling natively, and supply the output schema as a tool definition rather than relying solely on the markdown schema in the prompt. Do not give this prompt access to external tools or retrieval during its decision step—it should reason only from the provided [CONTEXT] and [DIALOGUE_STATE] to avoid introducing new information that could bias the cost-benefit analysis. Logging is critical: log every decision with the full input, output, validation status, and the downstream action taken. This creates an audit trail for tuning the [CONFIDENCE_THRESHOLD] and [CONTEXT_BUDGET_REMAINING] parameters over time.

Human review and high-risk gating: For domains where an incorrect assumption carries significant cost (e.g., healthcare, finance, legal), add a human review gate when the model decides to proceed with an assumption but the confidence score falls in a 'yellow' band (e.g., 0.70–0.90). In this case, surface the disclosure_text and the assumed action to a review queue before execution. This turns the prompt from an autonomous decision-maker into a triage assistant that pre-fills the review form. Avoid wiring this prompt directly to a destructive or irreversible action without such a gate. The next step after implementing the harness is to run the eval suite from the Prompt QA pillar, specifically testing for false-positive clarification rates and user friction scoring as described in the topic's eval criteria.