Concurrent Agent Plan Merge Conflict Resolution Prompt

Use this prompt when you have multiple agents that have independently produced execution plans and those plans overlap, conflict on resource usage, contradict each other on ordering constraints, or pursue incompatible goals. This prompt resolves those conflicts into a single coherent, safe, and executable merged plan. It is designed for multi-agent system builders and AI reliability engineers who need a deterministic recovery step when concurrent planning produces divergence. The ideal user is integrating this prompt into an agent harness that detects plan conflicts programmatically—by comparing resource claims, dependency graphs, or goal vectors—and then invokes this prompt as a structured recovery path before any agent takes action on a conflicting plan.

The required context for this prompt includes the full text of each conflicting plan, a description of the shared execution environment (available tools, resources, and their capacities), and the original goal or task that spawned the plans. Without this context, the merge cannot reason about resource constraints or goal alignment. The prompt expects plans to be provided in a structured format that identifies actions, their preconditions, the resources they consume, and their expected outcomes. If your agents produce plans as unstructured natural language, you must first normalize them into a comparable schema before invoking this merge prompt. The merge output should be validated against safety invariants—no resource over-allocation, no circular dependencies, and no dropped required actions—before being dispatched for execution.

Do not use this prompt for simple task assignment collisions or for merging observations; those are separate recovery workflows covered by the Multi-Agent Task Assignment Collision Prompt and the Concurrent Agent Observation Merge Prompt respectively. Do not use this prompt when only one agent has produced a plan; there is nothing to merge. Do not use this prompt when the plans are so fundamentally incompatible that no safe merge exists—for example, when two agents propose mutually exclusive irreversible actions with no rollback path. In those cases, escalate to a human operator or a higher-level arbitration agent rather than forcing a merge that could produce an unsafe composite plan. Finally, do not use this prompt as a substitute for proper agent coordination protocols; it is a recovery mechanism for when coordination fails, not a primary planning strategy.

This template resolves merge conflicts between concurrent agent plans that contain overlapping resources, contradictory ordering constraints, or incompatible goal specifications. Copy the block below into your agent harness, populate the square-bracket placeholders with runtime data from your plan store and conflict detector, and call the model. The prompt is designed to produce a structured merge decision plus a conflict-resolution trace that your harness can validate before committing the merged plan.

textCopy
You are a plan-merge resolver for a multi-agent system. Your job is to reconcile conflicting execution plans produced by concurrent agents into a single coherent plan.

## INPUTS

### Plan A
[PLAN_A]

### Plan B
[PLAN_B]

### Conflict Report
[CONFLICT_REPORT]

### Shared Resource Pool
[SHARED_RESOURCES]

### Global Ordering Constraints
[ORDERING_CONSTRAINTS]

### Goal Priority Rules
[GOAL_PRIORITY_RULES]

### Safety Constraints
[SAFETY_CONSTRAINTS]

## OUTPUT SCHEMA

Return a valid JSON object with exactly these fields:

{
  "merged_plan": [
    {
      "step_id": "string (unique identifier)",
      "action": "string (what to execute)",
      "agent": "string (assigned agent or 'any')",
      "depends_on": ["step_id"],
      "resource_claims": ["resource_id"],
      "rollback_action": "string (undo instruction if step fails)"
    }
  ],
  "conflicts_resolved": [
    {
      "conflict_id": "string (from conflict report)",
      "resolution": "string (choose: 'plan_a_wins', 'plan_b_wins', 'merged', 'deferred', 'escalated')",
      "rationale": "string (why this resolution was chosen)",
      "safety_impact": "string (low | medium | high | none)"
    }
  ],
  "unresolved_conflicts": [
    {
      "conflict_id": "string",
      "reason": "string (why it could not be resolved)",
      "recommended_escalation": "string (who or what to escalate to)"
    }
  ],
  "completeness_check": {
    "all_goals_covered": true,
    "missing_goals": ["string (goal descriptions not addressed)"],
    "ordering_violations": ["string (any ordering constraints broken)"],
    "resource_overcommits": ["string (resources claimed by multiple steps at same time)"]
  },
  "safety_assessment": {
    "overall_risk": "string (low | medium | high | critical)",
    "requires_human_approval": true,
    "risk_notes": ["string (specific risks identified)"]
  }
}

## RESOLUTION RULES

1. Safety constraints override all other priorities. If a step in either plan violates a safety constraint, it must be removed or modified.
2. Resource conflicts: apply the goal priority rules to decide which agent gets the resource. If priority is equal, prefer the plan with fewer total resource claims.
3. Ordering conflicts: preserve ordering constraints. If both plans specify contradictory orders for the same steps, use the ordering from the higher-priority goal.
4. Goal contradictions: if the plans pursue mutually exclusive goals, select the goal with higher priority. Document the excluded goal in unresolved_conflicts.
5. Do not invent new steps. Only merge, reorder, or remove steps from the input plans.
6. Every step in the merged plan must have a rollback_action.
7. If any conflict has safety_impact of 'high' or 'critical', set requires_human_approval to true.

## CONSTRAINTS

- Do not add steps that do not appear in Plan A or Plan B.
- Do not ignore conflicts listed in the conflict report. Every conflict must appear in either conflicts_resolved or unresolved_conflicts.
- Preserve all ordering constraints listed in the input.
- If you cannot resolve a conflict safely, escalate it rather than guessing.

Before wiring this into production, adapt the placeholder resolution rules to match your system's actual priority model. If your agents use numeric priorities, replace the text rules with a scoring function. If you have a human-in-the-loop queue, add a [REVIEW_QUEUE_ENDPOINT] placeholder and instruct the model to format escalation payloads for that endpoint. The output schema is deliberately strict: your harness should validate the JSON against this schema before accepting the merged plan. Reject any response that omits required fields or contains step IDs not present in the input plans.

The Concurrent Agent Plan Merge Conflict Resolution Prompt is not a standalone chat instruction. It is a structured merge operator that sits inside an agent orchestration harness. The harness is responsible for collecting the conflicting plans, assembling the prompt with the correct [AGENT_A_PLAN], [AGENT_B_PLAN], [SHARED_GOAL], [RESOURCE_CONSTRAINTS], and [CONFLICT_METADATA] placeholders, and then validating the merged output before it is dispatched for execution. Do not call this prompt without first confirming that a real conflict exists—running it on already-compatible plans wastes tokens and risks introducing unnecessary reordering.

Wire the prompt into a merge step that fires only when the orchestrator detects overlapping resource claims, contradictory ordering constraints, or mutually exclusive goal assignments. The harness should serialize each agent plan into a canonical JSON structure with fields for steps, resource_locks, preconditions, and expected_outcomes. Before calling the model, compute a lightweight conflict fingerprint (hash of overlapping resource IDs and contradictory preconditions) and attach it as [CONFLICT_METADATA]. After the model returns a merged plan, run a deterministic post-validation pass: check that no resource is double-booked in the same time window, that all original goal requirements are covered, and that no step depends on an output that was reordered after it. If validation fails, retry once with the validation errors injected into [PREVIOUS_FAILURE_CONTEXT]. If the second attempt also fails, escalate to a human operator with the conflict fingerprint and both original plans—do not loop beyond two retries.

Model choice matters here. Use a model with strong reasoning and structured-output discipline (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature=0 or very low to maximize deterministic merge behavior. The output schema must be strict: a JSON object with merged_plan (array of steps), resolution_decisions (array of conflict-to-resolution mappings), and safety_notes (array of warnings about assumptions made during merge). Log every merge attempt with the conflict fingerprint, model version, raw prompt, raw output, validation result, and final disposition (accepted, retried, escalated). This audit trail is essential for debugging merge failures and proving correctness to downstream systems that will execute the merged plan.

The most common production failure mode is not a bad merge but a merge that silently drops a constraint. A resource lock from Agent A's plan might be omitted from the merged output because the model prioritized conciseness over completeness. Your post-validation must explicitly check that every resource lock, precondition, and goal requirement from both input plans is either preserved in the merged plan or explicitly resolved with a documented trade-off in resolution_decisions. If a constraint disappears without a corresponding resolution entry, reject the output. The second most common failure is ordering inversion: the merged plan reorders steps in a way that violates a hard dependency. Validate the merged step sequence against the original dependency graphs before accepting the output. These checks are not optional—they are the difference between a merge that looks plausible and one that is safe to execute.