Agent Output Conflict Resolution for Classification Routing Disagreements Prompt Template

This prompt is designed for a specific failure mode in multi-agent pipelines: when two or more classification or routing agents assign the same user input to different downstream handlers. This is not a general disagreement about facts, code quality, or tool selection. It is a structural conflict where the system cannot proceed because it has multiple conflicting paths for the same request. The ideal user is a platform engineer or system architect who has already instrumented their agents to report routing labels and confidence scores, and now needs a programmatic, auditable tie-breaker that can run in production without blocking the entire pipeline.

Use this prompt when the cost of misrouting is measurable and the downstream handlers have different risk profiles. For example, a customer support ticket might be routed to 'billing' by one agent and 'technical-support' by another. Sending a billing dispute to technical support has a clear, negative business outcome. The prompt template requires you to supply [AGENT_A_ROUTE], [AGENT_B_ROUTE], [CONFIDENCE_SCORES], [INPUT_SUMMARY], and a [RISK_MATRIX] that quantifies the impact of each possible misrouting. It then produces a final decision, a confidence comparison, a risk assessment, and an explicit escalation path if the ambiguity is too high. This makes the decision logic transparent and reviewable, rather than relying on a hidden heuristic like 'pick the highest confidence score.'

Do not use this prompt for conflicts where the agents disagree on the content of an answer, the steps in a plan, or which tool to call. Those scenarios require different arbitration structures covered in sibling playbooks like the LLM Arbitration Judge or the Agent Output Conflict Resolution for Tool Selection Disagreements. Also, do not use this prompt if you haven't defined a [RISK_MATRIX]. Without a quantified cost of misrouting, the prompt cannot make a principled trade-off and will default to escalating everything, which defeats the purpose of automation. Before implementing, ensure your upstream agents produce structured routing labels and calibrated confidence scores; garbage in will produce garbage arbitration out.

This prompt template acts as a classification routing arbitrator, designed to resolve disagreements between multiple routing agents and produce a single, defensible routing decision. It is intended for platform engineers and system designers who have already run several agents against the same input and received conflicting routing labels. The prompt forces a structured comparison of agent outputs against a defined taxonomy, a severity matrix for misrouting, and a configurable escalation threshold. Do not use this prompt for general classification or for merging outputs that are not routing labels; it is specifically designed for the conflict resolution step in a multi-agent triage pipeline.

textCopy
You are a classification routing arbitrator. Your job is to resolve disagreements between routing agents and produce a final routing decision.

## ROUTING TAXONOMY
[ROUTING_TAXONOMY]

## MISROUTING SEVERITY DEFINITIONS
[MISROUTING_SEVERITY_MATRIX]

## ESCALATION THRESHOLD
[ESCALATION_THRESHOLD]

## AGENT OUTPUTS
[AGENT_OUTPUTS]

## ORIGINAL INPUT
[ORIGINAL_INPUT]

## INSTRUCTIONS
1. Compare the routing labels assigned by each agent.
2. For each agent, evaluate the confidence score and stated rationale against the original input.
3. Identify which routing label best matches the input based on the taxonomy definitions.
4. Assess the misrouting risk for each candidate label using the severity matrix.
5. If the confidence gap between the top two labels is below the escalation threshold, or if the misrouting risk for the leading label exceeds the threshold, escalate to human review.
6. Produce a final routing decision in the exact output format specified.

## OUTPUT FORMAT
Return a single JSON object with the following structure:
{
  "final_routing_label": "string",
  "confidence_score": 0.0,
  "decision_type": "resolved|escalated",
  "rationale": "string",
  "agent_alignment": {
    "agreeing_agents": ["agent_id"],
    "disagreeing_agents": ["agent_id"]
  },
  "risk_assessment": {
    "misrouting_risk": "low|medium|high|critical",
    "risk_rationale": "string"
  },
  "escalation": {
    "required": true,
    "reason": "string",
    "recommended_reviewer_role": "string"
  }
}

## CONSTRAINTS
- Do not invent routing labels outside the provided taxonomy.
- If escalation is required, set final_routing_label to null.
- Confidence scores must be between 0.0 and 1.0.
- The rationale must reference specific agent outputs and taxonomy definitions.
- If all agents agree, decision_type must be "resolved" and the rationale must explain why agreement is sufficient.

To adapt this template, you must populate five square-bracket placeholders with concrete data from your system. [ROUTING_TAXONOMY] should contain your complete list of valid routing labels with definitions, such as "billing": "Requests related to invoices, payments, or account charges.". [MISROUTING_SEVERITY_MATRIX] defines the business impact of sending an input to the wrong queue, for example "critical": "Routing a legal hold request to general support causes regulatory exposure.". [ESCALATION_THRESHOLD] is a numeric value (e.g., 0.15) representing the minimum confidence gap required to auto-resolve; if the top two labels are within this gap, the decision escalates. [AGENT_OUTPUTS] is a JSON array of objects, each containing agent_id, routing_label, confidence_score, and rationale. [ORIGINAL_INPUT] is the raw user text or event payload that the agents classified. The output is a single JSON object that your orchestration layer can parse to either forward the input to the resolved queue or place it in a human review queue with the recommended reviewer role.

Before deploying this prompt, build a validation layer around the JSON output. The validator must confirm that final_routing_label is either null (when escalation.required is true) or a string present in the provided taxonomy. Reject any output where decision_type is "resolved" but agent_alignment.disagreeing_agents is not empty, as this indicates a logic error. For high-stakes routing domains—such as healthcare intake, legal triage, or security incident response—always log the full arbitration payload and consider a secondary review step even for resolved decisions where misrouting_risk is "high" or "critical". This prompt is a decision-support tool, not a replacement for a well-governed routing architecture.

Integrating the arbitrator prompt into a production pipeline requires a structured API call, strict pre- and post-validation, and a clear escalation path. The goal is to make every arbitration decision deterministic and auditable, not just to get a plausible JSON response. Before calling the model, validate that all agent outputs reference labels present in your current routing taxonomy. Reject any output containing an unknown label and log it as a taxonomy drift event. Normalize all agent confidence scores to a 0.0–1.0 range if different agents use different scales, so the arbitrator receives comparable inputs.

Call the arbitrator as a structured output request with JSON mode enabled. Set response_format to json_object and provide the output schema explicitly. Use a low temperature (0.0–0.2) to minimize variance in arbitration decisions. If the model provider does not support strict JSON mode, wrap the call in a retry loop that validates the schema and retries once with the validation error appended as a correction instruction. After receiving the output, validate that final_routing_label is either null (indicating escalation) or a valid label from the taxonomy. Confirm that confidence_score falls within 0.0–1.0. Check that decision_type matches the escalation.required field: if escalation.required is true, decision_type must be "escalated" and final_routing_label must be null. If any validation fails, retry once with the specific error injected into the prompt. If the second attempt also fails, log the failure and escalate to human review with the raw agent outputs and all validation errors.

Log every arbitration decision with the timestamp, a hash of the original input, the full agent outputs, the arbitrator's raw response, the validation result, and the final routing action taken. This audit log is essential for measuring misrouting impact and calibrating escalation thresholds over time. When escalation.required is true, route the arbitration output to a human review queue. Include the original input, all agent outputs, and the arbitrator's risk assessment. The human reviewer should confirm or override the escalation decision. Track reviewer decisions to measure arbitrator accuracy and identify threshold calibration opportunities. Avoid deploying this prompt without the validation and logging harness; an unvalidated arbitrator can silently route inputs to the wrong handler and erode trust in the entire agent pipeline.