Constraint Elicitation Interview Prompt Template

This prompt is a planning pre-processor for agent systems. Its core job is to convert an underspecified user goal into a structured interview that probes for implicit constraints across security, latency, cost, data handling, and operational boundaries. You should use this prompt when a user request arrives that is too vague to generate a safe, executable plan—for example, a request like 'automate our customer onboarding' or 'summarize the latest research' that lacks clear scope, authority, or success criteria. The output is a set of targeted clarification questions and a completeness score, not a final plan. This prompt belongs in the agent frontend, before any task decomposition or tool selection occurs.

The ideal user is a developer or product manager integrating an AI agent into a product where users express goals in natural language. The prompt is designed for semi-autonomous systems where the cost of a wrong action is high. It is not a general-purpose chatbot clarifier. Deploy it when the agent will later act on the clarified goal—calling APIs, modifying data, or making decisions with business impact. The prompt requires the raw user input and, optionally, a catalog of known tool capabilities or domain constraints to ground its questions. Without this context, the interview may ask generic questions that fail to surface the most dangerous implicit assumptions.

Do not use this prompt if the user has already provided explicit, structured constraints. In that case, use the Constraint Completeness Check Prompt Template instead, which validates coverage rather than eliciting new information. Also avoid this prompt for trivial, low-risk tasks where a clarification interview adds more friction than value—setting a timer, drafting a casual email, or answering a factual question with no side effects. The prompt is not a replacement for a product's settings page or a formal onboarding wizard; it is a dynamic safety layer for agentic workflows where the user's initial statement is almost certainly incomplete.

A common failure mode is deploying this prompt without a timeout or question limit, leading to an endless interview loop that frustrates users. Always pair it with a maximum question count and a 'good enough' completeness threshold. Another risk is asking questions the system should already know—like available tools or data permissions—which erodes user trust. Ground the prompt with a [TOOL_CATALOG] and [DOMAIN_CONSTRAINTS] input to keep questions relevant. Finally, if the user's goal involves regulated data or irreversible actions, the output of this prompt must be reviewed by a human before any plan is generated, not treated as a green light for autonomous execution.

This template is designed to be pasted directly into your system instructions for a planning pre-processor or agent frontend. Its job is to take a user's stated goal and conduct a structured interview that surfaces implicit constraints the user has not yet articulated. The prompt uses a completeness scoring system to detect missing constraint categories and generates targeted follow-up questions ranked by impact. Replace every square-bracket placeholder with your specific domain, risk profile, and output requirements before use.

textCopy
You are a constraint elicitation interviewer. Your job is to take a user's stated goal and conduct a structured interview to surface implicit constraints across security, latency, cost, data handling, operational boundaries, and output requirements.

## INPUT
User Goal: [USER_GOAL]
Available Context: [CONTEXT]
Domain: [DOMAIN]
Risk Level: [RISK_LEVEL]

## INTERVIEW RULES
1. Begin by restating the goal to confirm understanding.
2. Assess constraint completeness across these categories on a scale of 1-5:
   - Security and access control
   - Latency and time budgets
   - Cost and resource limits
   - Data sensitivity and handling
   - Operational boundaries (what the system may and may not do)
   - Output format and quality requirements
   - Human approval and escalation triggers
   - Failure tolerance and fallback behavior
3. For each category scored 3 or below, generate ONE targeted question that probes for the missing constraint. Do not ask questions for categories scored 4-5.
4. Rank questions by impact: which missing constraint, if left unspecified, would cause the most severe failure?
5. Ask questions one at a time. After each answer, re-score affected categories and decide whether to ask the next question or conclude.
6. Stop the interview when all categories reach score 4+ OR the user declines to answer further OR you have asked [MAX_QUESTIONS] questions.

## OUTPUT FORMAT
After each user response, output:
{
  "category_scores": {
    "security": <1-5>,
    "latency": <1-5>,
    "cost": <1-5>,
    "data_sensitivity": <1-5>,
    "operational_boundaries": <1-5>,
    "output_requirements": <1-5>,
    "approval_triggers": <1-5>,
    "failure_tolerance": <1-5>
  },
  "next_question": "<targeted question or null if interview complete>",
  "question_category": "<category being probed or null>",
  "interview_complete": <true|false>
}

When the interview is complete, output a final constraint summary:
{
  "interview_complete": true,
  "constraint_summary": {
    "explicit_constraints": ["<constraint the user stated directly>"],
    "elicited_constraints": ["<constraint surfaced during interview>"],
    "remaining_gaps": ["<category still below score 4 with reason>"],
    "risk_notes": "<any risks from unresolved gaps>"
  }
}

## CONSTRAINTS
- Do not ask questions the user has already answered.
- Do not ask hypothetical questions unrelated to the stated goal.
- If the user provides a constraint that resolves multiple categories, update all affected scores.
- If the user refuses to answer a question, score that category as-is and move on.
- Never invent constraints. Only record what the user states or implies.

To adapt this template, replace [USER_GOAL] with the user's stated objective, [CONTEXT] with any available background information, [DOMAIN] with the relevant industry or application domain, [RISK_LEVEL] with low, medium, high, or critical, and [MAX_QUESTIONS] with a reasonable limit such as 5 or 8 to prevent interview fatigue. The category list can be extended or narrowed based on your domain. For regulated industries, add categories such as compliance or audit_trail. For real-time systems, add throughput or availability. The scoring threshold of 4 is tunable: raise it to 5 for high-risk domains where every gap must be closed, or lower it to 3 for low-stakes exploratory tasks where some ambiguity is acceptable.

Before deploying this prompt into production, validate that the JSON output is parseable by your application harness. Add a retry step if the model produces malformed JSON. For high-risk domains, route the final constraint summary to a human reviewer before it feeds into downstream planning. Common failure modes include the model asking redundant questions, failing to update scores after a user answer, or concluding the interview prematurely when critical gaps remain. Test against a golden set of deliberately under-specified goals and measure whether the interview surfaces the known missing constraints.

The Constraint Elicitation Interview prompt is not a one-shot generation call. It is designed as a multi-turn conversational module inside a planning pre-processor. The application should maintain a structured session state that tracks which constraint categories have been probed, which remain unanswered, and the current completeness score. Each model response should be parsed for the next interview question, the updated completeness score, and any newly detected missing constraint categories. The application loop continues until the completeness score meets a configured threshold (typically 0.85 or higher) or a maximum turn limit is reached to prevent infinite probing.

Validation and state management: After each model response, validate that the output contains a parseable JSON structure with at minimum a question field, a completeness_score float, and a missing_categories array. If parsing fails, retry once with a repair prompt that includes the raw output and the expected schema. Maintain a running constraint document that accumulates confirmed constraints from user answers. Before each new turn, inject the current constraint document and the list of already-probed categories into the prompt's [CONTEXT] placeholder to prevent redundant questioning. Log every turn with the question asked, user response, completeness score delta, and any parsing failures for observability.

Human review and escalation: For high-stakes domains such as healthcare, finance, or security operations, route the final accumulated constraint document to a human reviewer before it is passed to downstream planning modules. The review interface should highlight any constraint categories that were never probed because the user declined to answer or the turn limit was reached. Flag constraint documents where the final completeness score is below 0.80 or where conflicting constraints were detected but not resolved. The application should support an override mode where a human operator can add, modify, or reject constraints before the plan generation phase begins. Do not allow autonomous execution on constraint documents that have not met the minimum completeness threshold or that contain unresolved conflicts flagged by the Constraint Conflict Resolution prompt.