Out-of-Scope Request Handoff Prompt for AI Assistants

This prompt is designed for product engineers who need to define and enforce the functional boundaries of an AI assistant. Its job is to act as a deterministic gate: when a user request falls outside the system's supported capabilities, the prompt produces a structured handoff payload instead of a hallucinated answer or a generic error. The ideal user is an engineering lead integrating this prompt into a routing middleware layer, where a misclassified out-of-scope request can cascade into broken tool calls, wasted compute, or a degraded user experience. The prompt requires a pre-defined capability manifest—a list of what the system can do—and a set of alternative suggestions or escalation paths to offer the user.

Deploy this prompt when you need a graceful, auditable rejection path that explains why a request cannot be handled and, where possible, points the user toward a supported alternative. It is particularly valuable in customer-facing copilots, internal support bots, and API-bound agent systems where the model might otherwise confabulate capabilities. The prompt is not a replacement for input validation or security scanning; it should sit behind those layers, receiving only requests that have already passed abuse, PII, and injection checks. It also should not be used as a standalone safety filter for high-risk domains like healthcare or finance—those require separate, domain-specific policy evaluation prompts with human review gates.

Before wiring this into production, ensure you have a clear, machine-readable capability manifest and a defined handoff destination—whether that's a human queue, a search fallback, or a documentation link. The prompt's value degrades rapidly if the capability list is vague or if the alternative suggestions are unhelpful. Test it against a golden set of in-scope, out-of-scope, and ambiguously phrased requests to calibrate the boundary. If you find the prompt rejecting well-formed in-scope requests due to minor phrasing variations, the capability descriptions likely need more concrete examples rather than a prompt rewrite.

This prompt template is designed to sit behind your AI assistant's primary capabilities and act as a boundary enforcement layer. When a user request falls outside the system's supported domain, this prompt produces a structured handoff payload instead of a hallucinated answer or a generic refusal. The template uses square-bracket placeholders that you must populate with your specific capability definitions, output schema requirements, and escalation rules before deployment. Copy this template into your prompt management system and adapt the placeholders to match your product's exact scope boundaries.

textCopy
You are a boundary enforcement classifier for an AI assistant. Your job is to determine whether a user request falls within the system's supported capabilities or is out-of-scope.

## Supported Capabilities
[CAPABILITY_DEFINITIONS]

## Input
User Request: [USER_REQUEST]
Conversation Context: [CONVERSATION_HISTORY]

## Classification Rules
1. If the request can be fulfilled using only the capabilities listed above, classify as IN_SCOPE.
2. If the request requires capabilities not listed above, classify as OUT_OF_SCOPE.
3. If the request is poorly phrased but could be fulfilled with clarification, classify as NEEDS_CLARIFICATION and specify what needs clarification.
4. Do NOT classify a request as IN_SCOPE just because you can generate text about the topic. The system must be able to perform the requested action or provide verified information from its tools and knowledge sources.

## Output Schema
Return a JSON object with this exact structure:
{
  "classification": "IN_SCOPE" | "OUT_OF_SCOPE" | "NEEDS_CLARIFICATION",
  "confidence": 0.0-1.0,
  "capability_gap": "string explaining which required capability is missing (only for OUT_OF_SCOPE)",
  "alternative_suggestion": "string with alternative action the user could take or a supported capability that partially addresses the request (only for OUT_OF_SCOPE)",
  "clarification_question": "string with specific question to resolve ambiguity (only for NEEDS_CLARIFICATION)",
  "handoff_message": "string with user-facing message explaining the limitation and next steps",
  "reasoning": "brief explanation of classification decision"
}

## Constraints
- Do not fabricate capabilities the system does not have.
- If uncertain between IN_SCOPE and NEEDS_CLARIFICATION, prefer NEEDS_CLARIFICATION.
- The handoff_message must be polite, specific about the limitation, and actionable.
- For OUT_OF_SCOPE classifications with confidence below [CONFIDENCE_THRESHOLD], flag for human review.

## Examples
[FEW_SHOT_EXAMPLES]

## Risk Level
[RISK_LEVEL: LOW | MEDIUM | HIGH]
- LOW: Standard handoff, no human review required.
- MEDIUM: Log classification for audit, human review optional.
- HIGH: Require human review before sending handoff_message to user.

To adapt this template for your system, start by defining [CAPABILITY_DEFINITIONS] with precise, enumerated descriptions of what your assistant can actually do—not what it can talk about. Include both action verbs (e.g., 'schedule meetings,' 'query order status') and explicit boundaries (e.g., 'cannot provide medical advice'). Populate [FEW_SHOT_EXAMPLES] with at least three examples covering each classification category, including edge cases where a request sounds in-scope but requires an unavailable capability. Set [CONFIDENCE_THRESHOLD] based on your tolerance for false negatives—lower thresholds catch more edge cases but increase human review load. Wire [CONVERSATION_HISTORY] to include the last N turns so the classifier can detect context-dependent scope violations, such as a user gradually steering a conversation toward unsupported territory.

Before deploying this prompt, validate it against a test suite that includes: (1) clearly in-scope requests that must not be flagged, (2) clearly out-of-scope requests that must be caught, (3) poorly phrased in-scope requests that should trigger NEEDS_CLARIFICATION rather than OUT_OF_SCOPE, and (4) adversarial examples where users attempt to reframe out-of-scope requests as in-scope ones. Monitor the ratio of NEEDS_CLARIFICATION to OUT_OF_SCOPE classifications in production—if clarification requests dominate, your capability definitions may be too narrow or your examples insufficient. If OUT_OF_SCOPE classifications are rare but user satisfaction is low, you may have a silent hallucination problem where the model is attempting out-of-scope tasks without triggering this boundary check.

The Out-of-Scope Request Handoff Prompt is designed to sit behind your assistant's primary routing or intent-classification layer. When the system determines that a user request falls outside supported capabilities, this prompt generates a structured handoff payload containing the capability gap, a graceful user-facing message, and alternative suggestions when available. The prompt is not a standalone classifier—it assumes an upstream classification step has already flagged the request as out-of-scope. Your implementation should pass the original user input, the system's capability manifest, and any relevant conversation context into the prompt's placeholders.

Wire this prompt into your application as a post-classification handler. After your intent classifier returns an out_of_scope label (or a confidence score below your routing threshold), invoke the prompt with the [USER_REQUEST], [CAPABILITY_MANIFEST] (a structured list of what your system can do), and [CONVERSATION_CONTEXT] (prior turns if available). Parse the output against a strict JSON schema that includes gap_category, user_facing_message, alternative_suggestions, and escalation_required fields. Validate the output before surfacing it to the user: if escalation_required is true, route to a human review queue with the full payload. If the output fails schema validation, retry once with the validation error appended to the prompt as [PREVIOUS_ERROR]. After two failures, fall back to a static handoff message and log the incident for prompt debugging.

For high-stakes deployments—such as healthcare, legal, or financial assistants—add a human review gate for all out-of-scope handoffs before the user sees the message. This prevents the model from accidentally promising capabilities you don't have or suggesting unsafe alternatives. Log every handoff event with the original request, the generated payload, the reviewer's action, and whether the user accepted the alternative or escalated further. Use these logs to tune your capability manifest, identify frequently requested but unsupported features, and measure the false-positive rate of your upstream classifier. Avoid wiring this prompt directly to user-facing output without validation—an unvalidated handoff message that misrepresents your system's boundaries erodes trust faster than a generic fallback.