Multi-Product Intent Disambiguation Prompt

This prompt is designed for AI platform and product engineering teams building routing middleware for multi-product platforms. The core job-to-be-done is to analyze a single user request that could plausibly map to multiple products within your ecosystem and determine the primary product intent, any secondary product references, and a confidence score for the disambiguation decision. The ideal user is an engineer or technical product manager who owns a classification service that sits between the user input layer and downstream product-specific workflows, tools, and context retrieval systems. You need this prompt when your platform exposes multiple distinct products, features, or service lines under one interface, and a single ambiguous query like 'I can't export my report' could refer to the Analytics product, the Compliance product, or the Document Builder product depending on context.

You should not use this prompt when your platform has a single product or when product boundaries are already resolved by explicit user selection, URL path, or API key scoping before the input reaches your AI layer. This prompt is also inappropriate for general topic classification where the taxonomy is flat and non-overlapping—use a standard domain categorization prompt instead. The prompt requires a well-defined product taxonomy as input, including product names, descriptions, and boundary definitions. Without this taxonomy, the model cannot reliably disambiguate. You must also provide the user's raw input and any available session context such as recent pages visited, active subscriptions, or previous intents. The output is a structured disambiguation result containing a primary product label, a list of secondary products with relevance scores, a confidence score, and a brief reasoning trace. This output feeds directly into downstream routing logic, so it must be machine-parseable and deterministic enough to act on without human review for high-confidence cases.

Before deploying this prompt, define your product taxonomy carefully. Overlapping product descriptions cause the same ambiguity in the model that you're trying to resolve. Test the prompt against a golden dataset of ambiguous queries where you know the correct primary product, and measure both top-1 accuracy and whether secondary products are correctly identified when present. Pay special attention to queries that mention features shared across products—these are your highest-failure-mode cases. If your platform has compliance or billing implications for misrouted requests, implement a confidence threshold below which the system escalates to a human reviewer or asks the user a clarifying question rather than routing automatically. The next section provides the copy-ready prompt template you can adapt for your product taxonomy.

The prompt below is designed to be dropped into a classification or routing middleware layer. It accepts a user request that may reference multiple products and returns a structured JSON object identifying the primary product intent, any secondary product references, and a confidence score. The template uses square-bracket placeholders so you can swap in your own product taxonomy, examples, and constraints without rewriting the core logic.

textCopy
You are a product intent classifier for a multi-product platform. Your job is to analyze a user request and identify which product or products the user is referring to.

## INPUT
User Request: [USER_REQUEST]

## PRODUCT TAXONOMY
[PRODUCT_TAXONOMY]

## INSTRUCTIONS
1. Identify the PRIMARY product intent: the single product the user most clearly needs.
2. Identify any SECONDARY product references: other products mentioned or implied, even if they are not the main focus.
3. Assign a CONFIDENCE score from 0.0 to 1.0 for the primary classification.
4. If the request is ambiguous between two or more products, flag it as AMBIGUOUS and list the candidate products in order of likelihood.
5. If the request does not match any product in the taxonomy, set primary to "out_of_scope" and confidence to 0.0.

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## OUTPUT SCHEMA
Return ONLY valid JSON with this exact structure:
{
  "primary_product": "string",
  "primary_confidence": 0.0,
  "secondary_products": ["string"],
  "is_ambiguous": false,
  "candidate_products": [{"product": "string", "likelihood": 0.0}],
  "reasoning": "string"
}

To adapt this template, replace [PRODUCT_TAXONOMY] with your actual product list—include product names, short descriptions, and any aliases or common synonyms users might employ. The [CONSTRAINTS] placeholder should contain routing rules such as "if the request mentions billing, always route to the Billing product regardless of other signals" or "do not classify feature requests as support tickets." The [EXAMPLES] block is critical: provide at least five few-shot examples covering single-product requests, multi-product mentions, ambiguous cases, and out-of-scope inputs. After adapting, run the prompt against a golden test set of 50–100 labeled examples and measure primary product accuracy, secondary product recall, and the false-positive rate on the is_ambiguous flag before deploying to production routing.

This prompt is designed to sit at the ingress layer of a multi-product AI platform, immediately after user input is received and before any product-specific tool dispatch, context retrieval, or model selection occurs. The implementation harness must treat this prompt as a synchronous classification step with a strict latency budget—typically under 500ms for real-time chat or API flows. The output is a structured JSON payload containing a primary product intent, a list of secondary product references with confidence scores, and an ambiguity flag. Downstream routing logic consumes this payload to determine which product handler, tool set, and policy context to activate. The harness should never pass raw user input directly to product-specific workflows without first running disambiguation, as cross-product context loss leads to incorrect tool selection and broken user experiences.

Wire the prompt into your application as a pre-processing middleware function. The function should accept the user's raw input string and a product taxonomy array as variables, inject them into the prompt template's [USER_INPUT] and [PRODUCT_TAXONOMY] placeholders, and call your chosen model with response_format set to json_schema or equivalent structured output mode. Validate the returned JSON against a schema that requires: primary_intent (string, must match a taxonomy entry), primary_confidence (float 0-1), secondary_intents (array of objects with product and confidence fields), and requires_clarification (boolean). If primary_confidence falls below a configurable threshold—start with 0.7 and tune based on production data—route to a clarification flow rather than auto-dispatching. Log every classification result with the input hash, model version, confidence scores, and final routing decision for offline eval and drift detection. For high-stakes platforms, add a human review queue for inputs where requires_clarification is true or where primary_confidence is below 0.5.

Model choice matters here. Use a fast, instruction-tuned model for this classification task—smaller variants of GPT-4, Claude, or Gemini are sufficient and keep latency low. Avoid using the same large model that handles complex downstream reasoning, as the disambiguation step should be cheap and fast. Implement a retry strategy with exponential backoff for transient failures, but cap retries at two attempts to avoid tail latency spikes. If both attempts fail, fall back to a default routing rule based on the most common product or escalate to a human operator. Do not cache disambiguation results by input text alone—product taxonomies evolve, and identical queries can have different intents based on user context, session history, or feature flags. Instead, include a taxonomy version identifier in your cache key and invalidate on taxonomy updates. The next step after implementing this harness is to build an eval pipeline that compares disambiguation decisions against a human-labeled golden dataset, measuring precision and recall per product category, and monitoring for drift as new products are added to the taxonomy.