Tool Streaming Partial Result Merge and Conflict Resolution Prompt Template

This prompt is designed for the specific job of reconciling multiple, overlapping partial results that arrive from streaming tool calls. The ideal user is a real-time agent developer who has fanned out requests to several services—such as multiple search APIs, distributed databases, or concurrent inference endpoints—and is now receiving a stream of incremental chunks. These chunks may update, contradict, or refine earlier data. The core job-to-be-done is not simple concatenation; it is a stateful merge that produces a single, consistent, and auditable output, explicitly detecting conflicts, selecting a resolution strategy, and escalating what cannot be safely resolved.

You should use this prompt when the merge logic requires more than appending new text. Concrete triggers include: receiving a price update that conflicts with a previously streamed price, getting a status change from 'pending' to 'complete' that must overwrite the old state, or seeing two search result sets with overlapping items that need deduplication by a specific key. The required context for the prompt includes the raw, timestamped stream of partial results, the expected output schema, and a defined conflict resolution policy (e.g., 'last-write-wins', 'source-A-priority', or 'flag-and-escalate'). Without this structured context, the model cannot make consistent reconciliation decisions.

Do not use this prompt for simple chunk concatenation, such as reassembling a single streaming text response where chunks are sequential and non-overlapping. It is also the wrong tool for stateless result assembly where no reconciliation logic is required, or for single-source streaming without overlap. In those cases, a simpler assembly prompt or direct application logic is faster, cheaper, and less error-prone. Before reaching for this merge prompt, confirm that you genuinely have multiple sources, overlapping data, and the potential for conflict—otherwise, you are adding complexity and latency without benefit.

This prompt template is designed to be placed in your agent's system instructions or a dedicated merge step. It assumes the agent has already received partial results from one or more streaming tool calls and must now produce a single coherent output. The template forces the model to detect conflicts explicitly, choose a resolution strategy, validate merge consistency, and escalate unresolved conflicts rather than silently dropping data or picking an arbitrary winner.

textCopy
You are a merge-and-resolution agent. Your task is to combine multiple partial results from streaming tool calls into a single consistent output.

## INPUT
You will receive:
- A set of partial result chunks from [TOOL_NAME].
- Each chunk includes a sequence number, a timestamp, and a payload.
- Some chunks may overlap, conflict, or arrive out of order.

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "merged_result": <the reconciled output matching [OUTPUT_SCHEMA]>,
  "conflicts_detected": [
    {
      "field": "<field path>",
      "chunk_a": "<chunk_id>",
      "value_a": "<value>",
      "chunk_b": "<chunk_id>",
      "value_b": "<value>",
      "resolution_strategy": "last_write_wins | majority_vote | manual_merge | source_priority | escalation",
      "resolved_value": "<final value or null if escalated>",
      "rationale": "<brief explanation>"
    }
  ],
  "unresolved_conflicts": [
    {
      "field": "<field path>",
      "reason": "<why automatic resolution was not possible>",
      "recommended_action": "<what a human or upstream system should do>"
    }
  ],
  "merge_consistency_checks": {
    "no_silent_data_loss": <true | false>,
    "all_chunks_accounted_for": <true | false>,
    "schema_compliant": <true | false>,
    "issues": ["<description of any consistency problems>"]
  }
}

## CONFLICT RESOLUTION RULES
1. **last_write_wins**: Use the value from the chunk with the latest timestamp. Only valid when timestamps are reliable and monotonic.
2. **majority_vote**: Use the value that appears in the majority of chunks. Requires at least [MIN_CHUNKS_FOR_VOTE] chunks.
3. **source_priority**: Prefer values from chunks with higher priority sources as defined in [SOURCE_PRIORITY_MAP].
4. **manual_merge**: Combine non-overlapping parts of conflicting values when possible. Document the merge logic.
5. **escalation**: When no automatic strategy is safe, escalate the conflict in `unresolved_conflicts` and set the field to `null` in `merged_result`.

## CONSTRAINTS
- Never silently drop data from any chunk. Every chunk must be accounted for in `merge_consistency_checks`.
- Do not fabricate values to resolve conflicts. If you cannot determine the correct value, escalate.
- Validate that `merged_result` conforms to [OUTPUT_SCHEMA] before returning.
- If [RISK_LEVEL] is "high", escalate all conflicts regardless of confidence.
- If chunks contain contradictory facts that affect downstream safety or correctness, escalate even if a technical merge is possible.

## EXAMPLES
[EXAMPLES]

## TOOLS AVAILABLE
[TOOLS]

## CONTEXT
[CONTEXT]

Adaptation guidance: Replace [TOOL_NAME] with the specific streaming tool. Define [OUTPUT_SCHEMA] as a strict JSON Schema or TypeScript interface. Set [MIN_CHUNKS_FOR_VOTE] based on your fan-out width. Provide [SOURCE_PRIORITY_MAP] as an ordered list of source identifiers. Populate [EXAMPLES] with 2-3 real merge scenarios, including at least one that requires escalation. Set [RISK_LEVEL] to "high" for regulated, financial, or clinical workflows to force human review on all conflicts. Wire [TOOLS] with any helper functions for schema validation or timestamp comparison. Use [CONTEXT] to inject domain-specific merge rules. After pasting this prompt, run it against your eval suite described in the Testing and Evaluation section before deploying to production.

This prompt is designed to sit inside a streaming tool orchestrator—the application component that receives partial results from multiple concurrent or sequential tool calls and must assemble a coherent final output. The orchestrator should invoke this prompt only when it detects overlapping or conflicting partial results. Do not call it on every chunk; that burns tokens and adds latency. Instead, buffer partial results, track which tool produced each chunk and at what timestamp, and trigger the merge prompt when the buffer contains results that reference the same entity, field, or claim with divergent values. The prompt expects structured input: a list of partial results with source identifiers, timestamps, confidence scores if available, and the specific conflicting fields. If your tools don't produce confidence scores, omit that field—the prompt will still work but will rely more heavily on timestamp freshness and source priority rules you define in [CONSTRAINTS].

Validation and retry loop. After the prompt returns a merged result, validate the output against a schema that requires: (1) a resolved_fields object containing the merged values, (2) a conflicts array listing any conflicts that could not be resolved, (3) a merge_strategy field explaining which rule was applied (e.g., latest_wins, source_priority, confidence_weighted, manual_escalation), and (4) a data_loss_risk boolean. If data_loss_risk is true or the conflicts array is non-empty, route the output to a human review queue or a secondary verification prompt. If validation fails—missing fields, malformed JSON, or a merge_strategy that doesn't match your allowed set—retry once with the validation error appended to [CONSTRAINTS]. After two failures, log the raw partial results and the failed merge attempts, then escalate to an on-call engineer. Never silently drop partial results; always persist the raw chunks before merging so you can replay the merge if the prompt produces a bad output.

Model choice and latency budget. This prompt is reasoning-heavy: it must compare fields, detect contradictions, apply resolution rules, and explain its decisions. Use a model with strong structured output and reasoning capabilities (e.g., Claude 3.5 Sonnet, GPT-4o). Avoid smaller or faster models here—incorrect conflict resolution causes silent data corruption that is hard to detect downstream. Set a timeout of 5–10 seconds for the merge call. If the model doesn't respond in time, fall back to a deterministic merge rule (e.g., latest_wins by timestamp) and flag the result for async review. For streaming applications where latency is critical, consider running the merge prompt as a non-blocking sidecar: emit the deterministic merge immediately to the user, then correct it if the prompt returns a different resolution within a short window.

Observability and audit. Log every merge invocation with: the input partial results (hashed if they contain sensitive data), the prompt version, the model used, the output merge_strategy, the number of resolved and unresolved conflicts, and the data_loss_risk flag. Emit a metric for merge latency and conflict rate. If the conflict rate spikes above a threshold (e.g., >10% of merges have unresolved conflicts), trigger an alert—this usually indicates a tool contract change, a schema drift, or a new failure mode in one of your streaming tools. Store merge decisions in an append-only log so you can replay and audit them. For regulated domains, require human approval on any merge where data_loss_risk is true or where the merged output will be persisted to a system of record.

What to avoid. Do not use this prompt to merge results from more than 5–6 partial chunks at once; the context window gets noisy and the model may drop fields. If you have many partial results, pre-group them by entity or field before invoking the prompt. Do not pass raw tool outputs directly—strip irrelevant fields and normalize timestamps to a consistent format before building the prompt input. Do not skip the data_loss_risk check in your harness; it is the single most important signal for catching silent merge failures. Finally, do not treat this prompt as a one-time fix. As your tool ecosystem evolves, update [CONSTRAINTS] with new resolution rules and add regression test cases for each new conflict pattern you discover in production.