Concurrent Agent Observation Merge Prompt

This prompt is for agent-framework builders who need to reconcile conflicting observations from multiple concurrent agent actions into a single, consistent world model. The core job-to-be-done is taking a set of sensor reads, tool outputs, or state snapshots that may disagree—due to race conditions, clock skew, or partial failures—and producing a merged observation that downstream planning and action agents can trust. The ideal user is an AI reliability engineer or platform developer building a multi-agent harness where agents act in parallel and their observations must be consolidated before the next planning step. Required context includes the raw observations with their timestamps, the agent IDs that produced them, and the schema of the world model being updated.

Do not use this prompt when observations are strictly sequential or when a single authoritative source of truth exists that makes merging unnecessary. It is also the wrong tool for merging agent plans or goals—those require plan-merge or goal-conflict resolution prompts, not observation reconciliation. This prompt assumes the observations are about the same target entity or state variable; if the observations are about entirely disjoint parts of the system, a simple union is sufficient and this prompt adds unnecessary complexity. Finally, if the conflict involves business-rule violations that require human judgment (e.g., a medical device reading that contradicts a safety threshold), escalate to a human-in-the-loop workflow rather than relying on an automated merge.

Before wiring this prompt into your agent loop, ensure you have a clear conflict-resolution policy defined: last-writer-wins, majority-vote, trust-weighted, or timestamp-ordered. The prompt template expects you to supply that policy as a constraint. You should also define the output schema for the merged observation so that downstream consumers receive a predictable structure. Start by instrumenting your agent harness to capture observation metadata—agent ID, timestamp, confidence score, and source type—before feeding it into this merge step.

This prompt template is designed for agent-framework builders who need to reconcile conflicting sensor reads, tool outputs, or state observations from concurrent agent actions. It accepts a list of observations with timestamps and agent identifiers, then produces a merged world model with explicit conflict resolution notes. Use this when multiple agents are observing the same environment or resource simultaneously and you need a single source of truth before the next planning step.

textCopy
You are an observation merge engine for a multi-agent system. Your job is to reconcile concurrent observations from multiple agents into a single consistent world model.

## INPUT
You will receive a list of observations. Each observation includes:
- agent_id: which agent made the observation
- timestamp: when the observation was recorded (ISO 8601)
- observation_type: the kind of observation (e.g., sensor_read, tool_output, state_query)
- target: what was observed (resource ID, sensor name, API endpoint)
- value: the observed value or payload
- confidence: a score from 0.0 to 1.0 indicating the agent's confidence in this observation

[OBSERVATIONS]

## OUTPUT_SCHEMA
Return a valid JSON object with this structure:
{
  "world_model": {
    "<target>": {
      "resolved_value": <the merged or selected value>,
      "resolution_method": "latest_wins" | "highest_confidence" | "majority_vote" | "manual_merge" | "no_conflict",
      "contributing_observations": [<list of observation indices that contributed>],
      "discarded_observations": [<list of observation indices that were discarded>],
      "conflict_note": "<explanation if there was a conflict, otherwise null>"
    }
  },
  "unresolved_conflicts": [
    {
      "target": "<target with unresolved conflict>",
      "conflicting_values": [<list of conflicting values>],
      "reason": "<why automatic resolution was not possible>"
    }
  ],
  "merge_summary": "<one-sentence summary of what was merged and any issues>"
}

## CONFLICT RESOLUTION RULES
1. If all observations for a target agree, use the value with no conflict (resolution_method: "no_conflict").
2. If timestamps differ and values conflict, prefer the latest timestamp unless the older observation has significantly higher confidence (difference > 0.2).
3. If timestamps are within [TIME_WINDOW_MS] milliseconds of each other, use highest confidence.
4. If three or more agents observed the same target and a majority agree, use majority vote.
5. If you cannot resolve a conflict automatically, place it in unresolved_conflicts.
6. Never fabricate values. If all observations are low confidence (< [CONFIDENCE_THRESHOLD]), flag as unresolved.

## CONSTRAINTS
- Preserve all original observation indices in contributing_observations and discarded_observations.
- Do not drop observations silently. Every observation must appear in either contributing or discarded for its target.
- If an observation's target does not appear in any other observation, include it with resolution_method "no_conflict".
- Timestamp ordering must be monotonic. If you detect a clock-skew anomaly, note it in conflict_note.

To adapt this template, replace [OBSERVATIONS] with your serialized observation list, set [TIME_WINDOW_MS] to your acceptable concurrency window (e.g., 500 for half a second), and set [CONFIDENCE_THRESHOLD] to your minimum acceptable confidence (e.g., 0.3). For production use, validate the output JSON against the schema before accepting the merged world model. If unresolved_conflicts is non-empty, route to a human operator or a higher-capability model for final arbitration. Always log the full merge decision for auditability, especially when observations are discarded.

The Concurrent Agent Observation Merge Prompt is not a standalone chat interaction. It is a recovery and reconciliation step inside an agent harness that executes multiple actions in parallel. The harness dispatches several tool calls or sensor reads concurrently, collects their outputs, and then invokes this prompt when the observations conflict, overlap, or arrive out of order. The prompt's job is to produce a single consistent world-model update that the agent can act on in its next planning cycle. This means the harness must provide structured inputs: the list of observations, each with a timestamp, source agent or tool identifier, and the raw output payload. Without this structured envelope, the model cannot reliably resolve conflicts.

Wiring pattern. The typical call flow is: (1) The orchestrator dispatches N concurrent actions and awaits their results with a configurable timeout. (2) On timeout or completion, the harness collects all successful and partial responses into an observations array. (3) If any two observations disagree on a shared state key, or if timestamps are out of order, the harness invokes this merge prompt. (4) The prompt returns a merged state object and a conflict-resolution log. (5) The harness validates the output against a schema that requires merged_state, conflicts_resolved, and unresolved_conflicts fields. (6) If unresolved_conflicts is non-empty, the harness either escalates to a human or invokes a secondary clarification tool before updating the agent's world model. Do not skip step 5: an unvalidated merge can silently corrupt downstream planning.

Model choice and latency budget. This prompt requires strong reasoning over structured data and temporal ordering, not creative generation. Prefer models with strong JSON-mode support and low latency for this recovery step—Claude 3.5 Sonnet, GPT-4o, or Gemini 1.5 Pro are appropriate. Set a tight timeout (under 5 seconds) because this merge blocks the agent's next action. If the model times out, fall back to a deterministic merge rule (e.g., last-writer-wins by timestamp) and log the fallback for later review. Never retry this prompt more than twice; a merge that fails repeatedly indicates a deeper concurrency bug in the agent's action design, not a transient model error.

Eval harness and regression tests. Before deploying, build a test suite with known conflict scenarios: timestamp inversion (observation B arrives with an earlier timestamp than A), contradictory sensor reads (thermometer A says 72°F, thermometer B says 68°F), partial failures (one observation is an error message, not data), and duplicate observations (two agents report the same event). For each test case, assert that conflicts_resolved contains the expected resolution and that merged_state preserves all non-conflicting keys. Run these tests on every prompt or model version change. In production, log every merge invocation with the input observations, the model's output, and the validation result. This trace is essential for debugging agent behavior regressions.

What to avoid. Do not use this prompt for simple aggregation where no conflict exists—a deterministic merge function is cheaper and faster. Do not pass raw, unlabeled observation text; the model needs structured fields to compare values reliably. Do not allow the merged state to silently drop observations that failed to reconcile; the unresolved_conflicts field must surface ambiguity so the harness can decide whether to escalate, re-query, or proceed with a flagged uncertainty. Finally, ensure the harness enforces a maximum observation count (we recommend 20) to avoid context-window overflow when many concurrent actions complete simultaneously.