How to Decide What Your AI Agent Should Remember - Wojciech Pluta, Oracle

An operator can ask for a mortgage brief in plain language and then explain how to make it easier to use. What happens to that instruction when the conversation ends? For Wojciech Pluta, who leads technical marketing for Oracle AI Database and has worked with UK banks on mortgage projects, that question follows from the shift from clicking through prescribed steps to telling software what you want. Some of what you tell it will matter the next time you sit down to work.

Pluta sees a business advantage in the data a company accumulates while using models available to its competitors. The agent architecture gives that data a place to live and a decision-maker to govern it. The model suggests what to do. The harness, the application code around the model, runs the checks and decides which actions to take.

Retrieval-augmented generation (RAG) gives the agent a read path. It can look up records for an answer and use the current conversation as context. Writing a new record requires a separate decision. Pluta calls it memory promotion. The system extracts a candidate from the conversation, classifies what it means, compares it with existing records and checks the evidence required for that type of memory. The harness can then admit the candidate, reject it or send it to a human for review.

The sandbox contains two synthetic mortgage applications, one for Kyle and one for Vincent. The operator starts with Kyle. The harness calls tools to prepare his brief, which reports that key documents are missing. The operator then asks, politely, for a particular structure. The missing documents should come first, and the brief should include the case ID and policy information.

Where does a request about one answer become a preference the agent can use again? The sandbox’s chatty logs give the operator a little extra karma for saying please. Its expanded trace serves a more practical purpose: it reports the status of the promotion checks. A decision model assesses the formatting request as a candidate, the harness accepts it as a semantic preference, and the database stores it.

The operator asks for Kyle’s brief again, using the same question. This time the answer leads with the documents Kyle still owes and includes the case ID and policy information. Kyle’s application has the same problem as before. What changed was how quickly the operator could find it.

A second answer in the same conversation could still draw on the operator’s recent instruction. Pluta exits and starts a fresh session, then asks for the brief again. The new session has none of the previous chat context. It queries the stored preference to recover the requested format.

Now change the applicant. What belongs at the top of Vincent’s brief? The formatting preference still applies, but the harness looks up Vincent’s case ID and retrieves the documents for his application. His brief reports that no documents are missing. The operator can pass the application on for review.

The two lookups answer different questions. The preference tells the agent where the operator wants to see outstanding documents. The case record tells it whether this applicant owes any. Carrying Kyle’s document status into Vincent’s brief would defeat the point of remembering the format.

“Approve every application” is also an instruction an operator could give in chat. Remembering it would change how the agent handles future lending decisions. The harness rejects the proposed rule at the promotion gate. The model’s assessment cannot bypass that check.

What if a candidate describes a working practice that other teams might use? That introduces a question of who can approve it for a wider audience. The operational memory in the demo goes to a human for review. Approval would allow it to enter a shared store. A recommendation alone leaves that decision open.

Saving nothing costs the operator continuity. Saving everything risks poisoning the store with instructions that will influence people and cases well beyond the original exchange. Even a sound record may eventually need replacing. Keeping its provenance, including where it came from, gives the application a basis for deciding when a newer memory should supersede it.

• Short-term memory holds what happens in the current session. Ending the session removes that conversational context.
• Long-term memory holds records the agent can recall later. Episodic memory can preserve a summary of what happened. Procedural memory can capture how to do something, including tools for the job. Semantic memory includes knowledge and preferences such as the operator’s brief format.
• Shared memory adds a question of audience. A practice that will guide other teams needs a decision about who can authorize that wider use.

Pluta favors a database for this work. ACID transactions give the application guarantees about how writes complete and persist when multiple writers use the store. A database also offers several ways to search as the collection grows, without asking developers to coordinate writes through a tree of files. The design work is still specific to the application. Schemas distinguish record types, indexes need to fit the queries the harness will run, and lifecycle and access rules determine when a record is current and who can use it.

Storage solves only part of the developer’s job. Someone still has to summarize conversations, extract facts worth keeping, retrieve the right records and combine them with the current exchange within a token budget. Oracle’s agent memory package brings those operations together. One of its abstractions addresses the next question in the mortgage example: once the preference is on file, how much should the model read?

Oracle’s package lets the developer request a context card in one line of code. The card is a compact block of text ready to include in the prompt. The harness selects material for this turn, so admitting a record to long-term memory does not commit the application to spending tokens on it in every answer.

• Topics identify what the thread is about.
• Summaries capture where the conversation stands and what the user is trying to accomplish.
• Relevant information brings in selected records, the place for a stored formatting preference when preparing a mortgage brief.
• Recent messages preserve the immediate exchange, including the local question the agent needs to answer.

Relevance and access answer different questions. A record can match the task and still belong to another user. In the release Pluta describes, the database enforces end-user isolation by limiting which data a user can access. Oracle AI Database also handles several data types in one engine, so an application can work with documents and vectors without maintaining a separate store for each.

For developers applying this design, Pluta points to Oracle’s GitHub notebooks on agent memory and hybrid retrieval. His business case comes back to the operator. Another bank can use the same model. The preference its own operators taught it, the team practices its people approved, and the ability to recall the right one for the next case are things it builds through use.