October 20, 2026

Oracle Agent Memory: Persistent Recall Without Losing Project Truth

Build Oracle Agent Memory with scoped database recall, readable project truth, and a practical test for correction, isolation, provenance, and exit.

Oracle Agent Memory is a database-native memory layer for agents that need persistent conversations, durable facts, scoped retrieval, retention, and enterprise controls. It is a strong fit when Oracle AI Database already holds the operational data your agent reasons over.

But durable recall and canonical project knowledge are not identical. Inferred preferences and conversation summaries belong in a managed memory system. Architecture decisions, runbooks, constraints, and approved procedures should often remain files your team can read, edit, diff, and self-host. A practical design pairs Oracle's retrieval layer with a readable wiki such as Meshnote, exposed to agents through MCP.

What the leading Oracle Agent Memory pages cover

The current top results are Oracle's 26.8 getting-started guide, its MCP server tutorial, and the Oracle engineering article arguing that agent memory is a database problem. Together they cover package installation, managed schemas, threads, automatic extraction, scoped search, TTL, hybrid retrieval, MCP tools, LangGraph and WayFlow clients, security, and benchmark results.

Oracle's August 2026 research article reports 93.8% on LongMemEval and about 1,300 estimated input tokens per request at turn 80, versus roughly 13,900 for flat history. The current 26.8 product page reports a newer documented configuration at 94.4% (472 of 500) and adds graph memory, image support, and database-enforced end-user isolation. These are configuration-specific results, not a promise for every workload. The useful lesson is architectural: bounded retrieval can beat replaying an entire transcript, but benchmark numbers must be read with their model, embedding, index, and retrieval settings.

What those pages do not provide is a rule for deciding which store is authoritative, plus a release drill proving that correction, tenant isolation, provenance, and migration still work. This guide adds that missing operational layer.

How Oracle Agent Memory works

Oracle separates active thread state from durable memory records. Applications create or reopen a thread, add messages, let extraction produce reusable memories, and retrieve scoped context before a later model call. Version 26.8 supports keyword, vector, and hybrid search; hybrid search requires Oracle AI Database 23ai 23.6 or later. Messages and memory-like records can receive TTL values, while a scheduled database job physically purges expired rows and retrieval chunks.

The important production boundary is scope. A memory should carry the user, agent, thread, tenant, and source identifiers needed to prevent accidental cross-customer recall. Oracle's security guidance also recommends separate schema-owner and runtime accounts. The runtime path should attach the authenticated end-user context and fail closed rather than borrowing a privileged connection.

A two-layer architecture that stays understandable

LayerStore hereWhyDo not treat it as
Oracle Agent MemoryMessages, preferences, extracted facts, episodic history, context cardsScoped retrieval, hybrid search, TTL, database governanceThe automatically approved source of project policy
Readable project memoryDecisions, runbooks, architecture, accepted constraints, source notesHuman review, diffs, links, history, portabilityA high-volume transcript or behavioral profile
Source systemsOrders, tickets, contracts, code, database rowsThey remain authoritative for operational factsAgent-authored memory

This is the same distinction behind a robust persistent-memory architecture: derived memory helps the agent recall; canonical memory tells the team what is currently approved. If semantic retrieval and readable files are still being evaluated, see vector memory vs readable memory.

Minimal Oracle setup

The following example follows Oracle 26.8's public API. It assumes the database schema has already been provisioned and that the model credentials required by your configured providers are available in the environment.

pip install "oracleagentmemory==26.8.0" oracledb
import os
import oracledb

from oracleagentmemory.apis.searchscope import SearchScope
from oracleagentmemory.core import SchemaPolicy
from oracleagentmemory.core.embedders.embedder import Embedder
from oracleagentmemory.core.llms.llm import Llm
from oracleagentmemory.core.oracleagentmemory import OracleAgentMemory

pool = oracledb.SessionPool(
    user=os.environ["ORACLE_MEMORY_USER"],
    password=os.environ["ORACLE_MEMORY_PASSWORD"],
    dsn=os.environ["ORACLE_MEMORY_DSN"],
)

memory = OracleAgentMemory(
    connection=pool,
    embedder=Embedder(model=os.environ["MEMORY_EMBEDDING_MODEL"]),
    llm=Llm(model=os.environ["MEMORY_LLM"]),
    schema_policy=SchemaPolicy.REQUIRE_EXISTING,
    memory_store_id="SUPPORT",
)

thread = memory.create_thread(user_id="user-42", agent_id="support-agent")
thread.add_memory(
    "User 42 prefers email updates for incident INC-2048.",
    memory_type="preference",
)

results = memory.search(
    query="How should we update the user about INC-2048?",
    scope=SearchScope(user_id="user-42", agent_id="support-agent"),
)

for result in results:
    print(result.content)

Use CREATE_IF_NECESSARY only during controlled schema setup. Normal application instances should use REQUIRE_EXISTING with a least-privileged runtime identity. Also set explicit retention instead of allowing memory to grow forever.

Add readable project truth over MCP

Oracle's MCP tutorial exposes memory operations to multiple runtimes. Add a second MCP server for canonical project knowledge rather than forcing every durable fact into the same lifecycle. With Claude Code, a hosted Meshnote project can be connected with:

claude mcp add --transport http meshnote https://meshnote.io/mcp \
  --header "Authorization: Bearer $MESHNOTE_API_KEY"

Then give the agent an explicit contract:

  • Search Oracle memory for prior interactions, preferences, and relevant episodes.
  • Read the project wiki before changing architecture, policy, or a runbook.
  • Never promote an extracted memory into project truth without a cited source or human-approved change.
  • When the wiki conflicts with inferred memory, follow the wiki and correct or expire the derived record.

This makes the system agent-agnostic: Oracle can serve database-backed recall, while Meshnote gives Claude Code, Cursor, Codex, and other MCP clients the same readable project memory. For the protocol mechanics, use the MCP memory server guide.

How Oracle compares with other memory approaches

OptionBest fitStrengthTrade-off
Oracle Agent MemoryOracle-centric enterprise agentsRelational, vector, graph, lifecycle, and policy in one databaseOperational weight is high if Oracle is not already in your stack
Mem0Fast memory-layer integrationSimple add/search API with vector and optional graph memoryCanonical documents still need a separate authority model
Zep/GraphitiChanging entities and relationshipsTemporal context graphs and hybrid retrievalGraph-derived facts are not automatically approved policy
LettaPersistent stateful agentsAgent identity, memory blocks, message history, and MemFSThe runtime and the memory model are more tightly coupled
Native assistant memoryPersonal convenienceLow setup and useful personalizationLimited team governance and cross-tool portability

There is no universal winner. Choose Oracle when database governance, locality, mixed retrieval, and existing Oracle operations matter. Choose a lighter service when integration speed matters more. Keep readable files when humans must inspect, approve, and move the knowledge independently of the memory engine.

The six-case authority-and-replay drill

  1. Persistence: store a preference, restart the application, and retrieve it under the same scope.
  2. Isolation: repeat the query as another user and tenant; expect no result.
  3. Correction: change email to SMS, then verify the old preference cannot outrank the current one.
  4. Provenance: identify whether each answer came from a message, extracted memory, wiki page, or source system.
  5. Policy conflict: place an obsolete procedure in derived memory and the approved procedure in the wiki; the agent must follow the wiki and flag the stale record.
  6. Exit: export the canonical Markdown, disconnect the Oracle memory tools, and verify another MCP client can still reconstruct the approved project state.

Run this drill in CI or before a memory release. Recall quality is not enough if the system leaks scopes, preserves contradictions, or cannot explain which store won.

When this architecture is worth it

Use the two-layer design when an agent serves multiple users, remembers sensitive interactions, or participates in operational decisions. A small personal assistant may need only native memory. A support platform already on Oracle can justify the database-backed lifecycle. A development team sharing decisions across tools benefits from readable Markdown even if Oracle handles conversational recall.

The key is not maximizing remembered data. It is making every class of memory correctable, scoped, and replaceable. If your project knowledge must remain readable and portable across agents, start syncing — $8/mo. Teams can use self-hosted from $10/seat/month, with a five-seat minimum.

Related Reading

Your agent's memory should be files you can read and own

Meshnote is readable, self-hosted memory for AI agents — markdown wikis your agents maintain over MCP. Hosted from $8/month.

Start syncing — $8/mo

Rejoining the server...

Rejoin failed... trying again in seconds.

Failed to rejoin.
Please retry or reload the page.

The session has been paused by the server.

Failed to resume the session.
Please retry or reload the page.