Long-Term Memory Degradation in Long-Running AI Agents: Sleep-Inspired Consolidation

Long-running agents are often slowed down not by a single inference step, but by memory. At the beginning of a task, an agent can record facts such as “this repository uses a particular package manager to run tests” or “this API identifier is a string, not an integer.” These records are reasonable at the moment they are written. After a dozen or more rounds, similar experiences have been appended repeatedly with slightly different wording, mixed with old conclusions left over after the project changed its build process. As retrieval grows, the model has to choose among fragments that contradict one another, and it starts to behave as if it gets worse with use.

This is not a matter of prompts not being long enough. It is a structural problem in how memory is written: memory is local and incremental, with no global cleanup pass.

I. Why Incremental Memory Inevitably Becomes Dirty

A typical write path is: when a reusable fact appears in the current conversation or tool result, append a memory entry. This has three advantages: it is simple to implement, has low latency, and does not interrupt the current task. It also has three inevitable consequences.

First, duplication. The same constraint may be written in different sentences across different sessions. When vector retrieval returns results by similarity, several of these entries crowd into the context together, consuming window space while adding almost no information.

Second, contradiction. Environments change. Build commands, directory structures, API fields, and permission boundaries may all be adjusted midway through a project. Old entries do not expire automatically; new entries simply add another record. The model has no global view of “which one is newer” and can only guess based on how strongly something is worded.

Third, staleness and scope mismatch. An experience may hold only for one subdirectory, one environment, or one time window, yet it is written as a global rule. Later tasks are then misled by an overly broad memory, which is more dangerous than having no memory at all.

A common summary in technical discussions can be stated neutrally: agents write memory while working, and those writes are locally correct at the time. After accumulating across many sessions, the store fills with duplicates, conflicts, and invalid items. The information humans receive during the day is also fragmented and does not automatically become organized knowledge; memory consolidation during sleep is the process that replays experiences, prunes redundancy, and converts short-term traces into more stable representations. What engineering should imitate is this offline cleanup, not a catchy name for the feature.

II. What Sleep Consolidation Should Solve

Treating “dreaming” as a marketing concept is meaningless. Define it instead as an offline job between sessions, and the goal becomes clear: without occupying the user’s current interaction, review, merge, and rewrite raw experiences from a period of time so that the next session reads shorter, more consistent memory with scope and freshness information.

It should accomplish at least four things.

1. Merge duplicates. Multiple records that say the same thing should be combined into one canonical statement, retaining a source count or last-verified time rather than all original text.
2. Reconcile contradictions. When possible, determine old versus new based on time, environment identifiers, or explicit “changed” signals. When that cannot be determined, mark the item as a conflict and forbid silently choosing one side as fact.
3. Downgrade or delete invalid items. Entries that are past their validity period, bound to paths that no longer exist, or in conflict with updated project conventions should be archived rather than continuing to participate in retrieval.
4. Raise the abstraction level. Turn scattered operations into reusable rules, such as “the test entry point for this repository is defined by the project documentation; do not assume a particular package manager,” and state the applicable scope.

Consolidation is not retraining the model, and it should not rewrite raw logs the user has not authorized. It organizes the agent’s own working memory layer.

III. Suggested Memory Tiers

Do not put all information into one memory bucket. A safer design has three tiers.

The raw trajectory layer stores session summaries, key tool-call results, and explicit user corrections. It is append-only by default and is not used directly for online retrieval, or is replayed by time only during troubleshooting. It is the raw material for consolidation and the basis for auditing.

The working memory layer is the primary index for online retrieval. Entries are short and structured, with fields including at least: claim, applicable scope, evidence time, confidence, and status (active, needs verification, deprecated). Writes can still be incremental, but every entry must be updatable by later jobs.

The stable knowledge layer holds conventions that remain valid across sessions: repository standards, API invariants, and team prohibitions. Entry into this layer should require consolidation or human confirmation, updates should be infrequent, and conflict handling should be stricter.

The online path queries only working memory and stable knowledge; raw trajectories are left for consolidation jobs and postmortems. This keeps the current turn from being flooded by junk.

A minimal schema can look like this:

memory_item:
  id
  claim            # one-sentence claim
  scope            # repo/directory/environment/global
  evidence_at      # last verified time
  status           # active | conflict | stale | archived
  supersedes       # old item being replaced
  source_span      # pointer to raw trajectory; do not put long logs into retrieval text

IV. How to Run the Consolidation Job

Place consolidation between sessions, not in the turn the user is waiting on. Triggers can include: cumulative new entries exceeding a threshold, idle time exceeding a period, or detection of multiple highly similar records on the same topic.

An operational workflow is as follows.

Step 1: Window the scope. Process only new and hit entries from a recent time window or a project scope, avoiding a full-store rewrite every time.

Step 2: Cluster. Group candidates by topic, scope, and text similarity. Do not mix test commands, field types, and deployment environments into one “summary” group.

Step 3: Compare against the timeline. Within a group, sort by evidence time and mark possible change points. When the materials do not support a judgment, output a conflict rather than inventing a unified conclusion.

Step 4: Rewrite canonical entries. Keep only one active claim per group, and mark old entries as superseded or archived. The rewrite must be shorter, with explicit scope and uncertainties.

Step 5: Write back the index and record the job itself. Consolidation is also a write and must be traceable: which IDs were merged, what was deprecated, and what was retained. Otherwise the memory system becomes an unauditable black box.

Step 6: Set protections. Preferences, safety boundaries, and prohibitions explicitly stated by the user should not be diluted or overwritten by automatic summaries. Such entries should have a higher lock level; consolidation may append clarification but must not downgrade them.

The pseudocode expresses control flow only and does not depend on any vendor API:

on_idle(project):
  batch = load_recent_items(project, since=last_dream)
  groups = cluster_by_topic_and_scope(batch)
  for g in groups:
    if has_hard_lock(g): skip_or_append_only(g); continue
    decision = reconcile(g)   # merge | conflict | stale
    write_canonical(decision)
    mark_sources(g, decision)
  checkpoint(last_dream)

V. Working with Retrieval and Context

Consolidation addresses inventory quality; retrieval addresses which few entries should be seen in the current turn. The two must be designed together.

Retrieval should first filter for entries that are active and whose scope matches the current repository or directory, then sort by relevance. Conflict entries may be returned but should carry a “disagreement exists” marker, prompting the model to verify rather than execute them as fact. Stale entries should be excluded from context by default.

The context budget should be reserved for the current task. Memory injection should be short: one or two sentences per entry, with a limit on the number of entries. If that is still insufficient, expand raw trajectories on demand rather than pasting the entire memory store into the prompt.

Also distinguish “the model remembers” from “the system records.” The former is unreliable; the latter is testable. For evaluation, use a fixed task sequence: implant a rule first, introduce a rule change midway, then run multiple rounds of distracting tasks, and check whether the final retrieval returns the new rule, the old rule, or both side by side. Single-turn question answering will not reveal memory degradation.

VI. Risks and Boundaries

Automatic cleanup introduces new errors. Summaries may drop exception conditions, merging may combine two similar but distinct projects into one entry, and temporal inference may treat a change that has not yet gone live as already effective. Therefore, by default, consolidated results should have lower confidence than an explicit correction from the user in the current turn. High-impact operations such as deleting data, changing permissions, or publishing should still return to the current context or human confirmation; they must not rely on old memory alone.

Cost and privacy also need control. Consolidation reads history again, so its scope should be limited, secrets and personal information should be redacted, and it should be possible to disable it or perform deduplication only without rewriting. If a job fails, keep the original entries; do not write a half-finished result over valid memory.

From a research perspective, the significance of this kind of mechanism is that an agent’s capability no longer depends only on how long a single context is, but on whether the system can turn experience into updatable state. No matter how large the context window becomes, it cannot stop unbounded appends. Without consolidation, long-running operation is just a growing junk pile. With review, merging, and invalidation between sessions, memory changes from logs into knowledge. This does not replace reasoning; it lets reasoning start each time from cleaner premises.