Handoff Context Merging Prompt for Parallel Agent Results

This prompt is designed for the critical merge step in fan-out/fan-in agent architectures. After dispatching work to multiple specialized agents—such as a legal researcher, a financial analyst, and a contract reviewer—you receive raw, unstructured, and potentially conflicting outputs. The job-to-be-done is to fuse these disparate results into a single, structured payload that a downstream synthesis agent or a final reporting agent can consume without confusion, hallucination, or information loss. The ideal user is an orchestration engineer or AI platform builder who has already implemented parallel agent execution and now needs a reliable, programmatic handoff layer rather than an ad-hoc string concatenation.

Use this prompt when you have two or more agent outputs that overlap in subject matter, may contain contradictory claims, or use different terminology for the same entities. The prompt requires structured inputs: a list of agent outputs with source labels, an optional shared context or original user query, and a defined output schema. It is not suitable for merging outputs from agents that operated on completely unrelated tasks, as the forced reconciliation would create false connections. It is also not a replacement for upstream agent specialization—if your agents are producing wildly divergent formats or low-quality outputs, fix the source agents first. The prompt includes explicit instructions to preserve divergent perspectives when reconciliation is impossible, preventing the common failure mode of forcing a false consensus that hides critical disagreements from downstream agents or human reviewers.

Before integrating this prompt into your pipeline, ensure you have a validation layer that checks the merged output against the expected schema and verifies that no source agent's unique findings were silently dropped. In high-stakes domains like legal, financial, or clinical workflows, always route the merged context through a human review step before it reaches a decision-making agent. The next section provides the copy-ready prompt template with placeholders you can adapt to your specific agent topology and output schema.

This template is designed to be pasted directly into your orchestration layer. It accepts structured outputs from multiple agents that have worked on the same task concurrently, then produces a merged context document. The prompt resolves factual conflicts, deduplicates overlapping findings, and explicitly preserves divergent perspectives when reconciliation is impossible. Replace every [PLACEHOLDER] with values from your agent framework before execution.

textCopy
You are a context merging engine for a multi-agent orchestration system. Your task is to combine the outputs of [NUMBER] parallel agents into a single, coherent context document for a downstream agent or human reviewer.

## INPUTS
You will receive the following inputs:
- **Original Task Description:** [TASK_DESCRIPTION]
- **Agent Outputs:** A list of [NUMBER] agent outputs, each with an agent identifier, confidence score, and structured result.
  ```json
  [AGENT_OUTPUTS]

• Conflict Resolution Policy: [CONFLICT_POLICY]
• Output Schema: [OUTPUT_SCHEMA]

MERGING RULES

1. Deduplication: Identify and merge findings that describe the same fact, entity, or conclusion. Keep the version with the highest confidence score and note the supporting agents.
2. Conflict Resolution: When agents disagree on a factual claim:
   • If [CONFLICT_POLICY] is "majority_vote", select the claim supported by the most agents.
   • If [CONFLICT_POLICY] is "highest_confidence", select the claim from the agent with the highest self-reported confidence.
   • If [CONFLICT_POLICY] is "escalate", do not resolve; instead, flag the conflict for human review.
3. Divergent Perspective Preservation: If agents provide complementary but non-contradictory perspectives, include all perspectives in a "Divergent Views" section. Do not force consensus where none exists.
4. Source Attribution: Every merged claim must include a source_agents array listing which agent IDs contributed to it.
5. Uncertainty Propagation: If any contributing agent expressed low confidence, propagate that uncertainty into the merged output using the confidence field and an uncertainty_notes string.

OUTPUT FORMAT

Return a single JSON object conforming to this schema:

jsonCopy
[OUTPUT_SCHEMA]

CONSTRAINTS

• Do not invent new facts not present in the agent outputs.
• Do not drop findings unless they are exact duplicates.
• If a conflict cannot be resolved per the policy, include both claims in an unresolved_conflicts array with a recommended_action field set to "human_review".
• The merged context must be self-contained and usable without referencing the original agent outputs.

Before wiring this into production, validate that [AGENT_OUTPUTS] conforms to the expected input structure. A common failure mode is passing raw agent text instead of structured JSON, which causes the merge engine to hallucinate findings. Add a pre-validation step in your harness that checks for required fields (agent_id, confidence, result) and rejects malformed inputs before they reach the model. For high-risk domains, always set [CONFLICT_POLICY] to "escalate" and route unresolved conflicts to a human review queue rather than allowing automated resolution.

This prompt sits at the convergence point of a parallel agent execution graph. After multiple specialized agents complete their work concurrently, their raw outputs flow into this merging step before any downstream agent or human reviewer receives the combined context. The implementation harness must handle variable arrival times, partial failures, and output format inconsistencies from heterogeneous agents. Treat this prompt as a reducer function in a map-reduce pattern: it consumes a list of agent result objects and produces a single merged context document that resolves conflicts, deduplicates findings, and preserves divergent perspectives when reconciliation fails.

Wire the prompt into your orchestration layer with these concrete integration points. Input assembly: collect agent outputs into a structured array where each element includes agent_id, agent_role, task_description, output, confidence_score, and timestamp. If an agent times out or errors, include a status: failed entry with the error message rather than omitting it—the merging prompt needs to know what's missing. Validation gate: before calling the LLM, validate that at least one agent produced a successful result and that all required fields exist in each agent output object. Reject the merge request if the input array is empty or all agents failed. Retry logic: wrap the LLM call in a retry loop (max 3 attempts) with exponential backoff. On retry, append the previous merge attempt's validation errors to the prompt as additional context so the model can self-correct. Output validation: parse the merged context JSON and run schema validation checks—verify that conflicts array entries include both resolution and unresolved_divergence fields, that deduplicated_findings contains unique entries, and that information_loss_log captures any dropped content with explicit reasons.

For production deployment, add these operational safeguards. Logging: capture the full prompt payload, model response, validation results, and merge latency for every invocation. Store agent output hashes to detect when identical inputs produce different merges across model versions. Human review trigger: if the merge output contains unresolved_divergence entries or the merge_confidence score falls below your threshold (start at 0.7 and calibrate from production data), route the merged context plus raw agent outputs to a human reviewer queue before downstream consumption. Model selection: use a model with strong reasoning and structured output capabilities—GPT-4o or Claude 3.5 Sonnet work well for this task. Avoid smaller models that struggle with multi-document conflict resolution. Idempotency: generate a merge request ID from the sorted agent output hashes so retrying the same merge produces the same result, preventing duplicate downstream processing.

The most common production failure is silent information loss when the model drops findings it considers redundant but aren't. Mitigate this by requiring the information_loss_log field in your output schema and running a post-merge eval that checks whether key facts from each agent's output appear in the merged result. A second failure mode is false consensus where the model resolves a genuine disagreement by picking one side and discarding the other. Your eval suite should include test cases with deliberately conflicting agent outputs and verify that unresolved_divergence entries are preserved. Start with these evals before deploying, and add regression tests whenever a merge failure reaches production.