Loading page…
Version 26.8 can retrieve the history behind a changed preference or promise, but applications still need to decide which relationships to trust.
Listen to this story
Oracle’s AI Agent Memory 26.8 gives developers ways to keep competing versions of a fact linked rather than treating them as equally current or deleting the older record. Graph Memory supports explicit links from confirmed workflows and automatic candidate links during or after extraction; Oracle provides no accuracy evidence for the inferred route. Adoption requires managed schema version 13, and graph-aware retrieval can be bounded by link depth and result count.
Links can mark records superseded, refined, supporting, contradicting, or duplicate; invalidated records remain stored, preserving history.
Developers can disable automatic linking; extraction-time candidate linking adds prompt work, while post-write linking is the default.
Image searches use supplied descriptions or generated captions and do not return raw image bytes by default.
An AI agent that remembers an old delivery promise needs more than a newer search result. It needs to know the promise changed. Oracle’s AI Agent Memory 26.8 adds links between saved records so an agent can retrieve a current fact alongside the history that explains it. The release also adds image-aware memory and controls for managing stored context.
Oracle calls the new feature Graph Memory. It connects memory records with directed, named relationships: one record can supersede, refine, support, contradict or duplicate another. In Oracle’s support example, a revised delivery window can supersede an earlier preference. The link gives a future agent a reason to favor the new record, rather than treating two different delivery times as equally current.
A superseded, refined or duplicate memory can become invalid without being deleted. That distinction lets the application retain a trail of what changed. Search still starts with a direct match, but graph-aware retrieval can follow links to bring back related records. Developers can limit how far it follows those links and how many linked results it returns.
Applications can create a link explicitly when a workflow confirms the relationship. A replacement shipment, for instance, could supersede an earlier delivery commitment. That route uses information the application already knows; it does not ask memory extraction to infer what happened.
Oracle also offers automatic linking as memories are extracted. The default mode looks for candidate relationships after writing new memories; another mode presents candidates during extraction. Developers can turn automatic linking off. Oracle says the during-extraction approach can improve relationship quality, but requires more work inside the extraction prompt.
That leaves a judgment at the heart of the feature: a confirmed workflow event and an inferred relationship are not the same kind of evidence. Oracle provides both paths, but its announcement does not establish how accurately automatic linking will identify changed or conflicting facts in a particular application.
Graph Memory needs a database change, not just a new search setting. Managed schema version 13 adds a table and indexes for memory links, fields that track record status, and an Oracle SQL Property Graph over memories and links. Oracle’s companion notebook shows how to create or upgrade the schema for a demonstration. For production startup after migration, Oracle advises requiring an existing schema so upgrades remain deliberate.
The notebook compares ordinary and graph-aware search using a small support scenario. It also shows explicit links before turning to automatic linking. That makes it a way to inspect the new behavior, rather than a demonstration of how every relationship will hold up in a larger memory store.
Version 26.8 also lets applications persist images as document records and search them through supplied descriptions or generated captions. A support screenshot or receipt can therefore become durable context. Oracle says image search does not return the raw image bytes by default, a distinction between finding a relevant image record and sending the image itself back to an agent.
The release also includes metadata scoping, Oracle Deep Data Security integration, persisted summaries and pruning support. Those controls address a different consequence of persistent memory: keeping stored context within an intended scope and manageable over time. The central test for linked memory remains whether an application can preserve useful history while consistently putting the current fact first.
Story updates
Oracle is putting the database, rather than the AI application, in charge of who can read and write an agent’s stored memories. In an October 6 explanation, the company details how its September 22 Agent Memory release connects identity checks to database permissions—and why those controls alone do not make shared memory ready for production.
Oracle AI Agent Memory organizes records by user, agent and conversation thread. Those labels establish which records belong together, but they do not authenticate the person requesting access. Oracle explicitly warns against treating a user ID supplied by an application as evidence of identity.
Release 26.8 connects that memory store to Oracle Deep Data Security, which enforces access rules inside the database. The signed-in user’s identity token travels there with the request. The database checks it and applies the relevant policy on every memory read and write, rather than leaving that decision to application code.
Oracle’s implementation guide makes the boundary concrete. Its small web application lets Alice save a memory for herself, but the database rejects her attempt to save one for Bob. The application route does not compare their names; it forwards the end-user token for the database to enforce the ownership rule.
The guide distinguishes two credentials: one identifies the end user and their identity-management groups; the other proves the application may access the database. Oracle AI Database validates both before attaching the user’s security context—the identity and permissions used for that request.
The example also separates administrator, schema-owner and application accounts. The application account receives no direct table-reading or table-writing privileges. Without a valid end-user context, the request is denied.
Oracle identifies another problem with shared memory: automated extraction can create an incorrect record before anyone reads it. Controlling who may write therefore does not settle whether the content should be trusted. Its article argues that shared systems need controls over what gets stored, too.
For later reviews of an agent’s decision, Oracle recommends keeping two complementary records:
Log the user, time and memories shown to the model when an answer matters.
Enable Flashback Time Travel on relevant tables, such as prices and policies, to inspect their contents at that moment.
Retaining that history can conflict with the right to erasure, Oracle cautions. Teams must decide how deletions reach historical records before enabling it.
The implementation guide expressly forbids production deployment of its example. It uses a development server, in-memory sessions, environment-file secrets and simplified token handling. Its setup scripts also change database-wide identity settings and privileges, so Oracle directs users to disposable accounts in an isolated, non-production database.
oracle.comLoading discussion...
Join the conversation
When would you trust that decision, and when would you want a check?
Be the first to share a perspective or an experience.
Reader comments
Newest comments first. Replies stay oldest first.