Contradictory Input Tool Resolution Prompt

This prompt is designed for platform engineers and AI infrastructure teams who need to resolve conflicting signals in a user request before executing a tool call. The core job-to-be-done is preventing silent wrong-tool execution when a user's input contains internal contradictions—for example, asking to 'delete the production database and then back it up' or 'cancel my subscription but upgrade my plan immediately.' In these scenarios, guessing a single tool without acknowledging the conflict leads to downstream state corruption, security incidents, or user-facing errors that are harder to repair than a well-structured clarification request.

Use this prompt when your system sits between a user-facing interface and a defined tool catalog, and the cost of executing the wrong tool is high. The ideal user is an engineer integrating this prompt into a pre-execution guardrail layer—before any write operations, destructive actions, or state mutations. The prompt expects a structured input containing the raw user request, the available tool definitions, and any relevant conversation or session context. It is not designed for simple intent classification where no contradiction exists, nor for multi-step agent planning where the model should decompose a complex request into a sequence of tool calls. For those cases, use the Ambiguous Intent to Tool Mapping Prompt or an agent planning prompt instead.

Do not use this prompt when the tool catalog is flat, the user's intent is clearly singular, or the system can safely execute multiple tools in parallel without conflict. Overusing contradiction detection on straightforward requests adds latency and unnecessary clarification loops that degrade user experience. Before deploying, ensure you have defined a clear escalation path for unresolved contradictions—whether that means routing to a human reviewer, logging the conflict for offline analysis, or returning a structured clarification question to the user. The next section provides the copy-ready prompt template you can adapt to your tool catalog and risk tolerance.

This template is the core instruction set for a model that must resolve contradictory user requests and select a single tool. It is designed to be copied directly into your prompt management system or orchestration code. The prompt forces the model to identify the conflict, define a resolution strategy, and produce a single tool call with a clear justification, rather than silently picking a tool that matches only one part of the request. Use this template when your application accepts free-form user input that may contain conflicting goals, such as a request to both 'cancel my subscription' and 'upgrade my plan' in the same message.

textCopy
You are a tool-selection router that resolves contradictory signals in user input.
Your job is to detect when a user request contains conflicting intents, resolve the conflict using a defined strategy, and select exactly one tool to call.

## INPUT
User Request: [USER_REQUEST]
Available Tools: [TOOL_DEFINITIONS]
Conversation History: [CONVERSATION_HISTORY]
User Context: [USER_CONTEXT]

## CONFLICT DETECTION
1. Extract every distinct actionable intent from the user request.
2. Check if any pair of intents is contradictory. Contradictions include:
   - Mutually exclusive actions (e.g., create and delete the same resource).
   - Incompatible state transitions (e.g., upgrade and downgrade a subscription).
   - Conflicting parameters for the same tool (e.g., set temperature to hot and cold).
   - Temporal impossibilities (e.g., schedule a meeting for yesterday and tomorrow).
3. If no contradiction is found, proceed directly to tool selection.

## RESOLUTION STRATEGY
When a contradiction is detected, apply the following precedence rules in order:
1. **Explicit Over Implicit**: If one intent is stated explicitly and the other is implied, prefer the explicit intent.
2. **Most Recent Overrides**: If conversation history contains a prior resolution or clarification, prefer the most recent explicit instruction.
3. **Safety First**: If one action is irreversible or destructive, prefer the safer or reversible action and flag for human review.
4. **User Role Constraints**: If [USER_CONTEXT] includes permissions or role limits, discard intents that the user is not authorized to execute.
5. **Ask When Unresolvable**: If the conflict cannot be resolved with high confidence by the above rules, do not select a tool. Instead, produce a clarification request.

## OUTPUT SCHEMA
Return a single JSON object with the following structure:
{
  "conflict_detected": boolean,
  "conflict_annotation": {
    "intent_a": string,
    "intent_b": string,
    "contradiction_type": "mutually_exclusive" | "incompatible_state" | "conflicting_parameters" | "temporal_impossibility" | null,
    "resolution_strategy_applied": "explicit_over_implicit" | "most_recent_overrides" | "safety_first" | "user_role_constraints" | "ask_user" | null
  },
  "tool_selection": {
    "tool_name": string | null,
    "arguments": object | null,
    "justification": string
  },
  "clarification_question": string | null,
  "requires_human_review": boolean
}

## CONSTRAINTS
- Select exactly one tool or none. Never select multiple tools for contradictory intents.
- If no tool matches the resolved intent, set tool_name to null and provide a clarification_question.
- The justification field must explain why the selected tool was chosen over the conflicting alternative.
- If requires_human_review is true, do not execute the tool call; route to a human reviewer.
- Do not hallucinate tool names or arguments. Only use tools from [TOOL_DEFINITIONS].
- If [RISK_LEVEL] is "high", always set requires_human_review to true for any destructive action.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with your application's live data. [TOOL_DEFINITIONS] should be your full function schema, including descriptions and parameter types. [USER_CONTEXT] should include role, permissions, and account state. [EXAMPLES] is critical for teaching the model the boundary between resolvable and unresolvable conflicts—include at least one example where the model correctly asks for clarification and one where it resolves a conflict using the safety-first rule. [RISK_LEVEL] should be set to "high" for any domain involving financial transactions, healthcare actions, or irreversible state changes. After copying, test the prompt against a golden set of contradictory inputs and verify that the conflict_detected flag and tool_selection.tool_name match expected outcomes before deploying to production.

The Contradictory Input Tool Resolution Prompt is designed to sit between user input ingestion and tool execution. It should be invoked after the system has parsed the user request but before any tool call is dispatched. The prompt expects a structured input payload containing the user's raw request, the available tool catalog with schemas, and any relevant session or profile context. Its output is a conflict annotation, a resolution strategy, and a single tool choice with justification—not a final tool execution. This means your application harness must parse the model's structured output and then decide whether to proceed with the recommended tool call, escalate for human review, or ask the user a clarifying question.

Integration pattern: Wrap this prompt in a pre-execution guard function. The function should: (1) assemble the input payload with [USER_REQUEST], [TOOL_CATALOG], and optional [SESSION_CONTEXT]; (2) call the model with the prompt template and a strict JSON output schema; (3) validate the response against the expected schema (conflict flag, resolution strategy enum, selected tool ID, justification string, and confidence score); (4) check the conflict flag and confidence threshold. If conflict_detected is true or confidence is below your configured threshold (start with 0.7 and tune based on eval results), route to a human review queue or a clarification prompt rather than executing the tool. If the output fails schema validation, retry once with the validation error message appended to the prompt. If it fails twice, log the failure and escalate. Never execute a tool call when the conflict flag is true or the confidence score is below threshold—this is the primary safety invariant.

Model choice and latency: This prompt requires strong instruction-following and structured output capabilities. Use a model that supports JSON mode or function calling natively (e.g., GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro). Expect 200-500 output tokens and latency of 500-1500ms depending on the model and provider. If latency is critical, consider a smaller fine-tuned model specifically for conflict detection, but validate that it maintains the same abstention rate on your eval set. Logging and observability: Log every invocation with the input payload hash, the model's raw output, the parsed conflict annotation, the selected tool ID, the confidence score, and the final harness decision (proceed/block/escalate). This audit trail is essential for debugging wrong-tool executions and for demonstrating governance controls in regulated environments.

Eval integration: Before deploying, run this prompt against your golden test set of contradictory input examples. Measure: (1) conflict detection recall—what percentage of truly contradictory inputs are flagged; (2) false-positive rate—how often non-contradictory inputs are incorrectly flagged; (3) wrong-tool rate when the harness proceeds despite a missed conflict; (4) unnecessary escalation rate when the harness blocks a resolvable input. Track these metrics per tool category and per conflict type (e.g., parameter contradiction vs. intent contradiction vs. constraint violation). If wrong-tool rate exceeds 2% in production, increase the confidence threshold or add a secondary validation prompt before tool execution. What to avoid: Do not use this prompt as a standalone decision engine without the harness gates described above. Do not skip the conflict flag check even if the model selects a tool with high confidence—the flag is your primary safety signal. Do not deploy without logging the justification field; it is your best debugging artifact when the system makes the wrong call.