Oracle Adds Cross-Conversation Memory to Enterprise AI Agents

A new chat with an enterprise AI agent no longer has to start from scratch. Oracle says long-term memory is now part of Enterprise AI Agents in OCI Generative AI, allowing selected details from earlier conversations to inform later ones. The continuity comes with a consequential setup decision: under Oracle's current guidance, removing long-term memory requires deleting its project.

A shared subject, not a shared transcript

A fresh conversation normally lacks the preferences and background established in an earlier one. A larger context window can hold more material in a single request, but it does not make that material persist between conversations. Oracle's feature addresses that gap by extracting key information from eligible chats, storing it as searchable embeddings and retrieving relevant context later. Embeddings are searchable representations of the extracted information, not copies of every conversation.

The application assigns a memory subject identifier to each conversation. Conversations using the same identifier can share a memory space, even when they have different conversation IDs. That identifier works only within its project: the same value in another project does not connect the two memory spaces. Oracle advises using a stable, pseudonymous identifier that matches the application's intended continuity boundary.

Each conversation gets its own permissions

Sharing a subject identifier does not mean every chat must use memory in the same way. Applications set an access policy for each conversation, separately controlling whether it can recall existing context or contribute new information. The default permits both. A team could therefore let one conversation use a preference without allowing anything said there to become future memory.

The four access settings

• recall_and_store uses existing memory and permits new information to be saved. It is the default.
• recall_only uses existing memory but does not add information from that conversation.
• store_only can add information without recalling what was already saved.
• none neither recalls nor stores memory.

Oracle illustrates the handoff with a developer-support agent. A user supplies a preferred cloud region and asks for concise Python examples in one conversation. Days later, a new conversation can use those preferences when the user asks for an API example, provided both chats have the same subject identifier and the later one's policy allows recall. Extraction happens asynchronously, so a later chat must allow time for the earlier information to be processed.

The project-level commitment

The conversation settings offer fine control over future use, but they do not undo the project-level setup. According to Oracle's current guidance, the extraction and embedding models chosen during configuration cannot be changed. Long-term memory also cannot be disabled or deleted unless the project itself is deleted. Model availability varies by region, making the choice of project setup important before the feature is enabled.

Oracle advises setting response and conversation retention to meet data-handling requirements while accounting separately for long-term memory's project lifecycle. Those are different decisions: choosing how long to retain conversations does not replace a plan for the memory associated with the project.

Useful context, not a record of truth

This memory serves a different purpose from a document search system. File Search and retrieval-augmented generation bring in curated sources such as policies or contracts; long-term memory draws reusable context from earlier interactions. Oracle says agents can use both, but fast-changing or consequential business facts should still be checked against the appropriate system of record.

Nor should a saved preference be treated as a guarantee of recall. Oracle says the service selects key information rather than recording every statement, and advises testing extraction and retrieval with representative conversations. The useful test for an application is whether the details its users need actually survive the move to a new chat.