Agent Memory Refresh and State Reconciliation Prompt

This prompt is designed for a specific architectural moment: the agent has been away from its session and must now re-enter. The break could be caused by a deployment restart, a context-window overflow that forced an eviction, or a human-in-the-loop pause that lasted long enough for the environment to change. In all these cases, the agent holds a stored state object from a prior checkpoint, but it cannot trust that memory blindly. The job-to-be-done is to compare that stored state against fresh observations from the environment, flag contradictions, mark stale data, and produce a single reconciled state object that the agent can use as its new source of truth before resuming autonomous execution.

The ideal user is an agent runtime developer or AI engineer who is building a state-management layer for autonomous or semi-autonomous agents. You should use this prompt when your agent runtime detects a session boundary and needs to rebuild a trustworthy internal state. The required context includes the stored state object, a set of fresh observations from the environment, and a schema that defines what a valid reconciled state looks like. The prompt expects the model to act as a skeptical auditor, not a trusting summarizer. It must actively look for contradictions between memory and evidence, and it must never silently carry forward a stale field just because it was present in the stored state.

Do not use this prompt for real-time state updates during active execution. When an agent is mid-workflow and a tool returns a result, that update belongs to a step-verification or postcondition-validation prompt, not a full memory reconciliation. This prompt is also a poor fit for simple conversational state tracking, where a turn-level summary is sufficient and there is no external environment to reconcile against. For those cases, use a multi-turn session state summary prompt instead. Finally, avoid this prompt when the stored state is known to be fully trustworthy and the environment is static; the reconciliation overhead adds latency and token cost without benefit.

Before deploying this prompt, ensure your agent runtime can reliably detect session boundaries and trigger the reconciliation workflow. A common failure mode is calling this prompt too frequently, which wastes tokens and can introduce instability if the model overcorrects minor discrepancies. Another failure mode is calling it too late, after the agent has already acted on stale state and caused side effects that are expensive to unwind. Wire the prompt into a state-machine guard that fires on session start, not on every turn. Pair it with a state integrity validation prompt to verify the reconciled output before the agent resumes execution.

The following prompt template is designed to be dropped into an agent's state reconciliation step. It forces the model to compare a previously stored state snapshot against new evidence, producing an updated state object with explicit conflict markers and stale-data flags. Use this when an agent returns to a session after a gap, when a tool call returns results that contradict prior assumptions, or when a human operator provides corrective feedback that invalidates parts of the stored state.

textCopy
You are an agent state reconciliation module. Your task is to compare the [STORED_STATE] against [NEW_OBSERVATIONS] and produce an updated state object.

[STORED_STATE] contains the agent's last known representation of the session, including completed tasks, in-progress items, pending actions, and any assumptions or preferences recorded during prior turns.

[NEW_OBSERVATIONS] contains fresh evidence gathered since the state was last saved. This may include tool call results, user corrections, sensor readings, or outputs from other agents.

[CONFLICT_RESOLUTION_POLICY] defines how to handle contradictions:
- If [NEW_OBSERVATIONS] directly contradicts a field in [STORED_STATE], prefer the new observation unless [CONFLICT_RESOLUTION_POLICY] specifies otherwise.
- Flag all overridden fields with a `conflict_resolved` marker and record both the old value and the new value.
- If a field in [STORED_STATE] cannot be verified by [NEW_OBSERVATIONS] and is older than [STALENESS_THRESHOLD], mark it as `stale` and reduce its confidence score.

[OUTPUT_SCHEMA] requires the following structure:
{
  "updated_state": {
    "completed_tasks": [
      {
        "task_id": "string",
        "status": "completed",
        "completed_at": "ISO8601 timestamp",
        "evidence_ref": "reference to supporting observation"
      }
    ],
    "in_progress_tasks": [
      {
        "task_id": "string",
        "status": "in_progress",
        "last_known_step": "string",
        "confidence": 0.0-1.0,
        "stale": false
      }
    ],
    "pending_tasks": [
      {
        "task_id": "string",
        "status": "pending",
        "blockers": ["string"],
        "stale": false
      }
    ],
    "assumptions": [
      {
        "field": "string",
        "value": "any",
        "confidence": 0.0-1.0,
        "stale": false,
        "conflict_resolved": false,
        "previous_value": null
      }
    ],
    "session_metadata": {
      "last_updated": "ISO8601 timestamp",
      "reconciliation_timestamp": "ISO8601 timestamp",
      "observation_sources": ["string"]
    }
  },
  "conflicts": [
    {
      "field_path": "string",
      "old_value": "any",
      "new_value": "any",
      "resolution": "string explaining why new value was chosen",
      "confidence_after_resolution": 0.0-1.0
    }
  ],
  "stale_fields": [
    {
      "field_path": "string",
      "last_verified": "ISO8601 timestamp or null",
      "reason": "string explaining why this field could not be verified"
    }
  ],
  "unresolved_items": [
    {
      "item": "string",
      "issue": "string describing what remains uncertain",
      "recommended_action": "re-observe | ask_user | escalate | accept_uncertainty"
    }
  ]
}

[CONSTRAINTS]:
- Do not invent observations. Only use evidence present in [NEW_OBSERVATIONS].
- If a task appears in both [STORED_STATE] and [NEW_OBSERVATIONS] with different statuses, treat it as a conflict.
- If [NEW_OBSERVATIONS] is empty or contains only a timestamp update, do not mark fields as stale unless they exceed [STALENESS_THRESHOLD].
- Preserve all task IDs from [STORED_STATE] unless [NEW_OBSERVATIONS] proves they are invalid.
- Set confidence scores below 0.5 for any field that relies on a single unverified observation.

[EXAMPLES]:
[FEW_SHOT_EXAMPLES]

Produce only the JSON output matching [OUTPUT_SCHEMA]. Do not include explanatory text outside the JSON object.

To adapt this template, replace each square-bracket placeholder with concrete values from your agent runtime. [STORED_STATE] should be the serialized state object from your last checkpoint. [NEW_OBSERVATIONS] should be a structured dump of recent tool results, user messages, or sensor data. [CONFLICT_RESOLUTION_POLICY] can be a short rule like "prefer user corrections over tool output" or "prefer the most recent timestamp." [STALENESS_THRESHOLD] should be a duration string such as "5 minutes" or "1 hour" depending on how rapidly your domain state decays. [FEW_SHOT_EXAMPLES] should contain one or two worked examples showing a conflict and a stale-field scenario so the model internalizes the expected behavior before processing the real input.

Before deploying this prompt into a production agent loop, validate the output against the schema using a JSON schema validator. Run eval cases where you deliberately inject contradictions between [STORED_STATE] and [NEW_OBSERVATIONS] and confirm that the conflicts array captures every injected discrepancy. Test edge cases: empty observations, completely stale state, identical state and observations, and malformed input. If the agent operates in a domain where incorrect state could cause financial, safety, or compliance harm, route the unresolved_items array to a human reviewer before the agent acts on the reconciled state. Do not let the agent execute irreversible actions based on fields marked with confidence below your operational threshold.

This prompt is not a standalone chat instruction—it is a state reconciliation module that must be integrated into an agent runtime's memory management loop. The harness is responsible for providing the prompt with a complete snapshot of the agent's stored state, the new observations that triggered the refresh, and a strict output schema. The prompt's job is to produce a reconciled state object with conflict flags and stale-data markers; the harness's job is to validate that output, decide whether to accept or retry, and safely apply the update to the agent's working memory. Without a disciplined harness, a malformed reconciliation output can corrupt the agent's state and cascade into downstream planning failures.

Wire this prompt into the agent's state refresh pipeline as a dedicated step that runs when the agent returns to a session after a gap, when new observations contradict stored beliefs, or when a configurable staleness threshold is exceeded. The harness should assemble the prompt inputs from two sources: the agent's current state store (serialized as structured JSON) and the fresh observation payload (from tool outputs, user input, or environment sensors). Include a [RECONCILIATION_TIMESTAMP] and [SESSION_ID] in the prompt context to anchor the output in time and enable audit trail correlation. After calling the model, validate the output against a strict schema that requires: a reconciled_state object, a conflicts array with field, stored_value, observed_value, and resolution entries, and a stale_fields array marking data that was not refreshed. Reject any output that is missing these sections or contains fields not present in the input schemas.

Implement a two-stage validation harness before the reconciled state is committed. First, run structural validation: check that the output is valid JSON, that all required keys are present, and that no hallucinated fields appear. Second, run semantic validation: verify that every conflict entry references real fields from the input state or observations, that resolutions are one of the allowed enum values (accept_observed, retain_stored, flag_for_review, merge), and that stale-field markers only reference fields that existed in the stored state but were absent from observations. If validation fails, retry the prompt once with the validation errors appended to the [CONSTRAINTS] section. If the second attempt also fails, log the failure, preserve the previous state unchanged, and escalate to a human reviewer or a fallback conservative merge strategy. For high-risk domains such as healthcare or finance, always require human approval before applying any reconciliation that includes flag_for_review conflicts or modifies fields marked as immutable in the state schema.

Choose a model with strong structured output capabilities and low latency for this prompt, as state reconciliation is often on the critical path for agent responsiveness. GPT-4o and Claude 3.5 Sonnet are good defaults; avoid smaller models that may drop conflict entries or hallucinate field names. Enable structured output mode or JSON mode with the reconciliation schema provided as a tool or response format. Set temperature=0 to maximize determinism—reconciliation should not be creative. Implement a timeout of 10–15 seconds with a fallback to a rule-based merge (e.g., observed values overwrite stored values for non-immutable fields) if the model call fails. Log every reconciliation attempt with the input state hash, observation hash, output state hash, validation result, and latency for observability and regression testing. This log becomes your golden dataset for evaluating prompt changes and detecting reconciliation drift over time.