Every user has had the same frustrating chatbot experience.
You explain a problem. The conversation ends. The next day, you come back and have to explain the same thing all over again.
Long-term memory promises to solve that. But in an enterprise system, "remembering" is never just a convenience feature. It is also a question about data, trust, and control.
Oracle Fusion AI Agent Studio now supports long-term memory for agents. Before enabling it, every functional consultant should be able to answer one simple question:
What would we be comfortable letting this agent remember, and what should it never remember?
What Oracle means by long-term memory
Oracle describes two kinds of memory.
The first is episodic memory. This captures summaries of past interactions, tasks, cases, and activities. Oracle calls these summaries memory notes. They are maintained per user and per agent. When the user starts a new conversation, the agent can search relevant notes and bring useful context into the current conversation.
The second is user preferences. These are preferences about how a user likes to interact, such as response format, tone, communication style, or level of detail. Unlike episodic memory, user preferences can be shared across agents.
That distinction is important.
"This buyer prefers a short table before a detailed explanation" is a preference.
"This buyer told the agent about a sensitive supplier dispute last month" is interaction history. It needs much more care.
Where long-term memory can genuinely help
Repeated exception management
A cost accountant may be working the same close exception over several days. The agent can avoid asking for the same background each time and can remind the user what has already been checked.
Supplier and sourcing follow-up
A sourcing manager may return to the same negotiation or supplier issue. The agent can maintain continuity in the conversation without pretending it has a human memory of every business event.
Personal working style
Some users want a short answer first. Others want the transaction context, the risk, and the next action. Preferences can make the experience feel less generic without changing the business rule.
Where memory can become risky
Long-term memory should not become an uncontrolled notebook for enterprise data.
Do not enable it because it sounds advanced. Start with a clear purpose and a strict boundary.
Ask these questions before design begins:
- Could a memory note contain personal, confidential, supplier-sensitive, or commercially sensitive information?
- Is the information still correct when the agent sees it again?
- Who owns the policy for what is remembered?
- How will users know that memory is enabled?
- What is the retention and removal process for your organisation?
- Can memory create an incorrect assumption in a new context?
- Does a preference shared across agents make sense for every agent?
If your team cannot answer these questions, start with no memory and add it later after governance is agreed.
A safe first use case
The safest first use case is often a working-style preference, not a transaction detail.
For example, allow a user to say:
"When I ask about period close, show the highest-risk exceptions first and keep the answer short."
This is useful. It does not change the decision rule. It does not give the agent permission to reveal extra data. And it can be tested easily.
The next step might be carefully controlled episodic memory for a single agent that handles recurring operational exceptions.
Do not start with an agent that remembers everything from every user conversation.
A practical memory design checklist
Before enabling long-term memory, document the following.
1. Business purpose
What problem does memory solve that a normal conversation cannot solve?
2. Memory boundary
Which agent uses the memory? Which users? Which information categories are allowed? Which are prohibited?
3. Source of truth
Memory can help conversation continuity. It must not replace live Fusion data. If the user asks for a PO status, the agent should still use the approved business object or tool to retrieve current status.
4. Security review
Review the feature with Security, Privacy, and the business data owner. Treat memory notes as potentially sensitive agent data.
5. Test cases
Test a user returning to a previous conversation. Test the same user talking to a different agent. Test a change in the underlying transaction. Test a user who should not be allowed to see the historic context. Test an outdated memory note.
6. Support ownership
Name the team that will answer questions about unexpected memory behaviour. Without an owner, memory becomes a mystery feature that users stop trusting.
The rule that matters most
Memory can inform the conversation. It should not quietly become the source of truth for a business action.
Use live, authorised Fusion data for current transaction facts. Use memory only to make the conversation more helpful and continuous.
Final thought
The goal is not to make an Oracle Fusion agent feel human. The goal is to make it consistently helpful without making users wonder what it knows about them.
That is the standard worth designing for.
Checked Long-term (episodic) memory confirmed as a 26C AI Agent Studio capability against Oracle's AI Agent Studio 26C documentation; verified 25 Jul 2026. Behavior varies by release and configuration; verify in your own instance and test before acting.