Multi-Domain Intent Boundary Detection Prompt

This prompt is designed for multi-domain AI assistants that must handle compound user requests spanning unrelated capabilities within a single turn. The core job is intent boundary detection: taking a user message like 'Cancel my subscription and what's the weather in Lisbon?' and cleanly separating it into two distinct, non-overlapping intent segments—[billing:cancel_subscription] and [weather:forecast]. The ideal user is an AI engineer or product developer building a routing layer for a platform assistant that orchestrates multiple back-end skills, APIs, or sub-agents. You need this when a naive single-intent classifier would force an arbitrary choice, drop half the request, or produce a confused hybrid response.

You should not use this prompt when the user's request is a coherent multi-step task within a single domain. For example, 'Find flights to Lisbon and book the cheapest one' is a sequential workflow inside the travel domain, not a boundary detection problem. Applying this prompt to such inputs will likely cause over-segmentation, breaking an atomic workflow into fragments that lose dependency context. Similarly, avoid this prompt for simple single-intent turns where a standard classifier is cheaper and faster. The prompt is also unsuitable for detecting gradual topic shifts across multiple conversation turns; it is strictly for segmenting a single compound user message.

Before implementing, ensure you have a defined domain taxonomy—a controlled list of the domains your assistant supports. Without this, the model will invent ad-hoc boundaries that don't map to your routing infrastructure. The output schema must be validated programmatically: check that every segment maps to a known domain, that segments don't overlap, and that the original user text is fully covered by the concatenated segments. For high-stakes routing (e.g., financial transactions or healthcare actions), always include a confidence threshold check and route low-confidence segments to a human review queue or a clarification prompt. The next step after reading this introduction is to copy the prompt template, populate your domain taxonomy, and run the provided eval suite against your own compound-request test cases.

This prompt template is designed to be integrated directly into a multi-domain assistant's routing layer. Its job is to take a single user message that may contain requests spanning completely unrelated capabilities—such as a calendar query and a code debugging request in the same breath—and decompose it into cleanly separated segments. The output is a structured list of intent boundaries, each with its own domain label and the exact text span it covers. This prevents a single-domain handler from receiving a polluted, multi-domain input that it cannot process correctly.

textCopy
You are an intent boundary detection system for a multi-domain assistant. Your task is to analyze a single user message and identify distinct, unrelated requests that should be routed to different domain handlers.

## INPUT
[USER_MESSAGE]

## DOMAIN TAXONOMY
[DOMAIN_LIST]

## INSTRUCTIONS
1. Analyze the user message for requests that belong to different domains as defined in the DOMAIN TAXONOMY.
2. A compound request within the *same* domain (e.g., 'add milk and eggs to my shopping list') should be treated as a SINGLE segment. Do not over-segment.
3. A request that shifts to a completely unrelated domain (e.g., 'add milk to my shopping list and what's the weather in London') must be split into separate segments.
4. If the entire message belongs to a single domain, return a list with one segment covering the full text.
5. If a portion of the message does not fit any domain, label it as 'unclassified'.

## OUTPUT SCHEMA
Return a valid JSON object with a single key "segments" containing an array of objects. Each object must have the following fields:
- "domain": (string) The assigned domain from the taxonomy.
- "text": (string) The exact substring of the user message for this segment.
- "confidence": (float) A score between 0.0 and 1.0.

## CONSTRAINTS
- The concatenation of all segment "text" fields must exactly equal the original [USER_MESSAGE].
- Do not modify the user's text.
- If confidence is below 0.7, set the domain to "unclassified".

To adapt this template, you must replace the [DOMAIN_LIST] placeholder with a concrete, well-defined taxonomy relevant to your application. This should be a simple list of domain names and brief descriptions, such as "calendar: scheduling and event management" or "code_interpreter: executing and debugging code." The quality of the segmentation is directly tied to the clarity of this taxonomy. After integrating this prompt, you must implement a post-processing validation step in your application harness that verifies the output schema and checks the concatenation constraint. For high-risk routing decisions where a misrouted segment could trigger a destructive action, flag segments with confidence below 0.85 for human review or a confirmation prompt before execution.

This prompt is designed to be a pre-processing step in a multi-domain assistant pipeline. Before any domain-specific logic, tool selection, or response generation occurs, the raw user input is passed through this prompt to detect intent boundaries. The output is a structured segmentation of the user's turn into one or more distinct intent segments, each with a domain label, a confidence score, and a flag indicating whether the segment is dependent on a prior segment. This segmentation then drives downstream routing: a single user message like "Cancel my subscription and what's the weather in London?" is split into a billing intent and a weather intent, allowing the orchestrator to dispatch each to the correct handler, potentially in parallel.

The implementation harness should treat this prompt as a synchronous, deterministic gate. The recommended flow is: (1) Receive user input. (2) Assemble the prompt with the [INPUT] and [DOMAIN_TAXONOMY] variables. The taxonomy should be a strict, enumerated list of your system's supported domains (e.g., billing, technical_support, weather, general_qa). (3) Call a fast, cost-effective model (e.g., a small fine-tuned model or a fast API endpoint) with temperature=0 and a JSON mode or structured output constraint enforcing the [OUTPUT_SCHEMA]. (4) Parse the JSON response and validate it against the schema. A critical validation check is for over-segmentation: if a single domain task is split into multiple segments (e.g., "What's the weather in London and will it rain tomorrow?" split into two weather intents), a post-processing rule should merge adjacent segments with the same domain label. (5) If validation fails or the model returns unparseable JSON, implement a retry with a stricter prompt that includes the validation error message. After two failed retries, fall back to a default single-segment classification of [FALLBACK_DOMAIN] and log the raw input and errors for offline analysis.

For high-stakes routing where a misclassification could lead to a poor user experience or a security concern (e.g., routing a "delete all data" request to a general Q&A bot), the harness must include a confidence threshold check. Any segment with a confidence score below a configurable threshold (start with 0.85) should not be auto-routed. Instead, it should be flagged for human review or escalated to a clarification prompt that asks the user to disambiguate. Log every routing decision, including the raw prompt, the model's full output, the final validated segments, and the routing destination, to a structured logging system. This trace data is essential for debugging misroutes and for curating a golden evaluation dataset. The next step is to build an eval harness that runs this prompt against a set of annotated user turns containing both single-domain, multi-domain, and edge-case requests to measure precision, recall, and over-segmentation rate before deployment.