Ambiguous Intent Detection Prompt for Chat Routing

This prompt is designed for conversational AI builders who need to route user messages to the correct handler, queue, or agent. It sits between the user input and the routing decision, acting as a gate that detects when intent is too ambiguous to route confidently. Use this prompt when your system must avoid silent misrouting, when multiple intents could match a single user turn, or when underspecified requests would cause downstream handlers to hallucinate or fail. This prompt does not perform the routing itself. It produces a structured ambiguity assessment that your application code uses to either proceed with routing or pause and ask the user a targeted clarification question.

The ideal deployment scenario is a multi-skill chatbot, an agent mesh, or a support triage system where a single user message could reasonably map to several different workflows. For example, 'I can't access my account' could be a password reset, a permissions issue, or a billing hold. Routing this to the wrong handler creates a broken user experience and wastes downstream compute. This prompt forces the system to recognize that ambiguity and generate a specific, actionable clarification question rather than guessing. It is not a replacement for a well-designed intent classifier; it is a safety layer that catches the cases your classifier is least confident about. Wire it as a pre-routing check that runs after intent classification but before handler invocation, and only interrupt the user when the ambiguity score exceeds a configurable threshold.

Do not use this prompt for single-intent systems where only one action is possible, or for workflows where the cost of a wrong routing decision is negligible and can be corrected inline. It is also inappropriate for real-time, low-latency applications where a clarification round-trip would break the user experience contract—in those cases, prefer a default safe handler or a disambiguation UI element. When you deploy this prompt, pair it with an eval harness that measures two critical failure modes: false-positive interruptions that annoy users by asking for clarification when intent was actually clear, and false-negative passes that allow ambiguous requests to reach a handler that will fail silently. Track both rates in production and adjust your ambiguity threshold accordingly.

This template is designed to be placed as a pre-routing classification step in your chat pipeline. Before any downstream handler receives the user message, this prompt forces the model to assess whether the intent is clear enough to route confidently. If the intent is ambiguous, underspecified, or contains multiple competing intents, the prompt produces a structured ambiguity report and a targeted clarification question instead of guessing a route. This prevents the costly downstream errors that occur when a support bot fires a refund workflow for a billing question or a coding agent modifies files for a vague request.

textCopy
You are an intent classification and ambiguity detection system for a chat routing pipeline. Your job is to analyze the user's message and determine whether the intent is clear enough to route to a single handler. Do not execute any action. Do not answer the user's question. Only classify and, if necessary, request clarification.

## INPUT
User message: [USER_MESSAGE]
Conversation history (last 5 turns): [CONVERSATION_HISTORY]
Available routing targets: [ROUTING_TARGETS]

## CLASSIFICATION RULES
1. Identify the primary intent of the user's message.
2. If the message contains multiple distinct intents that would route to different handlers, flag as MULTI_INTENT.
3. If the message is missing critical parameters needed to route correctly (e.g., no product category for a refund request, no environment name for a deployment request), flag as UNDERSPECIFIED.
4. If the message contains contradictory constraints (e.g., "urgent" and "no rush," or "delete" and "archive"), flag as CONTRADICTORY.
5. If the message uses vague references ("it," "that thing," "the last one") that could refer to multiple entities in the conversation history, flag as AMBIGUOUS_REFERENCE.
6. If the intent is clear and maps to exactly one routing target, flag as CLEAR and provide the target.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "classification": "CLEAR" | "MULTI_INTENT" | "UNDERSPECIFIED" | "CONTRADICTORY" | "AMBIGUOUS_REFERENCE",
  "confidence": 0.0-1.0,
  "routing_target": "[TARGET_NAME]" | null,
  "detected_intents": ["intent_1", "intent_2"],
  "missing_parameters": ["param_1", "param_2"],
  "contradictions": [{"element_a": "...", "element_b": "...", "description": "..."}],
  "ambiguous_references": [{"reference": "...", "candidates": ["candidate_1", "candidate_2"]}],
  "clarification_question": "A single, concise question asking the user to resolve the ambiguity. Null if classification is CLEAR."
}

## CONSTRAINTS
- Never route to a target not listed in [ROUTING_TARGETS].
- If classification is not CLEAR, routing_target must be null.
- clarification_question must be a single sentence that the user can answer in one turn.
- Do not explain your reasoning in the output. Only return the JSON.
- If confidence is below [CONFIDENCE_THRESHOLD], classify as UNDERSPECIFIED even if you suspect an intent.
- For MULTI_INTENT, the clarification question must force a choice between the detected intents, not ask an open-ended question.

To adapt this template, replace the square-bracket placeholders with your application's specific values. [ROUTING_TARGETS] should be a list of handler names with brief descriptions so the model knows what each target does. [CONFIDENCE_THRESHOLD] should be a float between 0.0 and 1.0 that reflects your tolerance for routing errors—start at 0.85 and adjust based on production data. [CONVERSATION_HISTORY] should include the last 3-5 turns formatted as user: and assistant: pairs. If your system has no conversation history, pass an empty string. The output schema is intentionally strict: downstream code should validate that routing_target is non-null only when classification is CLEAR, and that clarification_question is non-null for all other classifications. Add a post-processing validator that rejects any response where these invariants are violated and retries the prompt once before escalating to a human review queue.

Integrating this prompt into a production chat router requires treating it as a deterministic gate, not a conversational suggestion. The prompt should be called synchronously after user input is received but before any downstream handler is invoked. The model's response must be parsed into a strict schema—typically a JSON object with fields for is_ambiguous, detected_intents, ambiguity_reason, and clarification_question. If the parser cannot extract these fields or the model returns an unexpected structure, the system should default to a safe fallback: either route to a generalist handler with a note that intent was unclear, or escalate to a human queue with the raw user input and the unparseable model output attached as diagnostic context.

The implementation should include a lightweight validation layer that checks the output before acting on it. If is_ambiguous is true, the clarification_question field must be non-empty and the ambiguity_reason must reference specific missing or conflicting information from the user's message. If is_ambiguous is false, the detected_intents array must contain at least one valid intent label from your system's known routing taxonomy. A validator that enforces these constraints prevents silent failures where the model marks something as ambiguous but provides no question, or claims clarity while producing an intent label that doesn't match any registered handler. When validation fails, increment a retry counter and re-invoke the prompt with the validation error appended as a corrective instruction. After two failed retries, log the full trace and escalate to a human reviewer rather than guessing.

Model choice matters here more than in many classification tasks. Use a model with strong instruction-following and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate defaults. Avoid smaller or older models that may conflate ambiguity detection with refusal or produce inconsistent JSON under the schema constraints. Set temperature to 0 or a very low value (0.1 maximum) to minimize variance in the ambiguity decision. For high-throughput systems, consider caching the prompt prefix that contains the system instruction and routing taxonomy, as this portion is static across requests and can significantly reduce latency and cost when your provider supports prompt caching. Log every ambiguity decision with the user input, the model's output, the validator result, and the final routing action. This audit trail is essential for tuning the ambiguity threshold over time and for reviewing cases where the system interrupted a user who was actually clear, or failed to interrupt a user who was genuinely ambiguous.