Cross-Agent Session Reconciliation Prompt

This prompt is designed for orchestration engineers who operate agent graphs where a single user session fans out to multiple specialized agents running in parallel. The core job-to-be-done is merging the structured outputs from these agents into a single, coherent result set before returning it to the user or writing to a system of record. The ideal user is an AI platform engineer or backend developer who has already solved agent specialization and handoff but now faces the reconciliation problem: two agents returned overlapping lists, one agent's finding contradicts another's, or the combined payload exceeds the user's context window. This prompt sits at the critical integration point between parallel agent execution and the final response layer.

Use this prompt when your agent topology follows a fan-out/fan-in pattern: a coordinator dispatches the same session context to multiple agents, each with a distinct capability or data source, and you need a single deduplicated, conflict-resolved output. The prompt expects structured inputs from each agent, including their output payload, a confidence score, and the specific sub-task they were assigned. It is appropriate for batch-style reconciliation where all agent outputs are available before merging begins. The output should be a single reconciled result with explicit conflict annotations, source attribution for each merged item, and a confidence-weighted resolution for any contradictory findings. Wire this into your agent graph as a post-execution merge node that runs after all parallel agents complete but before the final response formatter.

Do not use this prompt for real-time streaming reconciliation where partial results must be merged incrementally as agents respond—it assumes all inputs are available upfront. Do not use it to merge outputs from agents that operated on different sessions or user requests; cross-session deduplication requires a persistent workstream registry and fingerprinting approach covered in the Duplicate Task Detection Prompt Template. Do not use this prompt when the output schemas across agents are fundamentally incompatible without a transformation layer—if one agent returns a list of entities and another returns a narrative summary, you need an upstream normalization step before reconciliation. Finally, in high-stakes domains where contradictory findings could cause harm (clinical, legal, financial), always route the reconciled output through human review rather than treating the prompt's confidence-weighted resolution as final.

This prompt template is designed to be pasted directly into your orchestration layer. It expects structured session data from multiple agents that have operated on the same task or user session. The prompt instructs the model to identify overlapping, duplicate, and contradictory results, then produce a deduplicated, reconciled output. Replace every square-bracket placeholder with live data from your agent execution context before sending the request. The template is model-agnostic but assumes a model capable of structured JSON output and reasoning over multiple input blocks.

textCopy
You are a session reconciliation engine. Your job is to merge the outputs from multiple agents that worked on the same session, remove duplicates, resolve contradictions, and produce a single reconciled result set.

## INPUTS

### SESSION CONTEXT
[SESSION_CONTEXT]

### AGENT OUTPUTS
[AGENT_OUTPUTS]

### OUTPUT SCHEMA
You must return a valid JSON object conforming to this schema:
[OUTPUT_SCHEMA]

### CONSTRAINTS
- Do not drop any unique, non-duplicate information from any agent.
- When two agents report the same fact with different values, flag the conflict in a `conflicts` array. Do not silently pick one.
- When two agents report semantically equivalent information, merge them into a single entry and record both agent IDs in a `sources` field.
- If an agent output is incomplete or low-confidence, note this in a `quality_flags` array per entry.
- If the session context contains a user intent or goal, verify that the reconciled output still addresses it.
- Do not fabricate any data not present in the agent outputs.

### CONFLICT RESOLUTION RULES
- If a conflict exists and one agent has higher confidence or more recent data, prefer that agent's value but still record the conflict.
- If confidence is equal and no tiebreaker exists, mark the field as `unresolved` and include both values.
- If a conflict involves a safety-critical or regulated domain field, escalate it in an `escalation_required` array rather than resolving it.

### EXAMPLES
[EXAMPLES]

### RISK LEVEL
[RISK_LEVEL]

## OUTPUT
Return only the JSON object. No other text.

Adaptation notes: The [AGENT_OUTPUTS] placeholder should receive a structured array of agent outputs, each tagged with an agent ID, timestamp, and confidence score. The [OUTPUT_SCHEMA] should define the expected shape of the reconciled result, including fields for merged_results, conflicts, quality_flags, and escalation_required. The [EXAMPLES] placeholder should contain one or two few-shot examples showing correct reconciliation behavior, especially for conflict cases. The [RISK_LEVEL] placeholder should be set to high, medium, or low to adjust the model's caution. For high-risk domains, always route the output through a human review step before it reaches downstream systems. Validate the output against the schema immediately after generation, and if validation fails, retry with the error message appended to the prompt.

The Cross-Agent Session Reconciliation Prompt is designed to be invoked as a post-processing step after a set of parallel agents has completed execution on the same logical session. In an agent graph, this prompt acts as a reducer node: it receives a structured payload containing the original user request, the session identifier, and the raw outputs from all participating agents. The orchestration layer should enforce a strict contract where all agent outputs are collected, their execution statuses are verified, and a timeout threshold is applied before the reconciliation node is triggered. This prevents the prompt from running on incomplete data, which is the most common cause of false-negative conflict misses.

Wire this prompt into your application by building a reconciliation service that validates inputs before the model call. The service must confirm that the [SESSION_ID] matches across all agent outputs, that each output includes a [CONFIDENCE_SCORE] and [AGENT_ROLE] field, and that the total payload size does not exceed the model's context window. If the combined agent outputs exceed the context limit, implement a pre-processing step that summarizes or truncates low-confidence results before calling the reconciliation prompt. After the model returns the reconciled output, run a schema validator against the expected [OUTPUT_SCHEMA] to catch malformed JSON, missing required fields, or type mismatches. For high-stakes domains such as healthcare or finance, insert a human review step before the reconciled output is written to the system of record. Log the raw agent outputs, the reconciliation prompt request, the model response, and the validation result for auditability.

Common failure modes in production include: the model failing to surface a genuine conflict because it was buried in a long output, the model fabricating a merge when agents actually agreed, and the model dropping a unique insight from a low-confidence agent. Mitigate these by implementing a post-reconciliation diff check that compares the reconciled output against the union of all agent outputs to detect dropped information. Use an LLM judge with a conflict detection recall eval to measure whether the reconciliation prompt caught all known conflicts in a golden test set. For retry logic, if the output fails schema validation, re-invoke the prompt once with the validation error message appended to the [CONSTRAINTS] field. If it fails again, escalate to a human operator with the raw agent outputs and both failed reconciliation attempts. Avoid using this prompt for real-time, latency-sensitive applications; it is best suited for batch or near-real-time reconciliation where correctness is more important than speed.