AI agents are most useful when they can carry context forward. A single prompt can answer a question, but real agent workflows often span multiple turns, sessions, users, tools, and decisions. Oracle AI Agent Memory provides a database-backed memory layer that helps applications store messages, records, durable memories, summaries, and prompt-ready context in Oracle AI Database.
The release focuses on practical improvements for developers building memory-aware agents: lower-latency memory workflows, stronger retrieval with hybrid search, and more control over what gets stored, retrieved, updated, and injected back into the agent context.
These updates matter because memory is no longer a side feature for advanced chatbots. In enterprise agent systems, memory becomes part of the application architecture. It determines what the agent can carry forward, what it can retrieve later, how much context it needs to send to the model, and how safely the application can scope remembered information.
Companion notebook: https://github.com/oracle-devrel/oracle-ai-developer-hub/blob/main/notebooks/agent_memory/oamp_support_assistant_example.ipynb
Key Takeaways
- Oracle AI Agent Memory helps developers build agents with persistent short-term and long-term memory backed by Oracle AI Database.
- Latency-focused extraction improvements help memory processing fit more naturally into user-facing agent workflows.
- Hybrid vector and text search improves retrieval when applications need both semantic recall and exact matching.
- Custom extraction instructions let developers guide what should become durable memory.
- Context cards help compact long conversations into prompt-ready short-term context.
- Metadata filtering and update APIs provide more control over memory scope, retrieval boundaries and lifecycle management.
- Time-to-live (TTL) support lets applications define retention behavior for messages and memory-like records, including default retention periods, per-record TTL overrides, and expiration-aware retrieval.
- OracleDBEmbedder and chunked semantic indexing improve database-backed retrieval and indexing workflows.
- Benchmark evaluation includes LongMemEval and BEAM results to validate retrieval quality and continuity across long-running agent workflows.
- The end-to-end support copilot notebook demonstrates these capabilities together in an end-to-end customer-support copilot, from background extraction and hybrid retrieval to context compaction, updates, isolation, and retention.
Why Persistent Memory Matters for AI Agents
Many agents need to remember more than the latest user message. They need preferences, decisions, task state, policy guidance, tool outputs, and prior conversation context. Without memory, an agent has to rediscover the same context repeatedly. With persistent memory, it can retrieve useful information and continue work with better continuity.
Oracle AI Agent Memory supports both short-term and long-term memory. Short-term memory keeps an active conversation compact and focused through summaries and context cards. Long-term memory stores durable facts, preferences, records, and other reusable information across sessions.
A useful way to think about the difference is scope:
- Short-term memory helps the agent stay oriented inside the current thread: what the user is trying to do now, what has already been decided, and what recent messages still matter.
- Long-term memory preserves information that should survive beyond the current thread, such as a user preference, an account-level fact, a workflow rule, or a domain-specific record the agent should be able to retrieve later.
Because the memory layer is backed by Oracle AI Database, the application does not need to treat memory as a separate, opaque store. Messages, memory-like records, metadata, embeddings, and search text can live in the same enterprise data platform used for transactional data, JSON, vector search, and operational controls.
Oracle AI Agent Memory architecture showing storage, search, compaction, control, prompt context and Oracle AI Database
thread = memory.create_thread(
thread_id=THREAD_ID,
user_id=USER_ID,
agent_id=AGENT_ID,
metadata={"tenant_id": TENANT_ID, "case_id": CASE_ID, "status": "open"},
)
await thread.add_messages_async(
initial_messages,
metadata=CASE_METADATA,
)
await thread.add_memory_async(
"The customer prefers SMS for support updates.",
memory_type="preference",
metadata=CASE_METADATA,
ttl_days=180,
ttl_anchor=TimeToLiveAnchor.CREATED_AT,
)
results = await thread.search_async(
"damaged ORDER-7421 and preferred update channel",
exact_user_match=True,
exact_agent_match=True,
exact_thread_match=True,
max_results=10,
record_types=["memory", "fact", "preference"],
)
What Changes in Oracle AI Agent Memory
| Capability | What it improves | Developer value |
|---|---|---|
| Faster extraction workflows | Memory extraction latency | Keep user-facing turns responsive while memory formation happens more flexibly. |
| Hybrid search | Retrieval precision and recall | Combine semantic similarity with exact text matching for identifiers, aliases, SKUs, issue codes, and phrases. |
| Custom extraction instructions | Memory quality | Guide what durable facts should be preserved for a domain or workflow. |
| Context cards | Conversation compaction | Inject compact, prompt-ready context without replaying the full transcript. |
| Metadata filtering and inheritance | Retrieval boundaries | Scope results by tenant, source, tags, workflow, or review state. |
| Update APIs | Memory lifecycle | Update threads, messages, and memory-like records as application state changes. |
| OracleDBEmbedder | Database-managed embedding flow | Use a DB-resident embedding model aligned with Oracle-managed hybrid indexing. |
| Chunked semantic indexing | Indexing larger text | Index longer searchable text while preserving the logical memory record. |
Faster Memory Extraction Workflows
Automatic memory extraction converts raw conversation turns into higher-level memories that an agent can reuse later. A conversation may contain greetings, clarifying questions, temporary task details, and durable facts. The memory layer should preserve the durable information without forcing every user-facing turn to wait unnecessarily.
The direction is to make memory extraction more latency-aware, so applications can continue the interaction while memory processing happens in a way that reduces perceived latency. This matters because extraction often involves an LLM, and blocking every turn on memory consolidation can make an agent feel slower.
For example, after a support conversation, the application may want to extract the customer’s delivery issue, order identifier, preferred resolution, and escalation status. Those are useful durable facts, but they do not always need to be extracted synchronously before the user sees the next response. Separating the foreground response path from the memory consolidation path helps developers design agents that remain responsive while still forming useful memory.
In the end-to-end support copilot notebook, raw support messages are persisted on the foreground path while durable-memory extraction runs through an in-process background worker. The application can wait at an explicit consistency boundary before tests or reads that require extracted memories to be visible.
from oracleagentmemory.core import (
BackgroundExtractionQueueFullBehavior,
MemoryExtractionConfig,
MemoryExtractionMode,
)
extraction_config = MemoryExtractionConfig(
extract_memories=True,
extraction_mode=MemoryExtractionMode.BACKGROUND,
background_extraction_queue_full_behavior=(
BackgroundExtractionQueueFullBehavior.WAIT_THEN_RAISE
),
background_extraction_queue_put_timeout_seconds=10.0,
memory_extraction_frequency=1,
memory_extraction_window=-1,
memory_extraction_token_limit=6_000,
enable_context_summary=True,
context_summary_update_frequency=2,
memory_extraction_custom_instructions=EXTRACTION_INSTRUCTIONS,
memory_extraction_inherit_message_metadata=[
"tenant_id", "case_id", "channel", "tags", "review"
],
)In practice, the extraction workflow can separate:
- the foreground path, where the user receives the next agent response;
- the persistence path, where messages are stored for continuity and auditability;
- the consolidation path, where durable facts are extracted and stored for later retrieval.
Foreground response path and asynchronous memory consolidation path
The proof point is the request path. Persist the raw messages, return control to the application, and wait for extraction only when the next operation actually needs the derived memories.
import time
started = time.perf_counter()
message_ids = await thread.add_messages_async(
initial_messages,
metadata=CASE_METADATA,
)
write_seconds = time.perf_counter() - started
print(f"Raw write returned in {write_seconds:.3f}s")
# Cross the consistency boundary before searching extracted memories.
await thread.wait_for_memory_extraction_async(timeout=120)Hybrid Search for Better Retrieval Accuracy
Vector search is useful when a query and a stored memory are semantically related. But many enterprise workflows also depend on exact text: issue codes, invoice numbers, product names, aliases, ticket IDs, or error messages. Hybrid search helps agents retrieve memories by semantic relevance while still matching identifiers and phrases that matter exactly. For database-level background on vector retrieval, see AI Vector Search.
For example, a user may ask, “What was the renewal blocker?” and expect semantic recall. Another user may search for “INV-48291” or “ORA-27102” and expect an exact match. Hybrid search is designed for this mixed reality: language plus identifiers.
Vector-only retrieval is strong when wording changes. A memory that says “the customer delayed renewal because legal review is incomplete” can still be relevant to a query like “what blocked renewal?” But vector similarity is not always enough for short strings, codes, or names. An invoice number, product SKU, ticket ID, or error code may not carry much semantic meaning, yet it can be the most important retrieval signal in an enterprise workflow.
Hybrid search addresses this by combining semantic similarity with text matching over stored search text. Developers can keep the same memory-oriented search experience while improving retrieval for both natural-language questions and exact identifiers.
This is especially useful when memory records contain:
- natural-language context, such as the reason a customer delayed renewal;
- exact identifiers, such as invoice numbers, order IDs, ticket IDs, or error codes;
- short aliases, product names, or policy phrases that should be matched directly;
- a mix of conversational wording and structured business references.
This is where hybrid search earns its place. The application should not need one retrieval path for an exact policy code and another for a natural-language question.
from oracleagentmemory.core import (
OracleDBMemoryStore,
SchemaPolicy,
SearchIndexSyncMode,
SearchStrategy,
)
store = OracleDBMemoryStore(
embedder=db_embedder,
pool=db_pool,
schema_policy=SchemaPolicy.CREATE_IF_NECESSARY,
memory_store_id=os.environ.get("OAMP_MEMORY_STORE_ID", "OAMPDEMO"),
search_strategy=SearchStrategy.HYBRID,
search_index_sync=SearchIndexSyncMode.ON_COMMIT,
memory_retention_config=retention_config,
)
print("Hybrid Oracle DB memory store is ready.")
Hybrid search combining semantic vector recall, exact text matching, and Oracle-managed hybrid vector index
More Control Over What Becomes Memory
Different applications need to remember different things. A support agent, financial assistant, healthcare workflow, and coding assistant all have different memory priorities. Custom memory extraction lets developers guide what should be preserved as durable memory instead of treating every conversation detail equally.
A support workflow may want to preserve order IDs, delivery issues, return requests, escalation reasons, customer preferences, and policy-relevant facts. At the same time, it may want to ignore greetings, small talk, and temporary details.
This is important because good memory is selective. Remembering everything is not the same as remembering well. Raw transcripts often contain information that is temporary, redundant, or irrelevant to future decisions. Custom extraction instructions help the application define what “useful memory” means for its domain.
For a customer support workflow, custom extraction instructions might prioritize:
- order IDs, return requests, delivery issues, and escalation reasons;
- customer preferences that should influence future interactions;
- policy-relevant facts that should be preserved for follow-up;
- ignoring greetings, small talk, and temporary details.
The useful part is the policy boundary: define what durable support memory means, preserve exact identifiers, and explicitly exclude secrets and conversational noise.
EXTRACTION_INSTRUCTIONS = """
Keep only durable customer-support information: confirmed case and order facts,
stable communication preferences, commitments, and reusable support guidelines.
Preserve exact identifiers. Ignore greetings, speculation, credentials, payment
secrets, and transient conversational wording.
""".strip()This instruction block is passed to MemoryExtractionConfig through memory_extraction_custom_instructions, so the same domain policy is applied whenever background extraction runs.
Custom extraction instructions can be configured at the client level or overridden for a specific thread. Existing thread-level instructions can also be updated or cleared.
This gives developers a way to make memory extraction reflect expert judgment, product policy, or workflow-specific priorities instead of treating every conversation detail equally.
In the end-to-end support copilot notebook, the extraction policy preserves stable case and order identifiers, confirmed issue facts, commitments, and communication preferences while excluding greetings, speculative troubleshooting, credentials, payment secrets, and transient wording.
Context Cards for Conversation Compaction
Long-running conversations can become expensive and noisy if the entire transcript is passed back to the model on every turn. Summaries can help, but some agents need more than a plain recap. They need prompt-ready context that includes what is currently important.
The notebook uses this context card as a bounded input for each support turn instead of replaying the complete local agent transcript and its accumulated tool output.
Oracle AI Agent Memory provides context cards for this workflow. A context card can include:
- a concise thread summary;
- retrieval topics that describe what context is relevant;
- selected durable memories, facts, preferences, or guidelines;
- recent raw messages that still matter for the next turn.
Applications can call get_context_card() to build a compact context block that helps the agent continue without receiving the full conversation transcript.
A summary alone can still miss the one preference or policy the next turn needs. Context cards can request minimum counts for specific memory-like record types through min_relevant_results_by_type.
context_card = await thread.get_context_card_async(
fallback_message_count=6,
max_relevant_results=8,
max_recent_messages=4,
min_relevant_results_by_type={
"preference": 1,
"guideline": 1,
"fact": 1,
},
)
print(context_card.content)For example, an application can ask for at least one preference and one guideline so those records are not crowded out by general memories.
This becomes especially useful when a conversation has many possible memories. Without guidance, the most recent or most semantically similar records may crowd out a preference, guideline, or other record type that the agent still needs. Minimum counts give developers more control over the shape of the compacted context.
Context card compaction combining recent messages, summaries, retrieval topics, and relevant memories
Metadata Filtering and More Control
Enterprise applications often need deterministic retrieval boundaries. Semantic search alone may be too broad. Applications may need to search only memories from a specific tenant, source system, workflow, review state, channel, or tag set.
Similarity ranks candidates; it does not authorize them. Memory records and messages can store application-owned metadata, while exact scope and metadata filters constrain which records are eligible before ranking.
extracted_hits = await thread.search_async(
"damaged ORDER-7421 and preferred update channel",
exact_user_match=True,
exact_agent_match=True,
exact_thread_match=True,
max_results=10,
record_types=["memory", "fact", "preference"],
metadata_filter={
"tenant_id": TENANT_ID,
"tags": {"$array_contains": "damaged-delivery"},
"review": {"status": "approved"},
},
)
show_hits(extracted_hits)The release also adds array membership operators for metadata filters, including $array_contains, $array_contains_any, and $not. Automatically extracted memories can inherit source-message metadata by default, or developers can disable inheritance or select specific metadata keys.
Time-to-live (TTL) functionality extends these controls to memory lifecycle management. TTL is useful when messages or memory-like records should be retained only for a limited period, such as temporary task state, short-lived operational context, or information that should not continue influencing future agent behavior after it expires.
Applications can define default retention periods and per-record TTL values. Expired records are excluded from normal reads, thread-history windows, list APIs, and vector, keyword, or hybrid search; when a managed purge job is installed, expired rows and retrieval chunks can also be physically removed.
Update APIs round out the control story. Applications can update existing threads, messages, and memory-like records instead of treating memory as append-only. That matters when memory reflects state that changes over time.
For example, a memory extracted from a support thread may inherit metadata such as tenant, channel, source system, or tags. Later, the application can search only approved support memories for that tenant or update a memory-like record when the customer’s status changes. This makes memory easier to govern as part of an enterprise application rather than as an unstructured transcript archive.
These controls help applications manage memory by:
- tenant, user, agent, or thread scope;
- source system, channel, workflow, or review state;
- tags and array-style metadata;
- record lifecycle changes through update APIs.
Update APIs and Other Developer Improvements
Memory cannot be append-only if a customer can correct a preference. Stable IDs and update APIs make that correction explicit instead of leaving contradictory records for retrieval to sort out later.
from oracleagentmemory.core.retention import TimeToLiveAnchor
replacement_metadata = {
**CASE_METADATA,
"review": {"status": "approved", "updated_by": "support-agent"},
}
updated_id = await thread.update_memory_async(
CONTACT_PREFERENCE_ID,
content="The customer prefers email for support updates.",
metadata=replacement_metadata,
ttl_days=180,
ttl_anchor=TimeToLiveAnchor.CREATED_AT,
)| Update | Why it matters |
|---|---|
| Thread and memory update APIs | Applications can update existing threads and memory-like records instead of treating memory as append-only. |
| Message update API | Applications can update raw message records while preserving stored role and timestamp values. |
| Metadata support for manual writes | Applications can store structured annotations alongside messages and memories. |
| OracleDBEmbedder | Applications can use Oracle Database embedding SQL with a DB-resident model. |
| Chunked semantic indexing | Long searchable text can be indexed in managed chunks while preserving the logical record. |
| Standard Python logging diagnostics | Applications can observe SDK diagnostics through normal Python logging. |
| Configurable embedding dimensions and input limits | DB-backed clients can create schemas and choose chunk sizes more predictably. |
These improvements make Oracle AI Agent Memory easier to integrate into production workflows where memory needs to be updated, filtered, audited, and operated over time.
Benchmark Highlights
Evaluating agent memory requires more than checking whether a model can answer from the current prompt. Long-memory benchmarks test whether a system can preserve, retrieve, and use information across longer histories, multi-session interactions, updates, and temporal references.
For Oracle AI Agent Memory, benchmark evaluation should focus on how well the memory layer supports long-running agent workflows, including retrieval quality, continuity across sessions, and the ability to surface relevant information when useful context may have appeared many turns earlier.
Useful benchmark signals for a memory layer include:
- whether the system retrieves the right memory from a long conversation history;
- whether it handles updated facts and temporal references correctly;
- whether it preserves continuity across sessions instead of relying only on the latest prompt;
- whether retrieved memory improves the final agent response without adding unnecessary context.
| Benchmark | What it evaluates | Result |
|---|---|---|
| LongMemEval | Long-memory retrieval and reasoning across longer histories and multi-session interactions. | 94.4 overall score; 472 / 500 correct. |
| BEAM 100K | Long-context memory behavior over 100K-token chat histories. | 68.5% average accuracy; 274.08 / 400. |
| BEAM 1M | Long-context memory behavior over 1M-token chat histories. | 65.6% average accuracy; 459.50 / 700. |
| BEAM 10M | Long-context memory behavior over 10M-token chat histories. | 50.3% average accuracy; 100.56 / 200. |
What the Companion Notebook Demonstrates
The end-to-end support copilot notebook implements the release capabilities as one continuous damaged-delivery support case. It follows the workflow from setup and policy ingestion through agent tool use, compact context assembly, correction, isolation, retention, and shutdown.
The end-to-end workflow demonstrates:
- background extraction that keeps LLM-backed consolidation off the foreground response path;
- hybrid retrieval for exact policy identifiers and semantic damaged-delivery questions;
- domain-specific extraction instructions and inherited support metadata;
- context cards that combine summary, retrieval topics, durable records, and recent messages;
- application-controlled tools for scoped search, typed memory writes, and memory correction;
- exact scope matching, metadata filters, TTL refresh, deletion, and chunk-index updates;
- OracleDBEmbedder and an Oracle-managed hybrid index using the same database-resident model.
Security and Deployment Notes
Persistent memory should be handled carefully. Oracle AI Agent Memory can store thread content, durable memories, metadata, and embeddings in Oracle AI Database. When LLM-backed features are enabled, the SDK may also send content to configured model endpoints for extraction, summarization, embeddings, or context-card generation.
For production deployments:
- use encrypted database connections and trusted model endpoints;
- keep secrets out of prompts, logs, metadata, and memory records;
- apply end-user authentication and authorization before memory operations;
- pass correct user, agent, and thread scope values;
- review extracted memories, summaries, context cards, and retrieved records as model-derived or retrieved text;
- avoid letting memory-derived text authorize privileged actions without application-level checks.
These controls are especially important because memory can persist and later re-enter prompts.
Getting Started
Developers can install Oracle AI Agent Memory from PyPI:
pip install oracleagentmemoryThen configure an Oracle AI Database connection or pool, an embedder, and optionally an LLM for extraction, summaries, and context cards:
pip install --upgrade oracleagentmemory openai-agents oracledb
from oracleagentmemory.core import OracleAgentMemory
memory = OracleAgentMemory(
store=store,
llm=memory_llm,
memory_extraction_config=extraction_config,
)From there, applications can create threads, add messages, add durable memories, search by scope, filter by metadata, and build compact prompt context for agents.
Conclusion
Oracle AI Agent Memory gives developers more control over how AI agents remember and retrieve context. Faster extraction workflows help reduce latency. Hybrid search improves recall for both meaning and exact text. Custom extraction instructions make memory formation more domain-aware. Context cards help long conversations stay compact. Metadata filtering, update APIs, OracleDBEmbedder, chunked indexing, and logging diagnostics make the memory layer more practical for enterprise applications.
As agent workflows become longer and more stateful, memory becomes part of the application architecture. Oracle AI Agent Memory provides a database-backed foundation for agents that can remember, retrieve, compact, and continue with context.
Run the end-to-end support copilot notebook to see these capabilities working together in a continuous support workflow backed by Oracle AI Database.
Frequently Asked Questions
What is Oracle AI Agent Memory?
Oracle AI Agent Memory is a database-backed memory layer for AI agents. It helps applications store messages, durable memories, metadata, summaries, and prompt-ready context using Oracle AI Database.
How do AI agents store persistent memory?
AI agents can store persistent memory by writing conversation messages, extracted durable facts, preferences, and other memory-like records to a persistent store. Oracle AI Agent Memory uses Oracle AI Database as that persistence layer.
Why use hybrid search for agent memory?
Hybrid search helps when an agent needs both semantic recall and exact matching. Semantic search can retrieve memories by meaning, while text matching helps with identifiers such as issue IDs, SKUs, invoice numbers, aliases, and error codes.
How do custom memory extraction instructions work?
Custom memory extraction instructions guide what should become durable memory. They help the application preserve domain-specific facts, preferences, and workflow state while ignoring small talk or temporary details.
What should an AI agent remember or ignore?
An AI agent should remember information that helps future interactions, such as durable user preferences, decisions, task state, policy-relevant facts, and important identifiers. It should avoid preserving irrelevant, temporary, sensitive, or low-value details unless the application has a clear reason to store them.
How do context cards help long-running conversations?
Context cards compact long conversations into prompt-ready context. They can include a summary, retrieval topics, relevant memories, and recent messages so the agent can continue without replaying the full transcript.
Resources
- Oracle AI Agent Memory documentation
- Oracle Database 26ai documentation
- end-to-end support copilot notebook
- AI Vector Search documentation
- From RAG to Memory Systems: Building Stateful AI Architecture
- Which Agent Memory Approach Is Best for Long Conversations?
- Oracle AI Agent Memory: A Governed, Unified Memory Core for Enterprise AI Agents
- End-to-end Oracle AI Agent Memory support copilot notebook