Multi-Turn Intent Change Detection Prompt

This prompt is designed for a specific job: classifying how the current user turn relates to the prior conversation. It outputs a label—new, continuation, refinement, or correction—with evidence spans from the history. Use it inside routing and analytics pipelines where downstream behavior depends on whether the user is staying on task, changing the subject, or correcting a previous instruction. The ideal user is a developer or AI engineer building a multi-turn assistant, copilot, or support bot that needs to make real-time decisions about context management, state resets, or workflow branching based on turn-to-turn intent shifts.

This is not a general intent classifier. It assumes you already have a conversation history and need to detect shifts, not assign topic categories. If you need topic-level intent classification (e.g., 'billing inquiry' vs. 'technical support'), pair this with a separate classification prompt. If you need slot-filling or entity extraction, use a dialogue slot extraction template instead. The prompt is optimized for boundary cases where users subtly shift goals—for example, moving from 'show me my balance' to 'actually, that last transaction looks wrong,' which is a correction, not a new topic. It also handles mid-turn pivots where a single user message contains both a continuation and a refinement.

Before wiring this into production, confirm that your system has access to a structured conversation history with turn-level attribution. The prompt requires at least the current user turn and the prior assistant turn to function; performance improves with more history. Do not use this prompt for single-turn classification or for sessions without a clear turn boundary. If your application operates in a high-stakes domain—such as healthcare triage or financial transaction routing—add a human review step before acting on the classification output, and log the evidence spans for auditability. For a complete implementation, pair this with the session state JSON tracking prompt to update state based on the detected shift type.

This prompt template is designed to be copied directly into your prompt layer and adapted with your conversation data. It compares the current user turn against the prior conversation history and outputs a structured classification label with supporting evidence spans. The prompt is built for routing and analytics systems that need to detect subtle intent shifts, not just obvious topic changes. Replace each square-bracket placeholder with your actual conversation data, schema definitions, and operational constraints before use.

textCopy
You are an intent change detection classifier for a multi-turn conversation system. Your job is to compare the latest user turn against the prior conversation history and classify the relationship between the current turn and the preceding dialogue.

[CONSTRAINTS]

CONVERSATION HISTORY:
[HISTORY]

CURRENT USER TURN:
[CURRENT_TURN]

CLASSIFICATION TASK:
Analyze the current user turn in the context of the conversation history. Determine whether the user's intent is:
- NEW_INTENT: The user has introduced a completely new goal, topic, or request unrelated to the prior conversation.
- CONTINUATION: The user is continuing the same intent, adding more information, or progressing the same task without changing direction.
- REFINEMENT: The user is narrowing, specifying, or adding detail to the same intent without changing the core goal.
- CORRECTION: The user is explicitly correcting, reversing, or contradicting something they or the assistant previously stated.

EVIDENCE REQUIREMENTS:
For each classification, you must provide:
1. The classification label.
2. A confidence score from 0.0 to 1.0.
3. The specific span of text from the current turn that supports your classification.
4. The specific span of text from the history that the current turn relates to, if applicable.
5. A brief rationale explaining the relationship.

[OUTPUT_SCHEMA]

[EXAMPLES]

[RISK_LEVEL]

Adapt this template by replacing [HISTORY] with the prior conversation turns formatted as speaker-labeled utterances. Replace [CURRENT_TURN] with the latest user message. The [CONSTRAINTS] placeholder should contain any domain-specific rules, such as treating certain keywords as strong correction signals or ignoring small talk when classifying intent. The [OUTPUT_SCHEMA] placeholder should define the exact JSON structure your downstream system expects. The [EXAMPLES] placeholder should include 2-4 few-shot examples covering boundary cases like subtle topic shifts, partial corrections, and multi-intent turns. The [RISK_LEVEL] placeholder should specify the operational risk context, which determines whether low-confidence classifications should be routed to human review or logged for evaluation. For high-risk routing decisions, always add a confidence threshold below which the classification is treated as UNCLEAR and escalated rather than silently routed.

This prompt is designed to sit between the user's latest utterance and your application's routing, analytics, or state management logic. It is not a conversational response generator—it is a classification step that must execute before the system decides what to do next. The harness should treat this prompt as a synchronous pre-processing gate: the model receives the current turn plus a compressed representation of prior turns, and it must return a structured classification before the main assistant or agent is invoked. Because the output directly controls routing decisions, the harness must validate the classification label against an allowed enum, check for evidence spans that map to real input tokens, and fall back to a safe default (typically continuation or new) if the model output is malformed or low-confidence.

Wire the prompt into your application with a strict JSON schema validator. The expected output includes a classification field constrained to a closed set: new, continuation, refinement, correction, or unrelated. The harness should reject any output that does not match this enum and either retry with a more explicit constraint or default to continuation to avoid breaking the user's flow. For the evidence_spans field, validate that each span is a substring of the current user turn or a prior turn provided in the context. Spans that do not match input text indicate hallucination and should trigger a retry or a confidence downgrade. Log every classification decision with the turn ID, the raw model output, the validated output, and the fallback decision if one was used. This log becomes essential for debugging routing errors and for tuning the prompt over time. For model choice, a fast, instruction-tuned model (such as GPT-4o-mini, Claude Haiku, or Gemini Flash) is usually sufficient; the task is discriminative, not generative, and latency matters because this gate blocks the main pipeline.

If the classification is correction or refinement, the harness should flag the prior turn's state as potentially stale and trigger a state update or re-verification step before the main assistant responds. If the classification is new, the harness should reset or archive the active dialogue state and begin a fresh tracking session. For unrelated, consider whether the user has drifted into a topic your system cannot handle and route to a fallback or escalation path. Do not use this prompt in isolation for high-stakes decisions—combine it with explicit user confirmation when the detected intent change would discard work in progress or alter a transaction in flight. The next step after implementing this harness is to build a regression test suite with labeled turn pairs covering subtle shifts (e.g., 'Actually, can you also add...' versus 'Actually, I meant...') and measure classification accuracy before deploying to production routing.