Ambiguous Model Selection Clarification Prompt

This prompt is for MLOps engineers and AI engineering agents that receive a model selection request without the necessary decision dimensions—specifically, the task type, latency budget, cost constraints, or accuracy requirements. The job-to-be-done is not to pick a model, but to interrupt an underspecified workflow and produce a structured clarification that surfaces the trade-offs the requester must resolve first. Use this prompt when a model selection request arrives as a vague natural-language instruction like 'pick the best model for this' or 'use a cheaper one,' and the downstream system cannot safely default to a generic model without risking cost overruns, latency violations, or accuracy failures.

Do not use this prompt when the model selection context is already fully specified in the system prompt, when the task has a hardcoded model routing rule, or when the cost and latency envelope is so wide that any reasonable default is safe. This prompt is also inappropriate for real-time, low-latency paths where a blocking clarification round-trip would violate the user's SLA. The ideal user is an AI engineering agent that has access to a model catalog with known cost, latency, and capability profiles, and that operates in a workflow where pausing for clarification is cheaper than executing the wrong model choice. The required context includes the original user request, the available model catalog metadata, and any organizational policies that constrain model selection (e.g., data residency, approved vendor lists).

Before wiring this prompt into production, define the evaluation criteria for a good clarification: it must identify which dimensions are missing (task, latency, cost, accuracy), it must not ask for information already present in the request, and it must present the trade-off in terms the requester can act on without being an ML expert. The next step after reading this section is to review the prompt template and adapt the placeholders to your model catalog and policy constraints.

This prompt is designed for MLOps and AI engineering agents that receive model selection requests without the necessary context to make a sound decision. Instead of guessing a model or defaulting to a popular choice, the prompt instructs the system to identify which critical dimensions are missing—such as task type, latency budget, cost constraints, or accuracy requirements—and to produce a structured clarification request. The goal is to prevent premature, costly, or misaligned model recommendations by making the trade-offs explicit to the user before any selection logic runs.

Below is the copy-ready template. It uses square-bracket placeholders that your application must populate before sending the request to the model. The [USER_REQUEST] placeholder receives the original, underspecified query. [AVAILABLE_MODELS] should be a structured list of model names and their key characteristics (e.g., cost per token, typical latency, known strengths). [CONSTRAINTS] allows you to inject organizational policies, such as 'only use models deployed in our VPC' or 'do not recommend models that cost more than $0.10 per 1k tokens.' The [OUTPUT_SCHEMA] placeholder defines the exact JSON structure the model must return, which your harness can then validate and render to the user.

textCopy
You are an MLOps model selection assistant. Your primary directive is to never recommend a model when the user's request is ambiguous regarding task, latency, cost, or accuracy requirements. Your job is to identify missing decision dimensions and ask a targeted clarification question before proceeding.

USER REQUEST:
[USER_REQUEST]

AVAILABLE MODEL CATALOG (name, cost_per_1k_tokens, typical_latency_ms, strengths, constraints):
[AVAILABLE_MODELS]

ORGANIZATIONAL CONSTRAINTS:
[CONSTRAINTS]

INSTRUCTIONS:
1. Analyze the user request against the following required dimensions: primary task, latency budget, cost budget, minimum accuracy/quality threshold, and any domain-specific requirements.
2. Identify which dimensions are missing, underspecified, or contradictory.
3. If all required dimensions are present and unambiguous, you may proceed to recommend a model. Otherwise, you must halt and request clarification.
4. When requesting clarification, structure your response as a JSON object that conforms exactly to the output schema below. Do not include any text outside the JSON.
5. In the clarification question, explicitly surface the trade-off the user needs to make (e.g., 'Do you prioritize speed or accuracy?'). Provide concrete, contrasting options based on the available model catalog.

OUTPUT SCHEMA:
[OUTPUT_SCHEMA]

To adapt this template, start by defining your [OUTPUT_SCHEMA]. A robust schema includes a status field (e.g., "needs_clarification" or "ready_to_recommend"), a missing_dimensions array, a clarification_question string, and an options array of concrete alternatives. Next, populate [AVAILABLE_MODELS] with a machine-readable list from your model registry. If your registry is large, use a retrieval step (RAG) to insert only the top-N relevant models into the prompt to manage context length. Finally, wire the prompt into a harness that validates the JSON output against your schema before displaying anything to the user. If validation fails, retry once with the error message injected into the prompt. If the model recommends a model without clarification when dimensions are missing, log the event as a policy violation and escalate for human review. This prompt is a gating mechanism, not a recommendation engine; its success is measured by how often it correctly prevents a bad recommendation, not by how quickly it produces one.

This prompt is designed to sit between a user request for a model recommendation and any downstream model registry, inference endpoint, or automated training pipeline. The implementation harness must treat the prompt's output as a gating decision: if the output indicates ambiguity, the system must not proceed to model selection. Instead, it must surface the structured clarification request to the user and block any model invocation, deployment, or cost-incurring action until the user resolves the ambiguity. The harness should wrap the LLM call in a function that returns a typed result—either a ClarificationNeeded object with the trade-off dimensions and question, or a ModelSelected object with the chosen model and rationale. This typed contract prevents downstream code from accidentally treating a clarification as a recommendation.

Wire the prompt into your application with a pre-validation step that checks the incoming request for the required dimensions before calling the LLM. If the user request already contains explicit task type, latency budget, cost constraints, and accuracy requirements, you can skip the clarification prompt entirely and route directly to a model selection prompt. This saves latency and cost. If any dimension is missing, invoke the clarification prompt. After receiving the LLM response, run a post-validation step: parse the output and confirm that either all ambiguity dimensions are addressed with specific user-facing questions, or a concrete model recommendation is provided with justification. If the output is malformed—missing required fields, providing a recommendation while also flagging ambiguity, or failing to identify which dimensions need clarification—retry once with a repair prompt that includes the validation error. If the retry also fails, escalate to a human reviewer with the original request and both failed outputs. Log every clarification event, including which dimensions were ambiguous, the generated question, and the user's eventual response, to build a dataset for improving the prompt and for auditing selection decisions.

For tool-calling agents, expose the clarification prompt as a tool that the agent can invoke when it detects an underspecified model request. The tool's schema should return a structured clarification object, not a raw text block. The agent's planner should be instructed to call this tool before calling any model registry or deployment tool. If the agent attempts to call a model selection tool without first resolving ambiguity, the harness should intercept the call and force the clarification tool to run. This is a hard gate, not a suggestion. For evaluation, maintain a golden set of ambiguous and unambiguous model requests. Measure the prompt's precision (did it flag ambiguity only when needed?) and recall (did it catch all underspecified requests?). Track the rate of unnecessary clarifications—cases where the user had provided sufficient information but the prompt still asked for clarification—as this directly impacts user friction. Set a target for unnecessary clarification rate below 5% and monitor it in production. When the prompt fails, the most common failure mode is asking for clarification on dimensions the user already provided; address this by iterating on the prompt's instruction to check all provided context before flagging a dimension as missing.