Multi-Agent Output Conflict Detection Prompt Template

This prompt is for evaluation engineers and system designers who operate multi-agent pipelines and need to detect when agent outputs conflict before those conflicts reach a downstream consumer, arbitration step, or end user. The core job-to-be-done is inserting a reliable, structured detection layer between agent execution and any resolution logic. You should use this prompt when you have two or more agent outputs that address the same task, a shared context or evidence set they were supposed to use, and a defined conflict taxonomy. The ideal user is someone building a production system where unhandled disagreements between agents produce untrustworthy outputs, corrupted downstream state, or user-facing errors that are expensive to fix after the fact.

Do not use this prompt when you need a final merged answer or an arbitration decision. This prompt only detects and classifies conflicts; it does not resolve them. It is also the wrong tool when you have a single agent output, when the agents were assigned completely different tasks with no overlap, or when you are looking for a general quality score rather than a specific inter-agent disagreement. If your goal is to produce a single coherent output from disagreeing agents, pair this prompt with an arbitration or synthesis prompt that consumes the structured conflict report this prompt generates. Using this prompt in isolation without a downstream resolution step will leave conflicts identified but unaddressed, which can stall pipelines or confuse operators.

Before wiring this prompt into your application, ensure you have defined your conflict taxonomy clearly. The prompt expects categories such as factual, structural, policy, tool-choice, and schema conflicts, along with severity definitions that match your product's risk tolerance. You should also prepare a representative set of agent output pairs with known conflicts and non-conflicts to use as an evaluation set. This will let you measure false positives—where the prompt flags agreement as conflict—and missed semantic conflicts—where agents disagree in meaning but use different wording that the prompt fails to catch. Start by running this prompt offline against logged agent outputs before putting it in the critical path of a live pipeline.

This prompt template is designed to be the core detection engine in your agent arbitration pipeline. It takes the raw outputs from two or more specialized agents, along with the shared evidence they were supposed to use, and produces a structured conflict report. The report classifies the type of disagreement, scores its severity, and aligns each agent's claims against the source material. Use this as a pre-processing step before routing to an arbitration judge, a human reviewer, or a reconciliation workflow.

textCopy
You are an output conflict detection system for a multi-agent pipeline. Your job is to compare the outputs of multiple agents, identify disagreements, and produce a structured conflict report.

# INPUTS
## Agent Outputs
[AGENT_OUTPUT_A]

[AGENT_OUTPUT_B]

## Shared Evidence
[SHARED_EVIDENCE]

## Conflict Taxonomy
[CONFLICT_TAXONOMY]

## Severity Definitions
[SEVERITY_DEFINITIONS]

# INSTRUCTIONS
1. Parse each agent output and extract all factual claims, structural elements, and conclusions.
2. Compare the outputs claim-by-claim and element-by-element. Identify every point of disagreement.
3. For each disagreement, classify it using the provided [CONFLICT_TAXONOMY]. If a disagreement does not fit the taxonomy, classify it as "OTHER" and propose a new category.
4. For each disagreement, assign a severity score using the provided [SEVERITY_DEFINITIONS].
5. For each factual disagreement, check the claim against the [SHARED_EVIDENCE]. Note which agent's claim is supported, which is contradicted, and which claims cannot be verified.
6. Do not resolve the conflict. Only detect, classify, and score it.

# OUTPUT SCHEMA
Return a single JSON object with the following structure:
{
  "conflict_report": {
    "summary": "A one-sentence summary of the overall conflict state.",
    "total_disagreements": <integer>,
    "disagreements": [
      {
        "id": "<string>",
        "type": "<from taxonomy>",
        "severity": "<from severity definitions>",
        "agent_a_claim": "<exact text or description>",
        "agent_b_claim": "<exact text or description>",
        "evidence_alignment": {
          "agent_a_supported": <boolean>,
          "agent_b_supported": <boolean>,
          "evidence_citation": "<relevant excerpt or null>",
          "unverifiable": <boolean>
        },
        "root_cause_hypothesis": "<brief hypothesis for why the disagreement occurred>"
      }
    ]
  }
}

# CONSTRAINTS
- Do not invent disagreements. Only report genuine conflicts.
- If the agent outputs are identical or semantically equivalent, return an empty disagreements array and set total_disagreements to 0.
- If the shared evidence is insufficient to verify a claim, set unverifiable to true and evidence_citation to null.
- Do not include any text outside the JSON object.

To adapt this template for your pipeline, replace the square-bracket placeholders with your actual data. [AGENT_OUTPUT_A] and [AGENT_OUTPUT_B] should contain the raw, unmodified text or structured objects from your agents. [SHARED_EVIDENCE] is the ground-truth source material both agents were supposed to use—this is critical for evidence alignment and prevents the detector from hallucinating support. [CONFLICT_TAXONOMY] should be a list of your defined conflict types, such as "FACTUAL", "STRUCTURAL", "POLICY", "TOOL_CHOICE", or "SCHEMA". [SEVERITY_DEFINITIONS] should map severity levels like "LOW", "MEDIUM", "HIGH", and "CRITICAL" to clear, operational criteria based on user-facing risk and reversibility. Before deploying, run this prompt against a golden dataset of known agent disagreements and measure both false positive rate (flagging agreement as conflict) and missed semantic conflict rate (failing to detect paraphrased disagreement).

The Multi-Agent Output Conflict Detection prompt is designed to sit between agent execution and downstream arbitration or human review. It should be called after two or more agents have produced outputs for the same task, but before those outputs are merged, presented to a user, or passed to another agent. The prompt expects structured agent outputs, the original task context, and any shared evidence as inputs. Its output is a conflict report that downstream systems can use to decide whether to escalate, arbitrate, or reconcile.

In a production harness, wrap this prompt in a validation layer that checks the output schema before proceeding. The conflict report should include a conflict_type enum (factual, structural, policy, tool-choice, schema), a severity_score between 0.0 and 1.0, and a list of conflicting_spans with agent attribution and evidence alignment. If the model returns malformed JSON or missing required fields, retry once with a repair prompt that includes the original output and the schema error. Log every conflict detection call with the input agent outputs, the raw model response, the validated report, and the retry count. For high-risk domains, route any conflict with severity_score > 0.7 to a human review queue with the full conflict report attached.

Model choice matters here. Use a model with strong instruction-following and structured output support, such as GPT-4o or Claude 3.5 Sonnet, because the task requires precise schema adherence and nuanced semantic comparison. Avoid smaller or older models that may conflate stylistic differences with factual conflicts. If you are running this prompt at high volume, consider caching the normalized agent outputs and evidence embeddings to reduce redundant comparisons. The next step after detection is to route the conflict report to an arbitration prompt, an escalation trigger, or a reconciliation workflow, depending on severity and type.