Constraint-Elicitation Prompt for Agent Goals

This prompt is designed for the pre-planning clarification phase of an agent workflow. Its job is to take an ambiguous, under-specified user goal and transform it into a well-scoped objective with explicit constraints, boundaries, and success criteria. The ideal user is a developer or product manager building an agent frontend—the interface layer that sits between a human user's natural-language request and the planning module that generates executable steps. Without this clarification step, planning modules receive vague inputs and produce plans that are either too narrow, too broad, or misaligned with what the user actually intended. The prompt is not a planner itself; it is a constraint elicitor that produces a clarified goal document ready for downstream plan generation.

When to use this prompt: You have a user-facing agent that accepts free-text goals (e.g., 'research competitors,' 'optimize my cloud costs,' 'draft a contract'), and you need to extract implicit constraints before planning begins. Use it when the cost of a bad plan is high—either in tokens, tool calls, or real-world side effects. When not to use this prompt: Do not use it for well-structured, form-based inputs where constraints are already explicit (e.g., a configuration wizard). Do not use it for trivial single-step tasks where clarification adds more latency than value. Do not use it when the user expects immediate execution and the clarification loop would degrade the experience. This prompt is also inappropriate for high-stakes domains (healthcare, legal, finance) unless the clarified goal is reviewed by a human before planning proceeds.

Required inputs and context: The prompt expects a raw user goal string and, optionally, any available context about the user's environment, tools, or prior interactions. It works best when paired with a tool manifest or capability description so it can identify constraints the user hasn't mentioned (e.g., 'you didn't specify a budget, but the available tools have rate limits of X calls per minute'). The output is a structured goal document containing: a refined objective statement, explicit constraints (budgets, deadlines, permissions, scope boundaries), identified ambiguities that need resolution, and a confidence score. Next step after using this prompt: Feed the clarified goal into a plan-generation prompt. If the confidence score is low or unresolved ambiguities remain, route to a human for clarification before planning.

This template is designed to sit between a user's natural-language request and your agent's planning module. Its job is to surface what the user left unsaid—budget limits, deadline pressure, permission boundaries, quality expectations, and non-negotiable constraints—before the planner commits to a course of action. Use it when user goals arrive as short, vague, or emotionally loaded statements (e.g., "optimize our pipeline" or "fix the onboarding flow"). Do not use it when the user has already provided a structured specification with explicit constraints; in that case, pass the specification directly to the planner and skip the elicitation overhead.

textCopy
You are a constraint-elicitation assistant. Your only job is to take an ambiguous user goal and produce a clarified version with explicit constraints. Do not solve the goal. Do not generate a plan. Do not recommend actions.

## Input
User goal: [USER_GOAL]
Available tools and capabilities: [AVAILABLE_TOOLS]
Known organizational context: [ORG_CONTEXT]
Risk tolerance level: [RISK_LEVEL]

## Task
Analyze the user goal and identify what is missing or ambiguous. For each gap, formulate a specific, answerable question that would resolve the ambiguity. Then produce a clarified goal statement that incorporates reasonable defaults for any gap you cannot resolve, marked with [ASSUMPTION: ...] tags.

## Output Schema
Return valid JSON only:
{
  "original_goal": "string",
  "clarified_goal": "string with [ASSUMPTION: ...] tags where defaults were used",
  "identified_gaps": [
    {
      "gap": "string describing what is missing",
      "clarification_question": "string question to ask the user",
      "default_assumption": "string or null if no reasonable default exists",
      "risk_if_wrong": "low | medium | high | critical"
    }
  ],
  "explicit_constraints": {
    "budget": "string or null",
    "deadline": "string or null",
    "permission_scope": "string or null",
    "quality_threshold": "string or null",
    "non_negotiables": ["string"],
    "excluded_actions": ["string"]
  },
  "requires_user_clarification": true,
  "safe_to_proceed_with_defaults": false
}

## Constraint Categories to Probe
1. Budget: Money, tokens, compute, or human time the user is willing to spend.
2. Deadline: When this must be done and consequences of lateness.
3. Permission scope: What the agent is allowed to read, modify, delete, or create.
4. Quality threshold: Minimum acceptable accuracy, completeness, or polish.
5. Non-negotiables: Constraints the user would rather abort than violate.
6. Excluded actions: Things the agent must never do, even if they seem efficient.
7. Stakeholders: Who else cares about the outcome and what they value.
8. Reversibility: Whether actions must be undoable or can be permanent.

## Rules
- If a gap has no reasonable default, set default_assumption to null and set safe_to_proceed_with_defaults to false.
- Mark risk_if_wrong as "critical" for gaps involving data deletion, financial transactions, external communication, or privacy.
- Never invent facts about the user's situation. Use [ORG_CONTEXT] if provided; otherwise, flag missing context as a gap.
- If the goal is too vague to clarify even with defaults, set requires_user_clarification to true and safe_to_proceed_with_defaults to false.

Adaptation guidance: Replace [USER_GOAL] with the raw user input. Populate [AVAILABLE_TOOLS] from your agent's tool manifest—this prevents the elicitation from probing constraints irrelevant to your capabilities. [ORG_CONTEXT] should carry persistent facts like team size, industry, and known policies; pull this from session memory or a user profile. Set [RISK_LEVEL] to low, medium, or high based on the domain (e.g., high for finance or healthcare). If your agent framework already has a structured constraint schema, replace the explicit_constraints block with your own fields. The output JSON is designed to feed directly into a planning module: pass clarified_goal as the planner's objective and explicit_constraints as its boundary conditions. If requires_user_clarification is true, route back to the user with the clarification_question list before invoking the planner.

This prompt is designed to sit at the entry point of an agent planning pipeline, before any task decomposition or tool selection occurs. It transforms an ambiguous user request into a structured, clarified goal with explicit constraints, budgets, deadlines, and permission scopes. The implementation harness must treat this prompt as a pre-processing gate: if the output fails validation or contains unresolved ambiguities, the system should not proceed to planning. Instead, it should loop back to the user for clarification or escalate to a human reviewer. The prompt is stateless by design—it does not require conversation history or session context—but the harness should store the clarified goal as a structured object that downstream planning modules consume.

Wire the prompt into your application as a synchronous validation step with the following flow: (1) Receive user input and inject it into the [USER_REQUEST] placeholder along with any available [TOOL_CATALOG], [ORGANIZATIONAL_POLICIES], and [RISK_LEVEL] context. (2) Call the model with response_format set to the JSON schema defined in the prompt template. (3) Validate the output against a constraint completeness checklist: every field in the schema must be populated or explicitly marked as "not_applicable"; no field should contain the original ambiguous phrasing; the permission_scope must enumerate specific allowed and disallowed actions. (4) If validation fails, construct a targeted clarification question from the ambiguities_flagged array and present it to the user. Retry up to two times with the clarified input before escalating. (5) On success, serialize the clarified goal object and pass it to the plan generation module. Log the raw user input, the clarified output, and the validation result for audit trails and prompt regression testing.

For high-risk domains (finance, healthcare, legal, infrastructure operations), insert a human review gate after validation succeeds but before the clarified goal is released to the planning engine. The review interface should display the original user request side-by-side with the model's clarified output, highlighting any fields where the model made inferences or filled gaps. The reviewer can approve, edit, or reject the clarification. Rejections should trigger a structured feedback loop that improves future clarifications. For model choice, prefer models with strong instruction-following and structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller models that may collapse the constraint categories or hallucinate tool capabilities. Set temperature to 0 or near-zero to maximize consistency across repeated runs. Do not use RAG for this prompt—the constraint elicitation relies on the model's reasoning over the user's request and known policies, not external knowledge retrieval. If your agent frontend supports tool definitions, you can optionally pass the available tool list in [TOOL_CATALOG] to help the model identify permission boundaries, but the prompt should still work without it by marking unknown tools as requiring clarification.