---
格式版本: 2
标题: "Agent memory is a database problem: Oracle research makes the case | developers"
原文链接: "https://blogs.oracle.com/developers/agent-memory-is-a-database-problem-oracle-research-makes-the-case"
发布日期: "2026-08-10"
发布时间校准状态: "found"
发布时间需复核: "否"
发布时间来源: "rule:local:strict_original_body"
发布时间证据: "August 10, 2026 6 minute read"
发布时间校准原因: "规则确认唯一严格发布时间，来源 local:strict_original_body"
发布时间校准置信度: "high"
发布时间候选数量: 5
发布时间严格候选数量: 1
发布时间原页读取状态: "source template page reused from URL open"
发布时间未找到原因: ""
发布时间校准时间: "2026-08-11T22:08:40+08:00"
发布时间仲裁状态: "skipped"
发布时间仲裁尝试次数: 0
发布时间仲裁耗时毫秒: 0
发现时间: "2026-08-11T21:55:15+08:00"
入库时间: "2026-08-11T14:08:40.479Z"
来源平台: "固定入口"
搜索渠道: "fixed_url"
搜索词: "https://blogs.oracle.com/?page=news"
匹配关键词:
  - "roadmap"
  - "AI"
相关厂家:
  - "Oracle"
相关专家:
  []
内容类型: "网页"
抓取工具: "CDP Render"
清洗工具: "CDP Text + Defuddle/Readability 正文提取"
原始附件:
  []
AI优质: "否"
AI打分: 35
AI分档: "非优质"
AI质检状态: "不通过"
AI打分理由: "正文讨论Oracle Agent Memory数据库代理内存方案，未涉及超节点/AI Rack/机柜级AI系统、高速互连、供电、液冷、量产落地等核心主题，与项目关注范围明显无关。"
AI质检模型: "ali-deepseek-v4-flash"
AI质检时间: "2026-08-11T22:08:50+08:00"
AI主题相关性: 0
AI来源权威性: 15
AI新颖性: 10
AI技术细节: 0
AI商业部署信号: 0
AI完整性: 10
采集批次: "2026年8月11日21点09分57秒"
采集批次ID: "20260811-210957-092"
去重键: "https://blogs.oracle.com/developers/agent-memory-is-a-database-problem-oracle-research-makes-the-case"
---

*A technical report on arXiv sets out a database-native memory substrate for long-horizon agents: 93.8% on LongMemEval, roughly 10.7× fewer input tokens than flat conversation history, and governance treated as a design constraint, not an afterthought.*

---

## Key Takeaways

- Agent memory is fundamentally a data-management problem. Long-horizon agents need persistent, scoped, retrievable, and governable memory, not just larger context windows or more conversation history.
- Oracle Agent Memory manages working memory, long-term factual memory, and procedural memory directly on Oracle AI Database, with a lifecycle spanning extraction, consolidation, retrieval, summarisation, and revision.
- In the report, Oracle Agent Memory achieved 93.8% on LongMemEval and kept estimated input context to about 1,300 tokens per request at turn 80, compared with roughly 13,900 for flat conversation history.
- Keeping agent memory in the database keeps it close to the enterprise data it reasons over, while bringing transactions, relational, JSON and vector capabilities, scoped retrieval, and database-enforced governance into the same substrate.

---

Prompt and context engineering emerged for a reason: to elicit specific behaviours from large language models whilst maintaining a high signal-to-noise ratio in the context window, through systematic curation of the data injected into it. But as models grow more capable at reasoning, extensive context-window management is becoming less necessary.

The real job to be done sits elsewhere: adapting agents to new information, and making them dependable on long-horizon tasks. That job is the subject of a new technical report from Oracle’s AI teams, [*Oracle Agent Memory as an Enterprise Memory Substrate for Long-Horizon AI Agents*](https://arxiv.org/pdf/2607.13157), published this month on arXiv.

---

**Agent memory has emerged as the solution: the capability that lets agentic systems learn, adapt, and personalise from continuous interaction between the agent, its users, and its environment.** The report grounds this in recognisable enterprise use cases: support agents recalling incident history across weeks, coding agents reusing prior design decisions, analytics agents that know what “average spending” means in the business.

The core problem investigated is not recall; it is maintaining heterogeneous memory under explicit scope, retention, and retrieval constraints; this is effective memory management. Yet although many memory-management solutions have emerged, few have met the demanding requirements of enterprise AI workloads. Most are variations on “just add a vector store”: fragments assembled around the model (reflection buffers, framework add-ons, standalone memory services) that each work in a demo, and that together complicate governance, security, data locality, and reliability in an enterprise setting.

The gap is enterprise-grade memory: a substrate where governance and security are entry requirements rather than roadmap items, and where scale, reliability, and data locality come built in rather than bolted on. The report is written squarely at that gap. Its starting observation is simple: the list of things agent memory demands (persistence, indexing, scoped retrieval, transactions, governance) is a list of database requirements.

---

**Oracle Agent Memory is a database-native memory substrate that treats agent memory as a managed lifecycle, spanning ingestion, extraction, consolidation, retrieval, summarisation, and revision, built directly on Oracle AI Database.** The report organises that memory into three operational categories:

- **Working memory**: the active state of a task, materialised as thread summaries and context cards compact enough for prompt injection.
- **Long-term factual memory**: durable facts, preferences, and profile attributes that persist across sessions under user and agent scope.
- **Procedural memory**: lessons, strategies, and guidelines drawn from prior outcomes; what the agent has learned to do, not just what it knows.

An active memory core does the opinionated work: synchronising threads, extracting durable facts, refreshing summaries and context cards, orchestrating search. Beneath it sits a passive memory-store contract (insert, search, retrieve, enforce scope) that stays reusable even for third-party memory libraries wanting Oracle AI Database as their backend.

The report measures the substrate across long-horizon memory benchmarks, a flat-history baseline, and estimated token behaviour:

- **93.8% on LongMemEval** (469 of 500), including 100% on single-session assistant recall and 96.2% on temporal reasoning. Multi-session reasoning is the honest low point at 88%, and the report says so.
- **Roughly 10.7× fewer estimated input tokens** than a flat-history baseline by turn 80 of a scripted conversation: about 1,300 tokens per request against roughly 13,900.
- **48 wins, 13 losses, 19 ties** in pairwise judging against that same flat-history baseline, a 3.7× win ratio among non-tied turns, even though the baseline saw the entire transcript. Bounded, relevant context beat complete, unfocused context.
- **0.680 on BEAM at the 1M-token scale** under event-presence scoring, ahead of previously reported external results, with the stricter order-sensitive score (0.630) and an early 10M stress test (0.510) published alongside it.

**For enterprise leaders**, the argument is about where institutional memory should live. Agent memory holds private conversations, inferred preferences, learned procedures, and retrieved enterprise facts. Store it in a side service with its own authorisation model and you replicate identity, role, and policy outside your primary data platform. Place it in the database and memory stays close to the enterprise data it reasons over, inheriting the controls you already trust: with database-enforced access control through Oracle Deep Data Security, a denied record is absent from retrieval because the acting identity was never allowed to see it, not because an application filter caught it afterwards. **Memory stops being another shadow data store to govern.**

For developers, the report reads like an engineering document, because it is one. Threads are the integration primitive, and the workflow has four recurring stages:

1. Initialise the memory client with a database connection, an embedder, and an optional LLM.
2. Create or reopen a thread, scoped to a user and an agent.
3. Add messages so the system persists history and runs extraction and summarisation.
4. Retrieve context via scoped search, context cards, or thread summaries before the next turn.

Defaults are conservative: bounded reads, bounded search, explicit scope with exact-match controls, no hidden schema side effects. The [`oracleagentmemory`](https://www.oracle.com/database/ai-agent-memory/) Python client is model-agnostic at the embedder and LLM layer, slots into harnesses such as LangGraph and WayFlow, and supports three integration patterns (middleware-centric, tool-centric, or hybrid). The appendices cover setup, thread lifecycle, and search semantics in runnable detail.

The report also stakes out an evaluation position both audiences should note: downstream accuracy alone is not enough. A correct answer can hide noisy retrieval; a wrong one can hide a memory layer that did its job. It measures memory as a system instead, separating evidence retrieval, evidence use, task outcome, and operational efficiency, and applies that standard to itself, publishing configuration caveats, threshold sweeps, and failure modes in plain sight.

Every team building agents eventually rediscovers the same requirements list, and then rebuilds it around a vector store. The position behind Oracle Agent Memory is that the list already has an answer. Give agents a substrate that speaks transactions, vectors, JSON, and policy natively, and the effort moves to where it actually matters: managing the lifecycle of what an agent remembers, not plumbing where it stores it. **The storage question is settled. Remembering is the work.**

## The full report is available on arXiv

[Read the full report](https://arxiv.org/pdf/2607.13157)

## FAQs

### What is agent memory?

Agent memory is the persistent state that lets an AI agent retain and retrieve useful information across interactions. That can include active task context, facts and preferences learned over time, and procedures or strategies derived from previous outcomes. Unlike the context window, that information does not have to disappear when the current conversation ends.

### How is agent memory different from RAG or a vector database?

Vector retrieval can be part of agent memory, but retrieval alone is not memory management. An agent also needs to decide what to retain, how that information is scoped, when it should be updated or summarised, how long it should persist, and who is allowed to retrieve it. The Oracle report treats those as lifecycle and data-management problems rather than just search problems.

### Why use a database for AI agent memory?

Agent memory needs many of the capabilities databases already provide: persistence, indexing, structured and semantic retrieval, transactions, access control, and governance. A database-native approach also allows relational data, JSON, vectors, and memory state to live on the same managed substrate rather than being distributed across separate memory services.

### How does Oracle Agent Memory integrate with agent applications?

Developers create or reopen a thread scoped to a user and agent, add messages, and retrieve relevant context before subsequent turns. The `oracleagentmemory` Python client is model-agnostic at the embedding and LLM layers and supports middleware-centric, tool-centric, and hybrid integration patterns, including with frameworks such as LangGraph and WayFlow.