Probing Question Formulation Prompt Template

This prompt is designed for product teams building diagnostic or troubleshooting agents where the user's initial problem description is almost always a symptom, not the root cause. The core job-to-be-done is to prevent the agent from collecting surface-level arguments and calling a tool with incomplete or misleading information. Instead, the model generates a single, high-leverage probing question that forces the user to provide the underlying causal signal—for example, distinguishing between 'the server is down' and 'the server is unreachable from my network because the VPN token expired.' The ideal user is an AI engineer or product manager integrating this prompt into a copilot or agent that must resolve ambiguous technical issues, operational incidents, or complex configuration problems where the first user utterance is rarely diagnostic.

You should use this prompt when your agent needs to actively uncover the root cause before taking action, and when the cost of acting on a symptom is high—such as restarting a production service unnecessarily, escalating to the wrong on-call team, or applying a configuration change that masks the real issue. The prompt assumes you have at minimum a user problem statement, and optionally diagnostic context such as recent log lines, error codes, system state snapshots, or a history of recent changes. It returns a structured output containing the probing question itself, the hypothesis being tested by the question, and the expected diagnostic value of the user's answer, so that downstream logic can decide whether to ask another question, call a tool, or escalate.

Do not use this prompt for simple data collection forms, FAQ-style chatbots, or workflows where the user has already provided a complete and unambiguous request. If your system only needs to extract a known set of required arguments—like an account number, a date range, and a report type—use a missing-argument detection prompt instead. This prompt is also inappropriate when latency is the primary concern and a wrong tool call is cheap to reverse; probing questions add a conversational turn, and that trade-off only makes sense when the cost of acting on bad information exceeds the cost of the delay. Finally, avoid this prompt in purely informational Q&A systems where the model is answering questions from a knowledge base rather than diagnosing a live system state.

This template is designed to be pasted directly into your system instructions or user-message template. It instructs the model to act as a diagnostic interviewer, formulating a single question that probes for the underlying cause of a user's reported problem. The prompt forces the model to distinguish between symptom-collection questions and root-cause questions, which is critical for troubleshooting agents where surface-level information gathering wastes turns and erodes user trust.

textCopy
You are a diagnostic interviewer. Your task is to formulate a single probing question that moves toward the root cause of a user's reported problem.

## INPUT
User Problem Statement: [USER_PROBLEM_STATEMENT]
Available Context (previous turns, system state, logs): [CONTEXT]
Domain or System Under Investigation: [DOMAIN]

## CONSTRAINTS
- Ask exactly ONE question.
- The question must probe for an underlying cause, not a surface symptom.
- Do not ask the user to repeat information already present in [CONTEXT].
- Do not suggest a solution or diagnosis in the question.
- The question must be answerable by the target user persona: [USER_PERSONA].
- If the problem statement already contains clear root-cause indicators, ask a question that validates or eliminates the most likely hypothesis.
- If insufficient information exists to form any hypothesis, ask a question that gathers the single most differentiating piece of missing data.

## OUTPUT FORMAT
Return a JSON object with these fields:
{
  "question": "The probing question text.",
  "target_hypothesis": "The root-cause hypothesis this question is designed to test or explore.",
  "information_gap": "The specific missing information this question aims to collect.",
  "question_type": "One of: causal_mechanism | temporal_sequence | boundary_condition | counterfactual | differentiating_factor",
  "confidence": 0.0-1.0 indicating how likely this question is to advance the diagnosis meaningfully.
}

## QUESTION TYPE DEFINITIONS
- causal_mechanism: Asks how or why something happened.
- temporal_sequence: Asks about timing, order, or what changed before/after.
- boundary_condition: Asks about scope, affected vs. unaffected components, or limits.
- counterfactual: Asks what happened when a condition was different.
- differentiating_factor: Asks about a variable that distinguishes between competing hypotheses.

## EXAMPLES
User Problem: "The API keeps returning 500 errors."
Context: "Deployed v2.3.1 to production 10 minutes ago. Error rate spiked immediately after deploy. All endpoints affected."
Output:
{
  "question": "What specific change in v2.3.1 touched the shared authentication middleware?",
  "target_hypothesis": "A change in shared middleware is causing cascading failures across all endpoints.",
  "information_gap": "Which specific code change correlates with the failure onset.",
  "question_type": "causal_mechanism",
  "confidence": 0.85
}

User Problem: "My laptop is running slow."
Context: "No prior diagnostics. User is non-technical."
Output:
{
  "question": "Is the slowness constant or does it get worse when you open specific applications?",
  "target_hypothesis": "Application-specific resource contention vs. systemic issue.",
  "information_gap": "Whether the problem is tied to specific workloads or is ambient.",
  "question_type": "boundary_condition",
  "confidence": 0.72
}

To adapt this template for your application, replace the square-bracket placeholders with your runtime values. [USER_PROBLEM_STATEMENT] should be the raw user input. [CONTEXT] should include any prior conversation turns, system state, logs, or retrieved knowledge that the model can reference to avoid asking redundant questions. [DOMAIN] helps the model calibrate its technical depth—use values like "cloud infrastructure," "web application," or "clinical diagnostics." [USER_PERSONA] should describe the user's technical level and access to information, such as "non-technical end user" or "on-call SRE with access to dashboards." The output schema is designed to be machine-readable so you can log the model's diagnostic reasoning alongside the question for later evaluation. If your use case involves regulated domains, add a [RISK_LEVEL] placeholder and a constraint that high-risk scenarios require the question to be reviewed by a human before being shown to the user.

The probing question formulation prompt is designed to sit inside a diagnostic agent loop where the model has already identified that the user's problem description is insufficient for root-cause analysis. Wire this prompt as a synchronous decision step that executes after the initial user input is parsed but before any diagnostic tool calls are made. The harness should pass the user's original message, any conversation history, and the current set of known symptoms as [INPUT]. The [CONTEXT] placeholder should be filled with a structured summary of what the system already knows: confirmed symptoms, ruled-out causes, and any tool results already collected. This prevents the model from asking questions that have already been answered.

Validation and retry logic is critical here because a poorly formulated probing question wastes user attention and delays diagnosis. After the model returns a question, validate it against three criteria before showing it to the user: (1) the question must not ask for information already present in the conversation state, (2) the question must target a specific causal mechanism rather than collecting another surface-level symptom, and (3) the question must be answerable by the user without requiring technical knowledge they haven't demonstrated. If validation fails, retry with the validation errors appended to [CONSTRAINTS] and a note about which rule was violated. Set a maximum of two retries before falling back to a generic clarification template. Log every validation failure for prompt improvement cycles.

Model choice and tool integration depend on your latency budget. For real-time chat, use a fast model (Claude 3 Haiku, GPT-4o-mini) with a strict output schema that returns only the question string and a rationale field explaining which causal path the question targets. For async or batch diagnostic workflows, a stronger model (Claude 3 Opus, GPT-4o) can produce richer rationales that feed into downstream root-cause ranking. Do not give this prompt access to diagnostic tools directly—it should only formulate questions. The question output should feed into the next turn of the conversation, and the user's answer should be parsed by a separate argument extraction prompt before any tool calls execute. This separation prevents the probing prompt from hallucinating tool arguments.

Evaluation and monitoring should track diagnostic efficiency, not just question quality. Instrument the harness to measure: (a) whether the user's answer to the probing question led to a confirmed root cause within the next N turns, (b) whether the question was ignored or overridden by the user, and (c) the average number of probing questions before a diagnostic tool call succeeds. Use an LLM judge to score sampled question-rationale pairs on causal relevance and specificity. If your diagnostic agent operates in a regulated domain (healthcare, industrial safety, financial fraud), require human review of probing questions before they reach the user when the [RISK_LEVEL] is set to high. Store all question-rationale pairs with conversation IDs for audit and prompt regression testing.