Why Do Long‑Horizon AI Agents Still Use the Wrong Memories?

From Retrieval to State Maintenance

RAG stores relatively static external knowledge—documents, manuals, specifications—by chunking, embedding, and indexing them, then retrieving the most semantically similar pieces for a query. Agent Memory, however, must handle continuously evolving state such as user preferences, task progress, tool outputs, and procedural knowledge, which can be added, updated, merged, or deleted over time.

For example, a user may first express a preference for early flights and later request to avoid them. Both statements are true, but a pure vector similarity search would retrieve both, lacking the ability to decide which is current or should be discarded.

Memory Lifecycle

Oracle’s report defines a long‑term memory lifecycle comprising ingestion, extraction, consolidation, retrieval, summarization, and revision/removal. Different kinds of information follow distinct lifecycles: temporary working memory for ongoing steps, long‑term factual memory for preferences and business entities, episodic records of tool calls, and procedural memory distilled from successes and failures.

The system must continuously synchronize raw dialogues and tool traces, select information worth persisting, extract facts or experiences, merge duplicates, create compact summaries, enforce scope‑based retrieval, and revise or delete stale state. Evaluation of this process shows that a well‑engineered lifecycle prevents unbounded growth of context size.

Memory as an Enterprise Substrate

Oracle separates the active memory layer (which assembles the current context for inference) from the underlying Memory Store (which persists messages, summaries, facts, and user profiles). This layering enables multiple agents within an organization to share a common state base while respecting isolation, permission, and governance requirements.

Shared memory can reduce duplicate learning—e.g., a customer‑service agent’s captured preferences can inform a sales agent—but it also amplifies risks of leakage and error propagation if access controls are insufficient.

System Issues: Cost, Updates, Governance

In Oracle’s configuration, the Agent Memory system achieved 93.8% overall accuracy (469/500) on the LongMemEval benchmark, with 100% recall for single‑session queries, 96.2% for temporal reasoning, 94.9% for knowledge updates, and 88% for multi‑session reasoning. The experiment used GPT‑5.5, xhigh reasoning, nomic‑embed‑v1.5, an HNSW index, and top‑K=200; results are specific to this setup.

LongMemEval also revealed that maintaining the full conversation history inflates token usage dramatically (≈13,900 estimated tokens at round 80) compared with Agent Memory’s periodic summarization approach (≈1,300 tokens), a roughly ten‑fold reduction.

Beyond retrieval accuracy, a production‑ready memory system must answer questions about freshness, scalability, latency, write cost, conflict resolution, evidence tracking, and deletion integrity. Vector similarity alone cannot determine whether retrieved content is still applicable, belongs to the current user, or has been superseded.

Recent research ( Agent Memory: Characterization and System Implications of Stateful Long‑Horizon Workloads , 2026) classifies ten representative memory systems and shows that architectural choices trade off read‑path versus write‑path costs. Some designs simplify writes but incur higher query overhead; others front‑load extraction and consolidation to ease later retrieval.

Conclusion

When agents operate over long horizons, reliability hinges less on model intelligence and more on the ability to correctly remember, revise, and forget past information. Effective Agent Memory therefore evolves from a simple retrieval component into a governed, lifecycle‑aware data infrastructure that supports shared enterprise state while controlling cost and ensuring correctness.