Agent State Reconciliation Prompt After Partition

This prompt is designed for infrastructure engineers and platform operators who must reconcile divergent agent state after a network partition, offline operation, or split-brain scenario. In multi-agent systems, partitions cause agents to operate on stale or isolated copies of shared state. When connectivity is restored, those copies must be merged into a single consistent state without data loss, duplicate work, or conflicting decisions. The prompt takes the pre-partition state, the divergent state copies from each partition side, and a conflict resolution policy, then produces a reconciled state document with explicit merge decisions, conflict resolutions, and an audit trail.

Use this prompt when you have two or more divergent state snapshots that must be merged deterministically after the partition has healed and all copies are available for analysis. The ideal user is a platform engineer or SRE who understands the state schema, the semantics of the data, and the business rules that should govern conflict resolution. Required inputs include the pre-partition baseline state, the divergent state copies from each side of the partition, and a conflict resolution policy that specifies which side wins for each field or how to merge values. The prompt works best when the state is structured (JSON, protobuf, or typed objects) and the conflict rules can be expressed declaratively.

Do not use this prompt for real-time state synchronization, live CRDT-based merges, or scenarios where the partition is still active and writes are ongoing. This prompt is not a substitute for a distributed consensus protocol or a CRDT implementation. It is a post-mortem reconciliation tool for scenarios where automated merge strategies failed or were not available. Avoid using this prompt when the state is unstructured natural language without clear field boundaries, as the model may hallucinate merge decisions. For high-risk domains such as financial ledgers, healthcare records, or safety-critical systems, always require human review of the reconciled output before applying it to the live system. The prompt produces an audit trail, but the final merge decision must be verified by an operator who understands the domain consequences.

This prompt template is the core instruction set you will send to a reconciliation agent. It is designed to ingest two or more divergent state snapshots, identify conflicts, and produce a single, authoritative reconciled state. The template uses square-bracket placeholders for all dynamic inputs. Before executing, you must replace every placeholder with concrete values from your system, such as the actual agent states, the priority rules for your domain, and the required output schema.

textCopy
You are a State Reconciliation Agent. Your task is to resolve divergent state snapshots from multiple agent instances that were separated by a network partition or offline operation. Produce a single, reconciled state object that represents the most accurate and complete truth.

## INPUT STATE SNAPSHOTS
[AGENT_STATE_SNAPSHOTS]

## RECONCILIATION RULES
Apply the following rules in order of priority to resolve conflicts:
[RECONCILIATION_RULES]

## OUTPUT SCHEMA
Your entire response must be a single JSON object conforming to this schema:
{
  "reconciled_state": {
    // The final, merged state object. Include all fields from the input schema.
  },
  "conflict_resolutions": [
    {
      "field_path": "string", // e.g., 'user_profile.email'
      "conflict_type": "string", // e.g., 'UPDATE_CONFLICT', 'DELETE_UPDATE_CONFLICT'
      "winning_value": "any",
      "losing_values": ["any"],
      "resolution_strategy": "string", // e.g., 'LAST_WRITER_WINS', 'CUSTOM_RULE', 'MANUAL_REVIEW_REQUIRED'
      "rule_applied": "string" // The specific rule from RECONCILIATION_RULES that decided this
    }
  ],
  "manual_review_required": [
    {
      "field_path": "string",
      "reason": "string",
      "conflicting_values": ["any"]
    }
  ],
  "data_loss_risk": "string", // 'NONE', 'LOW', 'MEDIUM', 'HIGH'
  "reconciliation_summary": "string" // A brief natural language summary of actions taken
}

## CONSTRAINTS
- Do not invent data. If a value cannot be resolved with high confidence, flag it for manual review.
- Preserve the full audit trail of which agent contributed which value.
- If a delete operation conflicts with an update, apply the rule set but explicitly log the risk.
- The reconciled_state must be a complete, valid object according to the application's state schema.

To adapt this template, start by replacing [AGENT_STATE_SNAPSHOTS] with a structured list of the divergent states, including a unique agent ID and a vector clock or timestamp for each. The [RECONCILIATION_RULES] placeholder should be replaced with a clear, ordered list of your business logic, such as 'Last Writer Wins based on timestamp' or 'Agent A's state is authoritative for financial fields.' After running this prompt, always validate the output against your application's state schema before persisting it. For high-risk domains, the manual_review_required list must be surfaced to a human operator for approval before any state is merged.

The reconciliation prompt is the decision core of a larger state-recovery pipeline. It should never run in isolation. Surround it with pre-processing that collects divergent state snapshots, post-processing that validates the merged output against a known schema, and a persistence layer that writes the reconciled state only after all checks pass. The prompt itself is stateless; the harness owns state, idempotency keys, and retry decisions.

Before calling the model, assemble the two divergent state objects, the partition event metadata (start time, end time, affected agents), and any pre-merge conflict flags from deterministic checks. Pass these as [STATE_A], [STATE_B], and [PARTITION_CONTEXT]. After the model returns, run a schema validator against the reconciled output to confirm required fields exist, timestamps are monotonic, and no data was silently dropped. If validation fails, retry once with the validator error message appended to [CONSTRAINTS]. If it fails again, log the full input/output pair and escalate to a human operator. For high-risk domains such as financial ledgers or clinical records, require a human approval step before the reconciled state is committed—the model's output becomes a proposal, not the final state.

Model choice matters here. Use a model with strong structured-output support and a context window large enough to hold both full state objects plus instructions. GPT-4o and Claude 3.5 Sonnet are good defaults. Avoid smaller models that may hallucinate merge operations or drop fields. Set temperature=0 to reduce variance in conflict-resolution decisions. Log every reconciliation attempt with the partition ID, model version, input hashes, output diff from previous state, and the final merge decision. This audit trail is essential for debugging silent data corruption and proving consistency guarantees to compliance reviewers. Wire the harness to a dead-letter queue for any reconciliation that fails validation after retries—never silently discard a failed merge.