Long-term memory in Oracle Cloud Infrastructure (OCI) Generative AI carries selected context across conversations, helping agents continue without asking users to repeat the same background information. 

An AI agent can handle every turn in a conversation and still create a disconnected experience when the user starts a new conversation. 

The reason is simple: a new conversation is usually a new context. Preferences, constraints, and background established in an earlier conversation are not available automatically. Without a deliberate way to carry selected context forward, users may need to repeat information, agents may ask familiar questions, and an ongoing workflow can feel fragmented. 

The cross-conversation problem 

Without durable context, agent applications often face three practical issues: 

  • Repeated setup. Users may need to restate stable preferences and recurring background when they open a new conversation. 
  • Inconsistent experiences. Separate conversations for the same user or workflow can begin with different assumptions, even when the underlying task is part of an ongoing process. 
  • Application complexity. Developers must decide what history to retain, how to find the relevant parts, and how to inject them into future requests without replaying every prior transcript. 

A larger context window can hold more information in a single request, but it does not, by itself, make context persistent across separate conversations. The application still needs a deliberate way to carry useful context forward. 

Long-term memory: selected context that can cross conversations 

Long-term memory in OCI Generative AI provides persistent context across conversations within a project. When the feature is enabled, the service extracts key information from conversations, stores that information as searchable embeddings, and can retrieve matching context in later conversations. 

Long-term memory can support use cases such as remembering stable user preferences, retaining recurring background, and helping maintain continuity across interactions. The important word is selected: long-term memory is not a promise to record every statement or replay a complete transcript. 

Diagram showing how conversations within the same project and using the same memory_subject_id share long-term memory. Conversation 1 provides preferences for the Chicago region and concise Python examples. Three steps show how this information is processed: extract and condense useful context, create embeddings and store searchable vectors, and retrieve relevant memory. When Conversation 2 asks how to call the Responses API, retrieval returns the stored preferences to inform the response. New context from Conversation 2 can also update the shared memory when writing is enabled.
A write-enabled conversation contributes selected information that is extracted, embedded, and stored in project-scoped long-term memory. A later conversation can retrieve relevant memory to inform its response and, when write-enabled, contribute new information back to the same shared memory. 

The memory_subject_id metadata field identifies a long-term-memory subject within a project. Conversations created with the same value share the same long-term-memory space. A new conversation can therefore begin with a different conversation ID while still using relevant context associated with that subject. 

A practical example 

Consider an internal developer-support agent. During one conversation, a user says: 

My preferred OCI region is US Midwest (Chicago), and I prefer concise Python examples. 

Days later, the user opens a new conversation and asks: 

Show me how to call the OCI Responses API. 

If both conversations use the same memory_subject_id and the second conversation’s access policy permits recall, long-term memory can make the stored preference available as context. The agent can use that context when generating a concise Python example and, when relevant, reference the preferred region. 

The application assigns the subject identifier and memory access policy. OCI Generative AI processes extraction and recall within the project according to those settings. A compact implementation pattern looks like this: 

subject = "user_123456"  # Use a pseudonymous application identifier. 
 
first = client.conversations.create( 
    metadata={ 
        "memory_subject_id": subject, 
        "memory_access_policy": "recall_and_store", 
    } 
) 
 
client.responses.create( 
    model="<supported-model-id>", 
    conversation=first.id, 
    input="My preferred OCI region is Chicago, and I prefer concise Python examples.", 
) 
 
# Memory extraction is asynchronous; allow processing before a later recall. 

later = client.conversations.create( 
    metadata={ 
        "memory_subject_id": subject, 
        "memory_access_policy": "recall_only", 
    } 
) 
 
response = client.responses.create( 
    model="<supported-model-id>", 
    conversation=later.id, 
    input="Show me how to call the OCI Responses API.", 
) 
 
print(response.output_text)

The snippet focuses on memory metadata. The OCI Responses API documentation covers client configuration, regional endpoints, authentication, project OCIDs, and supported models. 

Memory with explicit boundaries 

Persistent context is most useful when applications can control where it applies. OCI provides two boundaries. 

First, projects isolate conversations, responses, files, containers, and memory settings. A memory_subject_id is scoped to its project; using the same text in another project does not join those memory spaces. 

Second, each conversation can set a memory_access_policy: 

  • recall_and_store recalls existing context and allows new information to be stored. This is the default. 
  • recall_only can use existing memory without adding new information from that conversation. 
  • store_only can contribute information without recalling existing memory. 
  • none neither recalls nor stores memory. 

These controls allow an application to distinguish, for example, between a personalized conversation, a conversation that should only use existing context, and a conversation that should not participate in long-term memory. 

How long-term memory differs from short-term memory and RAG 

Long-term memory is complementary to other context mechanisms. 

Short-term memory carries context within an ongoing conversation. Short-term-memory compaction can reduce the amount of earlier conversation history sent to the model while preserving key details. Long-term memory carries selected context across separate conversations associated with the same subject. 

File Search and retrieval-augmented generation (RAG) retrieve information from documents or other curated knowledge sources. They are a natural fit for policies, product documentation, contracts, and other authoritative content. Long-term memory derives reusable context from prior interactions, such as preferences and recurring background. 

An enterprise agent can use both: RAG for the source of truth and long-term memory for continuity. Memory should inform the interaction, but fast-changing or consequential business facts should still be verified against the appropriate system of record. 

Design for remembered context 

Long-term memory changes an agent from a sequence of isolated chats into a more continuous experience. That makes several design decisions important: 

  • Choose a stable, pseudonymous memory_subject_id that matches the continuity boundary in your application. 
  • Apply memory_access_policy deliberately instead of treating every conversation the same. 
  • Plan the project lifecycle before enabling the feature. Extraction and embedding model availability varies by region. Under current documentation, the selected models cannot be changed after configuration, and long-term memory cannot be disabled or deleted unless the project is deleted. 
  • Set response and conversation retention according to your data-handling requirements, and account separately for the project-level lifecycle of long-term memory. 
  • Evaluate extraction and recall with representative conversations. The service extracts key information; applications should not assume that every detail will be stored or recalled. 

Long-term memory is now part of Enterprise AI Agents in OCI Generative AI. Combined with the OCI Responses API, Conversations API, project scoping, and per-conversation access policies, it provides a managed capability that can help applications carry selected context across conversations. 

Get started