Conflict Detection Prompt for Overlapping Agent Roles

This prompt is for orchestrator builders and platform engineers who manage a registry of specialized sub-agents. Its primary job is to detect when two or more agents claim overlapping capabilities, produce contradictory outputs, or have conflicting tool access that could cause race conditions or deadlocks in a compound AI system. You should use this prompt before deploying a new agent, after updating an agent's capability manifest, or when an orchestrator receives conflicting responses from multiple agents during a task. The output is a structured conflict analysis with resolution recommendations and arbitration triggers—not a resolution itself. It produces the evidence your orchestrator needs to make a safe routing or arbitration decision.

Deploy this prompt at three specific integration points in your agent pipeline. First, run it as a pre-deployment gate whenever a new agent is registered or an existing agent's capability manifest is modified. The prompt compares the incoming manifest against all registered agents and flags capability overlaps, tool access collisions, and output schema conflicts before the agent ever handles a live task. Second, wire it into your orchestrator's conflict-resolution path: when an orchestrator receives contradictory outputs from multiple agents for the same subtask, invoke this prompt with the conflicting outputs and agent manifests to get a structured arbitration recommendation. Third, use it during periodic agent registry audits to detect capability drift where agents have organically expanded their scope through prompt updates or tool additions without explicit manifest changes. In all cases, the prompt requires a complete agent registry, including capability declarations, tool access lists, and recent output samples if available.

Do not use this prompt as a real-time decision maker in latency-sensitive paths. The conflict analysis requires comparing multiple agent manifests and outputs, which adds non-trivial token overhead. Instead, use it to generate conflict rules that your orchestrator can evaluate quickly at runtime. Also avoid using this prompt when you have fewer than two registered agents—there is no conflict to detect. If your agents operate in entirely disjoint domains with no shared tools, data stores, or output consumers, the prompt will correctly return a null conflict result, but you are better off skipping the analysis entirely. Finally, this prompt does not resolve conflicts; it identifies and classifies them. You will need a separate arbitration prompt or deterministic routing rule to act on its recommendations. For high-risk domains where conflicting agent actions could cause data corruption, financial impact, or safety issues, always require human review of the conflict analysis before automated resolution executes.

The following prompt template is designed to be dropped into an orchestrator's evaluation pipeline before dispatching work or after registering new agents. It accepts a structured agent registry and produces a conflict report that your application can parse to trigger alerts, block unsafe dispatches, or queue a human review. The template uses square-bracket placeholders that your application must populate at runtime—do not ship this prompt with unresolved placeholders.

textCopy
You are an agent conflict auditor. Your task is to analyze a registry of specialized agents and identify overlapping capabilities, contradictory outputs, and conflicting tool access that could cause failures in a multi-agent system.

## INPUT
[AGENT_REGISTRY]

## OUTPUT SCHEMA
Return a valid JSON object with the following structure:
{
  "conflicts": [
    {
      "conflict_id": "string",
      "conflict_type": "overlap | contradiction | tool_conflict | scope_violation",
      "agents_involved": ["agent_id"],
      "description": "string explaining the conflict",
      "evidence": {
        "agent_a_claim": "string",
        "agent_b_claim": "string",
        "tool_or_capability": "string"
      },
      "severity": "critical | high | medium | low",
      "resolution_recommendation": "string",
      "arbitration_trigger": "string describing when the orchestrator must intervene"
    }
  ],
  "no_conflicts_found": false,
  "audit_summary": "string"
}

## CONSTRAINTS
- Only report conflicts where two or more agents make claims that would cause incorrect execution, tool misuse, or contradictory user-facing outputs.
- Do not flag complementary capabilities as conflicts.
- If an agent's declared capabilities exceed its permitted tool access, flag as a scope_violation.
- If two agents would produce different answers to the same query given identical context, flag as a contradiction.
- If two agents claim the same exclusive responsibility, flag as an overlap.
- If agents have access to tools that could interfere with each other's state, flag as a tool_conflict.
- Severity "critical" means the conflict could cause data loss, security violation, or user harm.
- Severity "high" means the conflict would produce incorrect results.
- Every conflict must include an arbitration_trigger that tells the orchestrator when to step in.

## EXAMPLES
[CONFLICT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

Adaptation guidance: Replace [AGENT_REGISTRY] with a JSON array of agent objects, each containing at minimum agent_id, declared_capabilities, tool_access_list, output_contract, and role_boundary. Populate [CONFLICT_EXAMPLES] with 2–3 few-shot examples of correctly flagged conflicts from your own agent catalog—this dramatically improves detection accuracy. Set [RISK_LEVEL] to "high" if the orchestrator controls tools that modify production data, or "standard" otherwise; this field adjusts the auditor's sensitivity to borderline cases. If your registry is large, consider chunking agents by domain and running the prompt per cluster to stay within context limits.

What to do next: Parse the output JSON in your application layer. For any conflict with severity critical or high, block the orchestrator from dispatching to the involved agents until a human reviews the conflict report. For medium and low conflicts, log the report and set a review deadline. Do not rely on the model's no_conflicts_found field alone—always validate that the returned JSON conforms to the output schema before trusting the result. If the model returns malformed JSON, retry once with a repair prompt; if that fails, escalate to a human operator with the raw agent registry attached.

The conflict detection prompt is not a standalone utility; it is a control-plane component that should be wired directly into your orchestrator's agent registration and dispatch pipeline. When a new agent is registered or its capability manifest is updated, the orchestrator should run this prompt against the existing agent registry to detect overlapping claims before they cause production failures. The prompt expects a structured input containing the candidate agent's declared capabilities, tool access list, and output contracts alongside the current registry of active agents. The output is a conflict analysis with severity classification, overlap descriptions, and recommended resolution actions. This analysis should be treated as a gating check: if high-severity conflicts are detected, the orchestrator should block registration or flag the overlap for human review before the agent is allowed to participate in dispatch decisions.

Wire the prompt into your orchestrator as a pre-registration hook with the following implementation pattern. First, serialize the candidate agent's capability manifest and the current registry into the [AGENT_REGISTRY] and [CANDIDATE_MANIFEST] placeholders. The model should return a structured JSON output conforming to a schema that includes conflicts (array of overlap objects with severity, agent_a, agent_b, overlapping_capability, tool_conflict, output_contract_conflict, and resolution_recommendation fields) and arbitration_required (boolean). Validate the output against this schema before acting on it. If validation fails, retry once with the validation error included in the prompt context. If the retry also fails, escalate to a human operator and block the registration. For high-severity conflicts where arbitration_required is true, route the conflict analysis to a review queue rather than auto-resolving. Log every conflict detection run with the candidate manifest, registry snapshot, model output, and resolution decision for auditability. This is especially important in regulated environments where agent capability changes must be traceable.

Model choice matters here. Use a model with strong reasoning and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate. Avoid smaller or faster models that may miss subtle capability overlaps or produce inconsistent severity classifications. Set temperature low (0.0–0.2) to maximize consistency across runs. If your orchestrator processes many agent registrations per hour, consider caching conflict analyses for unchanged registry states and only re-running when the registry or candidate manifest changes. Do not use this prompt at dispatch time; it is a registration-time check. Runtime dispatch should rely on the resolved capability registry, not on re-detecting conflicts per request. The next step after implementing this harness is to build the arbitration workflow that consumes the conflict analysis output and either merges overlapping capabilities, assigns priority to one agent, or rejects the registration with a clear explanation to the agent author.