Conversation State Reconciliation Prompt for Open Items

This prompt is for AI engineering teams whose production assistants maintain an explicit, structured state model of open items—questions, tasks, and commitments—alongside the raw conversation transcript. The core job-to-be-done is detecting and diagnosing state drift: the condition where the assistant's internal state model has fallen out of sync with what actually happened in the conversation. For example, the state model might still list a question as 'unanswered' when the user provided an answer three turns ago, or it might mark a task as 'resolved' when the assistant only acknowledged it but never completed it. This reconciliation step is a critical control plane operation, not a user-facing response.

The ideal user is a backend AI engineer or technical lead building a stateful copilot, support agent, or task-oriented assistant. You should use this prompt when your system explicitly tracks open items in a structured format (JSON, a database, or a state machine) and you need a scheduled or triggered audit to compare that state against the raw transcript. This is not a prompt for generating a user-facing summary. It is an internal diagnostic that produces a machine-readable reconciliation report. Required context includes the full conversation transcript and the assistant's current internal state object for open items. The prompt is designed to be run by an orchestration layer, not directly by an end-user.

Do not use this prompt as a replacement for a deterministic state machine. If your open-item tracking can be handled with explicit code—such as a finite state machine that transitions on specific user intents or API calls—that is always more reliable. This prompt is for the inevitable gaps where natural language complexity defeats deterministic rules: implicit resolutions, sarcasm, topic shifts that obsolete a question without answering it, or user corrections that ripple through multiple pending items. The output is a reconciliation report that your system should use to patch its state, not a final answer to show the user. Always log the reconciliation diff before applying it, and in high-stakes domains like healthcare or finance, require human review of any state mutation that would close or alter a critical item.

This prompt template is designed to be injected into a reconciliation step within your state management middleware. It compares a structured representation of what the system believes is pending against the ground truth of the conversation transcript. The core job is to detect two failure modes: a resolved item still marked as open, or an open item that was silently dropped from the state model. Use this before generating any user-facing summary or handoff to ensure the system's memory is accurate.

codeCopy
You are a state reconciliation auditor. Your task is to compare the assistant's internal open-item state against the actual conversation transcript and produce a structured reconciliation report.

## INTERNAL OPEN-ITEM STATE
This is the list of open questions, tasks, and commitments the system currently believes are unresolved.
[OPEN_ITEM_STATE]

## CONVERSATION TRANSCRIPT
This is the full conversation transcript, including all user and assistant turns.
[TRANSCRIPT]

## INSTRUCTIONS
1. For each item in the INTERNAL OPEN-ITEM STATE, determine if it has been resolved in the CONVERSATION TRANSCRIPT. An item is resolved if the user confirmed satisfaction, the assistant provided a complete answer that the user acknowledged, or the task was explicitly completed.
2. Scan the CONVERSATION TRANSCRIPT for any questions, tasks, or commitments that are unresolved but are NOT present in the INTERNAL OPEN-ITEM STATE. These are "missed items."
3. For each missed item, identify the turn number where the item originated and the reason it should be considered open.
4. Do not flag rhetorical questions, social pleasantries, or statements where the user explicitly withdrew the request.

## OUTPUT SCHEMA
Return a valid JSON object with the following structure:
{
  "reconciliation_report": {
    "state_items_reviewed": [
      {
        "item_id": "string",
        "original_description": "string",
        "status_in_transcript": "resolved | still_open | cannot_determine",
        "resolution_evidence": "string or null",
        "correction_required": "mark_resolved | keep_open | flag_for_review"
      }
    ],
    "missed_items": [
      {
        "description": "string",
        "originating_turn": integer,
        "reason_open": "string",
        "severity": "blocking | high | medium | low"
      }
    ],
    "drift_detected": boolean,
    "summary": "string"
  }
}

## CONSTRAINTS
- Only mark an item as resolved if there is clear, explicit evidence in the transcript.
- If evidence is ambiguous, set status to "cannot_determine" and correction_required to "flag_for_review."
- Do not invent items. Only report missed items that have a clear basis in the transcript.
- If no drift is detected, drift_detected must be false and missed_items must be an empty array.

To adapt this template, replace [OPEN_ITEM_STATE] with a JSON-serialized array of your system's pending items, each with a unique item_id and original_description. Replace [TRANSCRIPT] with the full conversation text, ideally with turn numbers prefixed (e.g., [T1] User: ...). The output schema is designed for direct consumption by your state repair logic: iterate state_items_reviewed to apply corrections, and insert missed_items into your tracking system. For high-stakes domains like healthcare or finance, route any report with drift_detected: true or severity: blocking to a human review queue before mutating state.

The reconciliation prompt is not a standalone chat interaction—it is a batch comparison job that should run as part of a state management pipeline. Wire it into your application as a scheduled or event-driven check that fires after significant conversation turns, before session closeout, or when a state-change event is logged. The prompt expects two structured inputs: the current internal state object (your system's model of open items) and the raw conversation transcript. These must be formatted consistently, with turn-level timestamps or IDs that allow the model to reference specific locations in the transcript. The output is a reconciliation report with corrections—your application must parse this report and apply state mutations programmatically, not just display it to a user.

Build a validation layer around the reconciliation output before mutating state. The prompt's output schema should include a list of corrections, each with an action type (mark_resolved, mark_unresolved, add_missing, remove_stale), the affected item ID, and a citation to the transcript turn that justifies the correction. Your harness must verify that every cited turn ID exists in the input transcript, that no duplicate corrections target the same item, and that the proposed state transitions are valid (e.g., you cannot mark an item as resolved if it was never open). For high-stakes workflows—support tickets, healthcare, legal—add a human review gate: if the reconciliation report changes more than N items or flags a severity-1 discrepancy, queue the report for manual approval before applying mutations. Log every reconciliation run with input hashes, output diffs, and reviewer decisions for auditability.

Model choice matters here. This prompt requires strong instruction-following and structured output reliability. Use a model with native JSON mode or function-calling support, and set temperature=0 to minimize hallucinated corrections. If your state object is large, consider chunking: reconcile one category of open items at a time (e.g., unanswered questions separately from deferred tasks) to stay within reliable context windows. Implement a retry loop with a maximum of 2 attempts: if the output fails schema validation, feed the validation errors back into a retry prompt with the original inputs. If retries are exhausted, log the failure and escalate to a human operator—never silently apply a malformed reconciliation. Finally, instrument the pipeline with metrics: reconciliation frequency, correction count distribution, human review escalation rate, and time-to-resolution for detected drift. These metrics will tell you whether your state tracking logic needs improvement upstream, before the reconciliation prompt becomes a permanent crutch.