Partial Utterance Intent Classification Prompt

This prompt is designed for streaming input systems that must act on incomplete user messages before the user finishes typing or speaking. The core job-to-be-done is to classify the likely intent from a partial utterance, assign a calibrated confidence score, and produce a decision: wait for more input, predict and act now, or request clarification. The ideal user is an AI engineer or product developer building a real-time chat or voice interface where a latency budget requires early intent detection. You need explicit confidence thresholds to control premature action, and you need the model to reason about what it doesn't yet know rather than guessing. This prompt is not a general-purpose intent classifier; it is specifically tuned for the uncertainty and time-pressure of incomplete input streams.

Use this prompt when your system has a strict latency budget that makes it impossible to wait for a complete user utterance. Common scenarios include voice assistants that must begin processing before an endpointing decision, real-time copilots that offer suggestions as the user types, and multi-modal systems where a partial command can trigger a long-running tool execution. The prompt expects a streaming input buffer, recent conversation context, and a set of candidate intents with associated action costs. It outputs a structured decision object that your application harness can use to gate downstream actions. Do not use this prompt for complete-utterance classification where the full message is available; standard intent classification prompts handle that case with higher accuracy and lower complexity. Do not use it for offline batch processing or non-streaming chat logs.

Before implementing this prompt, ensure you have a well-defined set of intents, a calibration dataset for tuning confidence thresholds, and an evaluation pipeline that compares partial-utterance decisions against ground-truth full-utterance intents. The prompt's value comes from its ability to make explicit trade-offs between latency and accuracy. If your system cannot measure the cost of a wrong early decision—such as a tool call that must be rolled back or a user-facing response that must be corrected—then the added complexity of partial-utterance classification is not justified. Start with a complete-utterance baseline, measure the latency gap, and only introduce this prompt when the gap is a proven user-experience problem.

This prompt template is designed for a streaming input system that must act on incomplete user messages. It receives a partial utterance, the current dialogue state, and a set of known intents, then produces a structured classification decision. The prompt forces the model to reason about semantic completeness, information gain from waiting, and the cost of acting prematurely before committing to an intent label.

textCopy
SYSTEM:
You are an intent classifier for a streaming dialogue system. You receive partial user utterances and must decide whether to wait for more input, predict the most likely intent, or request clarification. Your output must be valid JSON matching the schema below.

INPUT:
- Partial utterance: [PARTIAL_UTTERANCE]
- Dialogue state: [DIALOGUE_STATE]
- Known intents: [INTENT_LIST]
- Latency budget (ms): [LATENCY_BUDGET]
- Wait threshold: [WAIT_THRESHOLD]
- Predict threshold: [PREDICT_THRESHOLD]

OUTPUT_SCHEMA:
{
  "decision": "wait" | "predict" | "clarify",
  "predicted_intent": string | null,
  "confidence": 0.0-1.0,
  "reasoning": string,
  "missing_slots": [string],
  "estimated_information_gain": 0.0-1.0
}

CONSTRAINTS:
- If confidence is below [WAIT_THRESHOLD], decision must be "wait" unless latency budget is exhausted.
- If confidence is above [PREDICT_THRESHOLD] and all required slots for the intent are filled, decision may be "predict".
- If the partial utterance is semantically ambiguous and context cannot resolve it, decision must be "clarify".
- Never invent slot values. Mark missing slots explicitly.
- Reasoning must reference specific evidence from the dialogue state and partial utterance.

EXAMPLES:
[EXAMPLES]

USER:
Classify the partial utterance.

Adapt this template by replacing the square-bracket placeholders with your application values. [PARTIAL_UTTERANCE] should contain the streaming text received so far. [DIALOGUE_STATE] should be a structured object with active slots, prior intents, and session context. [INTENT_LIST] must enumerate every intent your system can handle. [LATENCY_BUDGET] is the maximum milliseconds your system can wait before acting. [WAIT_THRESHOLD] and [PREDICT_THRESHOLD] are confidence boundaries you must calibrate against your own evaluation dataset. [EXAMPLES] should include 3-5 few-shot demonstrations covering wait, predict, and clarify decisions with partial utterances that mirror your production traffic. Before deploying, validate that the model reliably outputs parseable JSON matching OUTPUT_SCHEMA and that confidence scores correlate with actual correctness on a held-out test set.

The Partial Utterance Intent Classification Prompt is designed to operate inside a streaming input pipeline where user messages arrive incrementally. The implementation harness must manage three concerns: input buffering and flush triggers, model invocation with latency budgets, and output validation before downstream routing. A typical harness receives text chunks from a WebSocket or server-sent event stream, appends them to a session buffer, and invokes the classifier on a cadence—either on every chunk, on a debounced interval, or when the buffer's semantic completeness score crosses a threshold. The harness should treat the classifier as a stateless function: session context, prior turns, and slot state are passed in via [CONTEXT] and [CURRENT_SLOTS] placeholders, never stored inside the prompt template itself.

Validation is critical because a misclassified partial intent can trigger premature tool calls, incorrect routing, or disruptive clarification requests. The harness must validate the model's output against the [OUTPUT_SCHEMA] before acting on it. At minimum, check that intent_class is a non-empty string matching an allowed enum, confidence is a float between 0.0 and 1.0, and action_decision is one of WAIT, PREDICT, or CLARIFY. If validation fails, the harness should retry once with the same input plus an error description appended to [CONSTRAINTS], then fall back to WAIT if the retry also fails. For latency-sensitive voice pipelines, set a client-side timeout (e.g., 200ms for edge models, 500ms for cloud inference) and treat timeout as equivalent to a WAIT decision with a logged timeout_fallback flag. Log every classification attempt with session_id, buffer_length_chars, model_latency_ms, validation_pass, action_decision, and confidence for observability.

Model choice directly impacts the harness design. Smaller, faster models (e.g., 8B-parameter open-weight models or distilled classifiers) can run on every chunk with minimal latency but may produce noisier confidence scores. Larger models can be invoked less frequently—only when the buffer's semantic completeness heuristic (e.g., trailing punctuation, pause duration, or a lightweight BERT-based endpointing model) suggests the utterance may be complete. The harness should support a two-tier architecture: a fast, always-on classifier for WAIT vs. ACT gating, and a slower, higher-quality classifier for the actual intent label when ACT is triggered. Both tiers share the same output schema. Avoid wiring the classifier output directly to destructive actions (tool calls, database writes, user-visible messages) without a confirmation gate when confidence falls below the calibrated threshold defined in [THRESHOLDS].

Retry logic must distinguish between transient failures (timeouts, malformed JSON) and persistent failures (schema violations after retry, model refusals). For transient failures, implement exponential backoff with a maximum of two retries within the latency budget. For persistent failures, log the full prompt and raw response for debugging, emit a classifier_error metric, and fall back to a safe default: WAIT if the buffer is still receiving input, or CLARIFY if the buffer has been stable for longer than the maximum wait window. Never silently swallow classifier errors—every fallback decision should be observable in logs and trace spans. If the system operates in a regulated domain, ensure that every PREDICT action with confidence below the high-confidence threshold is queued for human review before execution, with the partial utterance, classification output, and session context attached to the review ticket.