Intent Detection Prompt Template for Unstructured Chat

This prompt is for platform engineers building conversational routers that must classify free-form user messages into a structured intent label, confidence score, and routing target. Use it when downstream workflows, tool dispatchers, or model selection logic depend on accurate intent detection. The prompt assumes you have a defined intent taxonomy and a routing table mapping intents to targets. It is designed for single-turn classification but can be extended with conversation history for multi-turn routing.

Do not use this prompt for multi-intent disambiguation, priority scoring, or out-of-scope detection as standalone tasks; those require separate specialized prompts. If your system must handle overlapping intents, assign urgency levels, or reject unsupported requests, compose this prompt with the dedicated disambiguation, priority scoring, or boundary enforcement prompts in your pipeline. The prompt also assumes the input is unstructured text; for multi-modal inputs, use a modality detection step before routing to this classifier.

Before deploying, ensure your intent taxonomy is stable and your routing table is complete. A missing routing target for a valid intent will cause silent failures downstream. Wire the prompt into a harness that validates the output schema, enforces confidence thresholds, and logs misclassifications for review. Start with a human-in-the-loop fallback for low-confidence predictions, then automate as your calibration improves.

This template is the core instruction set for an intent detection classifier. It is designed to be injected into a system prompt or a dedicated classification call before any downstream routing, tool selection, or agent dispatch occurs. The prompt forces the model to produce a structured JSON output containing an intent label, a confidence score, and a routing target, rather than a conversational reply. Use this template as the single source of truth for your intent classification step, and version it alongside your application code.

textCopy
You are an intent classification system. Your only job is to analyze the user's message and output a structured JSON object. Do not engage in conversation, answer the user's question, or perform any task.

## INPUT
[USER_MESSAGE]

## TAXONOMY
You must classify the input into exactly one of the following intents. If the input does not fit any intent, use "OUT_OF_SCOPE".

[INTENT_TAXONOMY]

## CONTEXT
Use the following conversation history and user profile only to disambiguate the current message. Do not let it override the explicit text of the current input.

[CONVERSATION_HISTORY]
[USER_PROFILE]

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
You must respond with a single JSON object matching this exact schema. Include no other text, markdown, or explanation.

{
  "intent": "string (the classified intent label from the taxonomy)",
  "confidence": "number between 0.0 and 1.0",
  "reasoning": "string (a brief, evidence-based explanation of why this intent was chosen)",
  "routing_target": "string (the downstream queue, agent, or tool identifier)",
  "needs_clarification": "boolean (true if the input is ambiguous and requires a follow-up question)",
  "clarification_question": "string or null (a concise question to ask the user if needs_clarification is true)"
}

## EXAMPLES
[FEW_SHOT_EXAMPLES]

To adapt this template, replace each square-bracket placeholder with the values specific to your application. [INTENT_TAXONOMY] should be a bulleted or numbered list of your supported intents with brief descriptions. [CONSTRAINTS] is where you inject domain-specific rules, such as "If the user mentions a billing issue, confidence must be at least 0.9 to route automatically." [FEW_SHOT_EXAMPLES] should include at least three diverse examples covering clear intent matches, ambiguous cases, and out-of-scope inputs. The [ROUTING_TARGET] field in the output schema should map directly to a queue name, function name, or agent ID that your application layer can act on without further parsing. After copying this template, run it against your golden evaluation dataset and adjust the taxonomy, constraints, and examples until the misclassification rate and out-of-scope detection meet your production thresholds.

Wiring this prompt into an application requires treating it as a deterministic function with a strict input contract and a validated output schema. The application layer must inject the user's raw message into the [USER_MESSAGE] placeholder and the current taxonomy into [INTENT_TAXONOMY] before sending the request. Do not rely on the model to remember the taxonomy from a prior turn; always provide it fresh in each call to prevent drift. The model should be configured with a low temperature (0.0–0.1) to maximize deterministic behavior, and the response format must be set to JSON mode if the provider supports it, or enforced via a strict parsing layer immediately after the call.

The output parser is the most critical component of the harness. Before the classification result touches any routing logic, validate that the JSON payload contains all required fields: intent_label, confidence_score, and routing_target. The intent_label must be an exact string match against the provided taxonomy; any label not in the set should trigger a retry or fallback. The confidence_score must be a float between 0.0 and 1.0. Implement a configurable CONFIDENCE_THRESHOLD (start at 0.75 and tune against production data) below which the system routes to a human review queue or a clarification prompt instead of an automated workflow. Log every classification with the raw input, the model's full response, the parsed fields, and the final routing decision for offline evaluation and drift monitoring.

For model choice, start with a fast, cost-effective model like GPT-4o-mini, Claude 3.5 Haiku, or Gemini 1.5 Flash. Reserve larger models for cases where the primary classifier returns a confidence score in a 'gray zone' (e.g., 0.65–0.85) or when the input is flagged as ambiguous. Implement a single retry with a rephrased prompt if the output fails schema validation; if the retry also fails, log the failure and route to human review. Never silently accept a malformed classification. Wire the routing_target field directly into your workflow dispatcher, but add a safeguard that rejects any target not present in your service registry to prevent hallucinated routing destinations from causing downstream failures.