Ambiguous Intent Model Escalation Prompt

This prompt is for platform engineers and AI infrastructure teams building model routers that must handle ambiguous, multi-intent, or unclear user requests before committing to a downstream model or workflow. Premature routing on ambiguous inputs causes wasted compute, incorrect tool selection, and broken user experiences. The core job-to-be-done is to insert a deterministic, auditable gate between user input and the router that either produces a structured clarification request to resolve the ambiguity or a confidence-scored best-guess routing decision with explicit ambiguity flags that downstream systems can act on.

Use this prompt when your system sits between user input and a model router, and you need to prevent silent misclassification. It is ideal for high-stakes routing scenarios where the cost of a wrong route is high—such as dispatching to a paid API, invoking a tool with side effects, or routing to a compliance-gated model. The prompt requires the raw user input, a list of available downstream intents or workflows, and a set of routing constraints. It is designed to be called before any expensive model inference, acting as a lightweight classifier that can run on a fast, cost-effective model to save compute downstream.

Do not use this prompt for simple binary classification tasks where ambiguity is unlikely, or for latency-critical paths where the overhead of ambiguity detection exceeds the cost of a wrong route. If your system has a single, well-defined downstream task with a narrow input domain, a direct classification prompt is more efficient. Similarly, if your router already has robust confidence scoring and a cheap fallback path, adding this gate may introduce unnecessary latency. The next step is to integrate this prompt into your routing middleware and pair it with the evaluation harness described in the 'How to Test This Prompt' section to calibrate the ambiguity threshold for your specific use case.

This prompt template is designed to be pasted directly into your system prompt or a dedicated classification step. Its job is to handle inputs that are too ambiguous for a standard intent classifier. Instead of forcing a low-confidence routing decision, it either requests clarification from the user or returns a best-guess routing with explicit ambiguity flags. This prevents silent misrouting, which is a primary cause of broken downstream workflows and poor user experience in production AI systems.

textCopy
You are an intent classification and escalation specialist. Your task is to analyze user inputs that are ambiguous, contain multiple potential intents, or lack sufficient context for a single high-confidence routing decision.

## INPUT
[USER_INPUT]

## AVAILABLE ROUTING TARGETS
[ROUTING_TARGETS]

## INSTRUCTIONS
1. Analyze the input for all possible intents.
2. If the primary intent is clear (confidence >= [CONFIDENCE_THRESHOLD]), produce a routing decision.
3. If multiple intents are equally likely or the input is too vague, produce a clarification request.
4. Never invent a routing target that is not in the provided list.

## OUTPUT SCHEMA
Respond with a single JSON object matching this schema:
{
  "decision": "route" | "clarify",
  "confidence": 0.0-1.0,
  "primary_intent": "string | null",
  "routing_target": "string | null",
  "all_detected_intents": ["string"],
  "ambiguity_flags": ["string"],
  "clarification_question": "string | null",
  "reasoning": "string"
}

## CONSTRAINTS
- If decision is "route", routing_target must be a valid entry from AVAILABLE ROUTING TARGETS.
- If decision is "clarify", routing_target must be null and clarification_question must be a polite, specific question.
- ambiguity_flags must list the reasons for uncertainty (e.g., "multiple_intents", "missing_context", "vague_language").
- Do not hallucinate capabilities or routing targets.

To adapt this template, replace [USER_INPUT] with the raw text from your application. Populate [ROUTING_TARGETS] with a structured list of your actual downstream workflows, tools, or queues (e.g., ["billing_support", "technical_troubleshooting", "account_management"]). Set [CONFIDENCE_THRESHOLD] based on your tolerance for misrouting; a value of 0.8 is a common starting point. Before deploying, validate the output JSON against the schema in your application layer. For high-stakes routing, log every clarify decision and periodically review them to tune your threshold and routing target descriptions.

This prompt is not a standalone chatbot. It is a decision node in a routing pipeline. The implementation harness must treat the model's output as a structured signal that controls downstream dispatch, not as a conversational reply. The primary integration point is a classification microservice or middleware layer that receives user input, calls the model with this prompt, parses the JSON response, and then either routes to a clarification workflow or dispatches to the selected model with the resolved intent. The harness is responsible for enforcing the contract: the prompt produces a decision, and the harness acts on it or escalates.

Begin by wrapping the model call in a function that accepts [USER_INPUT], [AVAILABLE_MODELS], [ROUTING_CONTEXT], and [CONFIDENCE_THRESHOLD]. The function should construct the prompt, call the model with response_format set to json_object (or equivalent structured output mode for the target model), and parse the result. Validate the output against a strict schema: decision (enum: clarify, route), resolved_intent (string or null), selected_model (string or null), confidence (float 0-1), ambiguity_flags (array of strings), and clarification_question (string or null). If decision is route but confidence is below the threshold, override to clarify. If decision is clarify but confidence is above the threshold, log the inconsistency and treat it as clarify—the model explicitly signaled ambiguity. Any parse failure, schema violation, or missing required field should trigger a retry with the same prompt plus the validation error message appended as a [PREVIOUS_ERROR] context. Limit retries to two attempts before falling back to a safe default: route to a general-purpose model with a low_confidence flag or escalate to a human review queue.

Logging is critical for this prompt because ambiguous intent is a leading indicator of taxonomy gaps and model weakness. Log every decision with: the raw user input, the parsed decision, confidence score, ambiguity flags, selected model, and whether the harness overrode the model's decision. Also log the latency of the classification call and any retry attempts. These logs feed two operational workflows: a dashboard for monitoring ambiguity rates by intent category, and a dataset for improving the routing taxonomy and few-shot examples over time. For high-stakes domains—healthcare, finance, legal, safety—add a human review path when ambiguity_flags contains terms like regulatory_risk, safety_concern, or legal_implication. The harness should place these inputs into a review queue with the full prompt response and raw input, not attempt automated routing. The next step after implementing this harness is to run the eval suite from the playbook's testing section against a golden dataset of known ambiguous and unambiguous inputs to calibrate the confidence threshold and measure routing accuracy before production traffic hits the system.