Offline Memory Consolidation for AI Agents Across Sessions

AI agents cannot improve across sessions by relying only on temporary context in the current conversation. After a task ends, raw logs, tool responses, and user corrections may still exist, but the next conversation does not automatically inherit those lessons. Loading the entire history into every prompt consumes context and risks treating outdated conclusions as facts.

A more reliable approach separates “what happened” from “what will be useful later.” The online phase records events faithfully. The offline phase replays those records, consolidates findings, and corrects mistakes.

Human memory provides a useful analogy, but this is not an attempt to replicate biology. Live interaction resembles short-term registration: capturing events, evidence, and unresolved questions. Idle-time processing resembles consolidation: turning recurring, verified, or costly-to-relearn information into retrievable notes.

This offline process is sometimes described as “dreaming.” It does not mean generating another conversation. It means replaying task trajectories without supervision, detecting contradictions, revising rules, and writing the results back to a memory store. Computation happens between interactions so that subsequent calls can use less context, produce more accurate results, and remain easier to audit.

1. Define the Boundaries of Memory

Here, long-term memory means experience acquired through tasks and user interactions, retained across sessions, and made available later as plain text or structured records. It differs from three related mechanisms.

First, it does not modify model weights. Memory lives in external storage and can be versioned or rolled back. An incorrect note can be withdrawn without retraining the model.

Second, it is not single-session in-context learning. Temporary reasoning within a conversation applies to that session and disappears when the session ends.

Third, it is not merely a summary that replaces an earlier conversation. Summaries can lose evidence trails and make individual claims difficult to invalidate. Compression can save context space, but it should not be mistaken for long-term memory.

With these boundaries established, the system should have at least four layers:

• Raw records: Immutable records of what happened.
• Memory notes: Conclusions that have been assessed.
• Retrieval representations: Representations used to find relevant notes.
• Injected context: The small subset of memory relevant to the current task.

Offline consolidation operates across these layers, but it must never directly rewrite raw logs.

2. Keep Online Processing Focused on Capture and Tagging

During an interaction, the agent should prioritize the user’s task rather than extensive journaling. Only a limited set of information warrants immediate capture: key observations, checked facts, failed steps, explicit user preferences, and unverified hypotheses.

These can be stored as short records in an external memory directory or marked in logs as candidates for consolidation.

Tagging should be selective. Emotion and salience can increase replay frequency in biological memory; the engineering equivalent is priority, not labeling every moment as important. Useful signals include:

• A user correction.
• A successful retry after a tool error.
• A constraint mentioned repeatedly.
• A constraint whose violation could cause an irreversible action.
• An answer verified by an external result.

Small talk, repetitive progress updates, and unchecked guesses should stay out of long-term memory by default.

Deciding what will matter later is itself a prediction. Writing a rule predicts that it will be useful again. Recording a verified fact predicts that future tasks can avoid paying the same verification cost.

Each candidate memory should therefore include its scope, evidence references, confidence, and invalidation conditions. A memorable statement without an applicability boundary is difficult to evaluate when deciding whether to inject it later.

The record format need not depend on a particular product interface. Stable fields are sufficient:

id: mem-20260321-014
type: verified_fact | procedure | preference | open_question
scope: When this applies and when it does not
claim: A one-sentence conclusion
evidence: An immutable reference to the original logs
confidence: low | medium | high
expires: A time or event that invalidates the memory
status: candidate | active | superseded | rejected

3. Build a Closed Loop for Offline Consolidation

An idle-time job reads candidate records and the relevant raw logs, then performs four operations.

Replay

Replay trajectories by task rather than as disconnected chronological fragments. Check whether the recorded conclusions actually explain subsequent results.

Merge

Combine related observations into more general notes while preserving exceptions. When two notes contradict each other, do not simply keep the newest one. Return to the evidence. If the conflict cannot be resolved, mark it as an open_question.

Correct

When later tool results or user corrections contradict a note, mark the old note as superseded and identify the evidence that overturned it. Never overwrite it silently.

Prune

Remove expired, low-confidence, or long-unused entries from the active set. Archive them before deletion when an audit trail is needed.

The output remains a set of notes, not new model parameters.

Consolidation jobs should be rate-limited, interruptible, and rerunnable. Use a memory-store version as input; repeated execution against the same version should produce the same note changes. A failed offline job should not contaminate an online session.

4. Retrieve Selectively and Inject Carefully

At the start of the next session, do not place the entire memory directory into the prompt. Filter against the current task first:

• Does the scope match?
• Is the status active?
• Is the entry still valid?

Then limit the selected entries by relevance and confidence.

Injected notes should retain an explicit label identifying them as memory rather than current observations. Include evidence references so that the model or a person can review the source.

Retrieval failure should be acceptable. If nothing matches, continue without memory and add any new lessons to the candidate set after the task.

When retrieved notes conflict, prefer original evidence and newer valid notes—not an older conclusion merely because it sounds more certain.

5. Evaluate Outcomes, Not Memory Volume

The value of long-term memory lies in reducing repeated mistakes on later tasks, not in accumulating more notes.

One evaluation setup uses a sequence of tasks that require multiple queries, with correct feedback revealed only after each round. A stateless baseline reasons from scratch each time. The memory-enabled system may read only notes it previously wrote and that subsequently passed through offline consolidation.

Useful comparison metrics include:

• Accuracy or cumulative reward on later tasks.
• Average context length.
• Error recurrence rate.
• The proportion of notes later overturned.
• Performance regressions caused by irrelevant injected memories.

A single performance curve is not proof of a general capability. When the data distribution changes, notes may overfit an old database schema.

Evaluation should vary both tasks and user constraints. It should also include a control condition that deliberately provides incorrect feedback, testing whether the system turns wrong answers into persistent rules. If incorrect feedback enters memory and remains valid indefinitely, the problem is inadequate verification, not excessive memory capability.

6. Engineering Controls for Deployment

Storage

Separate raw logs from memory notes. Logs suit append-only storage; notes suit small versioned files or collections of records.

Object storage can hold archives, logging services can preserve operation histories, and relational or document databases can hold queryable notes.

In a general-purpose cloud environment such as Baidu AI Cloud, rely on general capabilities such as object storage, logging, and access control. The application should define its own memory format rather than assume that the platform provides a built-in “dreaming” interface.

Access Control

Isolate memory by tenant, user, and task domain.

Tool credentials, identity documents, and raw sensitive personal information should be excluded from notes by default. Retain only minimal necessary facts, such as whether something was verified or rejected. Reuse across users requires explicit authorization.

Consistency

Online writes should enter the candidate state. Offline jobs promote validated notes to active.

Online reads must ignore unfinished consolidation results so that sessions never receive partially updated rules.

Security

Treat memory as untrusted data. Before injecting a note, ensure that it cannot rewrite system instructions.

Notes may serve as reference facts, not higher-priority control commands. Rules that could trigger external actions require secondary confirmation or policy validation.

7. Common Failure Modes and Responses

Failure mode	Consequence	Response
Writing too much	Full-process summaries increase retrieval noise.	Retain reusable conclusions and their exceptions.
Writing too early	Guesses become established rules before the task is complete.	Keep unverified content as open_question; do not let it guide high-risk actions.
Adding without removing	Expired preferences continue to appear in prompts.	Use expiration conditions, supersession chains, and periodic replay.
Losing traceability	Notes cannot be checked against their sources.	Require evidence references before promotion to active.
Competing with online serving	Offline processing increases interactive latency.	Isolate queues, cap batch sizes, and support pausing.

8. Implement in Stages

Start with immutable logs and candidate notes so that tasks can be replayed.

Next, introduce narrowly scoped retrieval, injecting only preferences and verified facts.

Then add offline merging, conflict detection, and expiration handling.

Finally, evaluate error recurrence and context costs across multiple rounds of tasks. At every stage, it should be possible to disable memory and return to stateless behavior for comparison.

Long-term memory is not valuable because it preserves all history. Its value comes from evidence-backed predictions about future use: what is worth reading again, what must be checked again, and what is no longer valid.

Online capture, offline replay, reversible notes, and controlled injection form a closed loop. Together, they allow an agent to turn one correction into fewer repeated mistakes while keeping the origin of every lesson visible.