Agent Output Conflict Resolution for Tool Selection Disagreements Prompt Template

This prompt is for agent platform engineers and orchestration engineers who need to resolve disputes when multiple agents select different tools or functions for the same task. It acts as an arbitration layer that evaluates each agent's tool choice against capability requirements, safety constraints, and the original user intent. The core job-to-be-done is producing a single, auditable tool selection decision with a clear fallback specification when your agent graph produces conflicting tool calls. You should reach for this prompt when you have two or more agents that independently chose different external functions, APIs, or database operations for the same user request, and you need a deterministic resolution path that can be logged, reviewed, and traced.

Before using this prompt, you must have the original user request, the full list of available tools with their schemas and capability descriptions, and the conflicting tool selections from each agent with their justifications. The prompt works best when agents provide structured reasoning for their tool choices rather than bare function names. You should also supply any relevant safety policies, rate limits, or access control rules that constrain tool usage. Do not use this prompt for single-agent tool selection—that belongs in the function calling and tool selection pillar. Do not use it for conflicts that are purely about output content rather than tool choice, such as two agents producing different text answers from the same tool. The prompt is designed for the specific failure mode where the agent graph diverges at the action layer, not the content layer.

The prompt requires you to define a [TOOLS] manifest that includes each tool's name, description, required parameters, capability tags, and safety constraints. You must also provide the conflicting agent selections in a structured format that includes the agent identifier, selected tool, arguments, and a justification string. The output is a structured arbitration decision containing the winning tool selection, a capability match score, a safety compliance flag, a fallback tool if the primary selection is unavailable, and an audit trail explaining why other selections were rejected. For high-risk domains such as financial transactions, healthcare operations, or infrastructure changes, you must route the arbitration output through a human approval step before execution. The prompt includes a [RISK_LEVEL] parameter that adjusts the decision threshold and fallback behavior accordingly.

Common failure modes to watch for include the arbitrator selecting a tool that satisfies capability requirements but violates an unstated safety constraint, the arbitrator hallucinating tool parameters that don't exist in the actual tool schema, and the arbitrator failing to detect that none of the proposed tools are actually suitable—requiring escalation rather than forced selection. You should implement post-arbitration validation that checks the selected tool against the actual tool registry, verifies parameter schemas, and confirms that safety flags are consistent with the declared risk level. Start by running this prompt against a golden dataset of known tool conflicts where you've pre-labeled the correct resolution, and measure both selection accuracy and the quality of the audit trail before deploying to production agent pipelines.

This prompt template serves as the core arbitration logic for resolving tool selection conflicts in multi-agent systems. When two or more agents propose different tools for the same user request, this prompt acts as the final decision layer. It evaluates each proposal against capability requirements, safety constraints, and task intent before selecting the best tool or triggering a fallback. The template is designed to be dropped directly into an orchestration layer where conflicting tool proposals need systematic resolution rather than ad-hoc selection.

textCopy
You are a tool selection arbitrator for a multi-agent system. Your job is to resolve disagreements between agents that have proposed different tools or functions for the same task. You must select the single best tool based on capability matching, safety alignment, and task requirements. If no tool is suitable, you must specify a fallback action.

## ORIGINAL USER REQUEST
[USER_REQUEST]

## CONFLICTING TOOL PROPOSALS
[TOOL_PROPOSALS]

## AVAILABLE TOOL CATALOG
[TOOL_CATALOG]

## SAFETY AND POLICY CONSTRAINTS
[SAFETY_CONSTRAINTS]

## ARBITRATION RULES
1. Match each proposed tool against the user request to verify it can fulfill the core intent.
2. Check each tool against the safety constraints. Reject any tool that violates a constraint.
3. Compare the remaining tools on capability coverage, argument completeness, and side-effect risk.
4. If multiple tools remain valid, select the one with the lowest side-effect risk and highest capability match.
5. If no tool is valid, specify a fallback: request clarification, escalate to a human, or use a safe default action.

## OUTPUT FORMAT
Return a JSON object with the following structure:
{
  "selected_tool": "tool_name_or_null",
  "selected_arguments": {},
  "rejected_tools": [
    {
      "tool_name": "string",
      "rejection_reason": "string"
    }
  ],
  "capability_gap_analysis": "string",
  "safety_check_results": "string",
  "fallback_action": "string_or_null",
  "confidence_score": 0.0_to_1.0,
  "arbitration_rationale": "string"
}

## INSTRUCTIONS
- If you select a tool, `selected_tool` must be the exact tool name from the catalog and `fallback_action` must be null.
- If you cannot select any tool, `selected_tool` must be null and `fallback_action` must contain a concrete next step.
- `confidence_score` must reflect your certainty in the decision. Use 0.0 for complete uncertainty and 1.0 for absolute certainty.
- `arbitration_rationale` must explain why the selected tool was chosen and why each rejected tool was eliminated.

Adapt this template by populating the four input placeholders before each arbitration call. [USER_REQUEST] should contain the original user intent in its raw form—do not paraphrase or summarize, as this can mask capability requirements. [TOOL_PROPOSALS] must include each agent's proposed tool name, arguments, and the agent's rationale for selection. Structure this as a JSON array or clearly delimited text block so the arbitrator can parse individual proposals. [TOOL_CATALOG] should be the authoritative list of available tools with their schemas, descriptions, and side-effect classifications (read-only, write, destructive). [SAFETY_CONSTRAINTS] must enumerate hard policy rules such as data access boundaries, user confirmation requirements, and prohibited action categories. If your system has dynamic constraints that vary by user role or session context, inject those into this placeholder at runtime rather than hardcoding them into the prompt.

The output schema is designed for direct consumption by an orchestration engine. Parse the selected_tool and selected_arguments fields to execute the chosen tool programmatically. If selected_tool is null, route the fallback_action to your escalation handler. The confidence_score field enables threshold-based gating: if confidence falls below your system's minimum (typically 0.7 for automated execution), consider escalating even when a tool is selected. The rejected_tools array and arbitration_rationale provide an audit trail for debugging arbitration decisions in production. Store these alongside the execution log to diagnose patterns of incorrect tool selection or overly conservative fallback behavior.

Before deploying this prompt, build a validation layer that checks the JSON output for structural compliance. Common failures include malformed JSON when the model adds commentary outside the object, missing required fields, or selected_tool values that don't match the catalog. Implement a retry with the validation error message fed back as context if the output fails schema checks. For high-risk domains where tool execution has irreversible side effects, add a human approval gate before acting on the arbitration decision, regardless of confidence score. This prompt is not a substitute for access control—enforce tool permissions at the execution layer, not in the arbitration prompt.

This prompt is designed to be a deterministic gate in your agent graph, not an advisory suggestion. When your agent graph produces conflicting tool calls, collect all proposals, assemble the prompt variables, and call the arbitration model. The output is a structured JSON decision that your executor must validate and follow. The primary integration point is immediately after tool proposal generation and before any side-effect-producing function call. Treat the arbitration model's output as the single source of truth for the next action, but never execute it blindly—always validate the JSON against the expected schema before proceeding.

Implement a confidence threshold gate using the confidence_score field in the output. If the score falls below your threshold (recommend 0.7), route to a human reviewer with the full arbitration rationale, agent proposals, and the fallback_action payload. For high-risk tools—those that modify data, send communications, or execute financial transactions—add a second validation pass that confirms the selected tool's arguments match the user request before execution. Log every arbitration decision with the agent proposals, selected tool, rationale, and confidence score for auditability. If the model returns a fallback_action, execute that action directly rather than retrying arbitration; the model has already determined that no proposed tool is safe or appropriate.

Model choice matters here. Use a model with strong reasoning and structured output capabilities. Avoid models that are prone to hallucinating tool schemas or ignoring explicit constraints. Implement a retry policy with a maximum of two attempts for malformed JSON, but do not retry for low-confidence decisions—those should escalate. Monitor for arbitration latency, as this step adds a synchronous call to your critical path. If latency becomes a bottleneck, consider caching arbitration decisions for identical proposal sets or pre-computing tool capability mappings to reduce the prompt's reasoning burden. The most common production failure is executing a tool without validating the arbitration output's schema, which can lead to silent argument corruption.