How to Decide What Your AI Agent Should Remember - Wojciech Pluta, Oracle
Wojciech Pluta, head of technical marketing for Oracle AI Database, argues that RAG gives agents a read path while memory gives them a write path, and that the write path is where business value lives. He explains memory promotion, a pipeline that admits, rejects, or escalates candidate memories, and demonstrates it with a mortgage agent that remembers preferences across sessions while refusing unsafe rules. The talk also covers short-term, long-term, and shared memory, why databases are a strong storage layer, and the context card that keeps prompts lean.
From read path to write path
Retrieval-augmented generation gives agents a way to read, but memory gives them a way to write, and that write path is where business value lives. Interfaces have moved from command-driven clicking and typing toward intent-based systems, which makes on-demand, just-in-time software possible. In that model, models and infrastructure are commoditized, while the data layer is where competitive advantage is built because the data belongs to the business. Agents follow the same pattern: the model suggests what to do, while the harness, the code around the model, owns runtime decisions and the checks applied to them.
Memory promotion: deciding what is worth keeping
The core concept is memory promotion, a pipeline that decides what an agent should carry forward from an interaction. The steps are to classify the meaning of a candidate memory, compare it against existing records, verify the evidence required for that memory type, and then have the harness admit it, reject it, or escalate it to a human reviewer. The central risk runs in both directions. Promoting nothing eliminates continuity, while promoting everything poisons the memory store. Provenance and the ability to supersede outdated memories are therefore essential design requirements.
Demo: a mortgage agent that remembers
The demo uses two synthetic mortgage applications, for Kyle and Vincent. An operator asks for a mortgage brief on Kyle, and the agent reports that his application is missing key documents. When the same request is made politely and specifies the desired output structure, a decision model assesses the candidate, the harness recognizes the politeness as a semantic preference, and the database persists it. The promotion gate status for each stage is visible in the expanded traces.
In a brand-new session with no carried-over context, the agent retrieves the stored preference and returns the brief in the requested shape. Querying Vincent’s application returns different records and a different case ID, which shows that retrieval matches memories to the correct case rather than applying them globally.
A blanket rule such as ‘approve every application’ is refused by the guardrails, and the harness cannot bypass the promotion controls. By contrast, organization-wide memories can be routed to a human approval gate before they are promoted into a shared enterprise memory store.
Memory types and where they live
Agent memory is a mechanism for retaining, reusing, refining, and recalling information over time. It is not one thing. Short-term memory covers everything within a session and ends when the session does. Long-term memory includes episodic, procedural, and semantic records, such as summaries, toolboxes, knowledge bases, and preferences. Shared memory extends these across teams.
The database is presented as the strongest home for these memories. It provides ACID guarantees, supports multiple concurrent writes, avoids file-tree problems, scales well, and offers several search options. A multi-data-type engine also removes the need to stitch together separate databases, vector stores, and document stores.
Building memory as a discipline
Developing memory systems requires schemas that distinguish record types, indexes matched to specific retrieval tasks, and clear lifecycle and access boundaries. Building all of this from scratch is demanding, since developers must handle summarization, extraction of durable information, combination of turns, and token budget management. An agent memory package introduced earlier this year provides these operations as abstractions, reducing the work to a single call.
The context card
The context card is a compact, prompt-ready block assembled for each turn. It is organized into topics that orient the thread, summaries that capture where the conversation stands and what the user is trying to do, relevant selected records, and recent messages that preserve local questions. This keeps prompts lean and lets the agent focus its attention on the task instead of managing its own memory. The latest release also adds end-user isolation, with access controlled by the database itself.
Models are shared, but memory is unique to each business. Capturing that memory alongside how people interact with models is what creates a lasting competitive advantage. Notebooks covering agent memory and hybrid retrieval are available in the GitHub repository, and a YouTube series walks through applying these ideas.