Memory Management

Memory Compaction Removes Critical Information

Over a long-running session, an agent's live working context (the conversation buffer, scratchpad, and accumulated tool outputs for the current run) comes to contain multiple, mutually contradictory statements about the same fact — an earlier tool result, a superseded plan, or a value that later changed — with no mechanism marking any of them as authoritative. Unlike long-term memory-store conflicts, which surface across sessions, this happens entirely within one continuous run: partial compaction, tool retries, and branching sub-tasks leave old and new versions of the same fact co-resident in context, and the model attends to whichever is more salient rather than resolving the conflict.

Many agent architectures periodically "refresh" a block of context — re-fetching current system state (order status, ticket state, account balance, feature flags) and re-injecting it into the prompt so the agent reasons over up-to-date information rather than what it read at session start. When the refresh mechanism itself reads from a stale source — a lagging read replica, a cache with a long TTL, a materialized view that hasn't recomputed — the agent receives a context block that looks fresh (it was "just refreshed") but actually contains old data, and the agent has no way to distinguish this from a genuine refresh.

An agent has no internal tracking of how much of its context window is currently consumed, so as the session grows — tool outputs, retrieved documents, prior turns — early content gets silently truncated or evicted by the underlying context-management layer without the agent ever registering that it happened. The agent continues to reason as if everything it was told earlier is still available, producing answers that ignore or misremember instructions, constraints, or facts that were established at the start of the session and have since fallen out of the window.

Retrieved Memories Contradict Each Other

Individual entries in a persistent memory store can become corrupted — truncated writes from a crashed process, malformed JSON from a partial serialization, encoding mangling, or a bad migration that silently drops or garbles fields — and the retrieval path has no validation step that would catch this before the corrupted entry is handed to the agent. Instead of failing loudly, the agent receives a mangled fact, a broken embedding, or a record with fields swapped and treats it as valid input, often producing a confidently wrong answer that is harder to diagnose than an outright retrieval failure would have been.

As a memory store accumulates entries over months of operation — many small, partial, or redundant writes rather than clean consolidated records — the store fragments: the same underlying fact ends up spread across dozens of small entries, indexes grow disproportionately to the useful information they contain, and retrieval has to search, rank, and merge far more candidate records than the actual amount of distinct information warrants. Retrieval latency climbs and result quality drops, not because any single record is wrong, but because the signal is scattered across so many fragments that ranking and top-k selection can no longer reliably surface the most complete or relevant one.

When multiple agent instances or agent types share a common memory store — a customer-service agent and a billing agent both reading/writing facts about the same account, or multiple parallel worker agents in a fleet — they can each see a different view of "current" memory state at the same moment, because of replica lag, per-connection caching, or eventual-consistency propagation delays in the shared store. There is no single moment-in-time snapshot all agents agree on, so two agents acting concurrently on the same entity can make decisions based on genuinely different, both-locally-valid-but-mutually-inconsistent memory states.

When two writes to the same memory record happen concurrently and the storage layer performs a non-atomic read-modify-write cycle (read current value, apply an update in application code, write the result back), the two writes can interleave: both read the same starting state, both compute an update based on that stale starting state, and the second write to complete overwrites the first — or worse, a field-level race produces a record that mixes fragments of both updates, a state that neither writer ever intended and that doesn't correspond to either update applied cleanly. Unlike a full corrupted record from a crashed write, this is a "successfully" completed write that is nonetheless wrong because of the race.

An agent accumulates state — working memory, in-progress task tracking, session-scoped facts — purely in the host process's memory (a Python dict, an in-memory cache, an unpersisted object graph) without writing it to durable storage. When the process restarts — a deploy, a crash, an autoscaler recycling the instance, an out-of-memory kill — all of that state disappears instantly and irrecoverably, and the agent resumes (or a fresh instance picks up the workload) with no record that the state, or the work in progress, ever existed.

A memory write completes and is acknowledged as successful, but the read path the agent actually queries — a separate search index, a cache layer, a denormalized read table — has not yet been updated to reflect it, so the agent's next retrieval for that same fact returns the pre-update value even though the write, from the writer's point of view, already happened. This is a read-after-write consistency gap: the record of the update exists somewhere in the system, but not yet on the path the agent reads from, and neither the write nor the read reports any error.

A shared memory store's write path — a queue, a lock, a single-threaded writer — has no concept of write priority, so a burst of low-priority writes (verbose interaction logging, background enrichment, routine housekeeping updates) can occupy the write pipeline or hold a lock long enough that a high-priority write (a safety-relevant correction, a critical status update) queues behind them and is delayed well past when it was needed. The delay isn't caused by the high-priority write being slow itself — it's blocked waiting for unrelated, lower-value writes to clear ahead of it in a shared, priority-blind pipeline.

Memory intended to be scoped to a single user, tenant, or session leaks into a different user's, tenant's, or session's context — a shared vector index queried without a tenant filter, a session-ID collision, a caching layer that keys on the wrong scope, or a retrieval query broad enough to pull in another user's records because embeddings happen to be similar. The agent then surfaces one person's private facts, preferences, or history to someone else, without any error or access-denied signal, because from the retrieval system's point of view the query simply "worked" and returned relevant-looking results.

Relevant Memories Not Retrieved When Needed

When long-term memory is compacted to fit a fixed storage or retrieval-token budget — a periodic "condense this user's history into a compact profile" job, rather than the cascading multi-pass summarization that produces summary drift — the single compaction pass must decide what to keep and what to discard under that budget, and it systematically drops details that appear low-value at compaction time but turn out to be exactly what a later query needs. Unlike summary drift, where quality degrades across repeated re-summarization cycles, this is a one-time, budget-driven compression choice: the loss happens once, at the moment of compaction, because the summarizer has no way to know in advance which details a future query will actually require.

A retrieval system's relevance or similarity score (cosine similarity, a reranker's confidence output, a hybrid search's combined score) is meant to signal how useful a retrieved memory will be for the current query, but in practice that score frequently doesn't correlate well with actual usefulness — a high-scoring result can be topically similar but practically useless (a near-duplicate that adds nothing new, an outdated version of a fact), while a lower-scoring result can be exactly the piece of context the agent needs. Agents that treat the raw score as a trustworthy confidence signal — using it to decide what to include, how much to trust a fact, or whether to ask a clarifying question — inherit whatever miscalibration the scoring function has, often without any indication that the score wasn't dependable.

A memory store accumulates near-duplicate entries — the same fact stated slightly differently across multiple writes, or the same document ingested more than once — and the retrieval layer has no deduplication step, so a single query returns several near-identical results occupying multiple slots in a limited top-k result set. Instead of surfacing k genuinely distinct, useful pieces of information, the agent receives k-minus-several redundant restatements of the same one or two facts, wasting context budget and pushing genuinely different, useful candidates below the cutoff.

The retrieval index itself — the vector index's internal graph/tree structure, an inverted index's postings lists, or a search engine's shard metadata — becomes structurally corrupted, from a bad write during an index rebuild, a version mismatch between index format and query engine, a crashed process leaving a partial index update, or disk/memory corruption at the infrastructure level. Unlike corruption of an individual memory record, this degrades retrieval quality or availability across the entire index (or a whole shard/partition of it), producing wrong, missing, or inconsistent results for many unrelated queries at once rather than for one specific fact.

Retrieval ranks results primarily or purely by semantic similarity to the query, with no explicit weighting for recency, so when a memory store contains both an older fact and a newer fact that supersedes it, the older one can outrank the newer one simply because it happens to phrase things in a way that scores higher against the query embedding. The agent then surfaces or acts on the stale result ahead of the current one, not because the current one is missing from the store, but because the ranking function that decided what to return never considered which one is actually more recent.

When the embedding model used to index a memory store is upgraded or swapped — a new model version, a provider change, a fine-tuning update — the vector space it produces shifts: distances and similarity relationships that held under the old model don't hold the same way under the new one, so old embeddings computed with the previous model and new embeddings computed with the current model are no longer meaningfully comparable, even though they're stored in the same index and queried together as if they were. Retrieval quality degrades in a way that has nothing to do with the content of the memories themselves, purely because the "ruler" used to measure similarity changed without the stored data being re-measured against it.

Repeated Summarization Degrades Information Quality

Too Much Information Retrieved for Effective Use