SFMC Tips #396 : Agentforce: How Agent Memory Works and How It Differs from Variables
With the September 2026 Agentforce feature release, Agent Memory became generally available, allowing agents to remember relevant information from previous conversations with users and use it in new conversations.
Meanwhile, the July 2026 Data 360 feature release also introduced a feature called Agentic Memory and Context.
I introduced Agentic Memory and Context in an earlier article. The two have similarities not only in their names but also in their purpose of remembering past conversations.
However, Agent Memory and Agentic Memory and Context are separate features provided by Salesforce.
Another question is whether Variables, which have traditionally been used in Agentforce, become unnecessary if agents can automatically remember past conversations.
Furthermore, where is Memory stored, and how long is it retained?
This article examines how these two features work, their advantages and disadvantages, their differences from Variables, where information is stored and how long it is retained, and the organization-wide Memory controls added in October 2026.
① Agent Memory in Agentforce Builder
Agent Memory is a feature that remembers relevant information obtained from previous conversations between the same agent and user and uses it in subsequent conversations.
For example, if a user tells an agent, “I would like answers summarized in bullet points,” that preference can be saved as Memory and reflected in the answer format in a future conversation.
The important point is that developers do not need to define the information to be remembered in advance as Variables.
Agentforce determines relevant information from conversation content and saves it as Memory.
However, not all information from a conversation is saved, and not all saved Memory is necessarily used in every subsequent conversation.
The agent uses relevant information from saved Memory as Context when generating an answer.
Agent Memory supports both Agentforce Employee Agent and Agentforce Service Agent.
Agentforce Employee Agent: In Lightning Experience, users must opt in to Memory usage themselves. They can view, edit, and delete saved Memory under Memory & Preferences.
Agentforce Service Agent: A separate opt-in procedure is not required. To allow users to view, edit, and delete Memory through conversations, you must add the User Memory Management subagent.
Setup Instructions
1. Enable Agent Memory and User Profile
Open the target agent in Agentforce Builder and switch to Script View.
Add the following settings to the existing context block.
context:
memory:
enabled: True
user_profile:
enabled: TrueThese settings serve the following purposes.
- memory: Remembers information obtained from past conversations and uses it in subsequent conversations.
- user_profile: Adds available Profile information for the associated user to Context.
2. Add User Memory Management
Add the standard asset so that customers can manage Memory through conversations with requests such as “What do you remember?” and “Please forget this information.”
In Agentforce Builder, open Asset Library from Subagents and add User Memory Management.
This subagent appears only when Enable Conversational Memory for Agentforce is enabled under Einstein Audit, Analytics, and Monitoring Setup in Setup.
This subagent contains the following standard Actions.
- Get User Memories: Retrieves saved memories.
- Manage User Memory: Creates, updates, and deletes memories.
- Get Agent Memory Preference: Checks Memory usage preferences.
- Update Agent Memory Preference: Changes Memory usage preferences.
3. Identify the Customer in a Service Agent
In my environment, adding this standard subagent alone did not work properly.
The execution user under which the Service Agent runs is different from the customer participating in the conversation. When managing Memory for each customer, the agent execution user’s ID must not be passed directly as the customer ID.
Some configurations can receive authenticated customer information from the channel. In this article, however, I explain how I made it work using standard Service Customer Verification, with identity verified through a code sent by email.
This does not mean that this authentication method is mandatory for every Service Agent. If reliable authenticated participant information is already available, use the configuration appropriate for that information.
① Add the Standard Asset
First, I added the Service Customer Verification subagent from Asset Library. This subagent primarily uses the following two Actions.
- Send Email with Verification Code: Searches for the customer and sends a verification code by email.
- Verify Customer: Verifies the entered verification code.
② Pass Values Between Actions
After adding the standard asset, check whether the output of the sending Action is passed to the input of the verification Action.
Depending on the template, this may already be configured. In that case, there is no need to create duplicate variables.
If it is not configured, prepare internal variables such as the following in the existing variables block. The variable names below are examples used in this article.
variables:
VerificationKey: mutable string = ""
description: "Authentication key returned by the verification email action."
visibility: "Internal"
VerificationCustomerId: mutable string = ""
description: "Customer ID returned by the verification email action."
visibility: "Internal"
VerificationCustomerType: mutable string = ""
description: "Customer type returned by the verification email action."
visibility: "Internal"
IsVerifiedCustomer: mutable boolean = False
description: "Verification result returned by VerifyCustomer."
visibility: "Internal"
VerifiedCustomerId: mutable string = ""
description: "Customer ID returned by VerifyCustomer after successful verification."
visibility: "Internal"Configure the Action calls within the reasoning section of Service Customer Verification to store outputs and assign inputs.
The following example assumes that the Action reference names are SendEmailVerificationCode and VerifyCustomer. It is not code intended to replace the entire Action definitions of the standard asset.
actions:
SendEmailVerificationCode: @actions.SendEmailVerificationCode
with customerToVerify=...
set @variables.VerificationKey = @outputs.authenticationKey
set @variables.VerificationCustomerId = @outputs.customerId
set @variables.VerificationCustomerType = @outputs.customerType
VerifyCustomer: @actions.VerifyCustomer
with authenticationKey=@variables.VerificationKey
with customerCode=...
with customerId=@variables.VerificationCustomerId
with customerType=@variables.VerificationCustomerType
set @variables.IsVerifiedCustomer = @outputs.isVerified
set @variables.VerifiedCustomerId = @outputs.customerIdCustomers enter their email address or similar information and the verification code they receive.
Authentication Key, Customer ID, and Customer Type are internal information passed between Actions. Customers are not asked to enter them.
In particular, the Authentication Key and the verification code received by email are different values.
Keep the standard asset’s identity verification steps and the settings that prevent internal information from being exposed to customers. If the configuration supports repeating verification, clear the previous verified state when restarting verification so that old results are not reused.
4. Pass the Verified Customer ID to Memory
In this configuration, the results of identity verification are passed to the Memory Actions.
Assign the verified customer ID to the Authenticated Participant ID of Get User Memories and Manage User Memory.
Configure the Action calls in the reasoning section of User Memory Management as follows. Match the Action reference names to the script of the asset that was added.
actions:
GetUserMemories: @actions.GetUserMemories
available when @variables.IsVerifiedCustomer == True and @variables.VerifiedCustomerId != ""
with searchQuery=...
with authParticipantId=@variables.VerifiedCustomerId
ManageUserMemory: @actions.ManageUserMemory
available when @variables.IsVerifiedCustomer == True and @variables.VerifiedCustomerId != ""
with userConversation=...
with agentContext=...
with authParticipantId=@variables.VerifiedCustomerIdDo not delete standard call settings or Action definitions not shown here, including Get Agent Memory Preference and Update Agent Memory Preference. Separately verify that the appropriate customer is correctly identified when checking or changing Memory preferences.
This configuration explicitly specifies two things.
- Memory retrieval and modification Actions are available only when identity verification has succeeded and a customer ID exists. In other words, anonymous access is not permitted in this configuration.
- The target customer ID is passed from the verified variable rather than allowing the LLM to guess it.
Add the following to the existing Instructions of User Memory Management.
Use only VerifiedCustomerId after IsVerifiedCustomer is True for memory reads and writes.
Never ask the customer for an internal Salesforce ID or infer it from conversation text.
If verification is missing, guide the customer to identity verification first.
For memory requests, call the corresponding action and base the response on its result.
If the action fails or reports that no operation was performed, do not imply that the memory was saved.This does not mean that the standard asset is always unable to identify the customer. In a configuration such as this one that uses the result of an identity verification Action, that result needs to be explicitly connected.
5. Verify Saving, Retrieval, and Carryover to Another Conversation
Save your changes and verify their behavior. When testing on a published channel, Commit → Activate the relevant version.
Verify Saving and Retrieval Within the Same Conversation
First, complete identity verification.
After verification, say the following.
- “I enjoy mountain climbing. Please remember this so it can be used in future conversations.”
You can clearly see that Memory is being updated.
Next, ask:
- “Tell me what you remember about me.”
The agent responds:
- “The user enjoys mountain climbing.”
Next, Verify in a New Conversation
End the current conversation and start a new one.
Verify your identity again, identify yourself as the same customer, and ask:
- “Tell me what you remember about me.”
The same information is returned even in the new conversation after the previous session has ended.
Also Test Adding, Updating, and Deleting
I tried the following requests.
- “I am a woman.” (Add)
→ The information that the user is a woman was added.
- “Delete mountain climbing as my hobby and change it to camping.” (Update)
→ The hobby was changed from mountain climbing to camping.
Note: At present, a direct update request is not possible. You need to combine a deletion instruction and an addition instruction.
Advantages
A major advantage is that it can be enabled relatively easily from Agent Script.
For basic use, you do not need to individually configure Data Streams, DMOs, Identity Resolution, or similar components in Data 360.
Because relevant information is automatically remembered from conversations, developers also do not need to define every piece of information to be remembered in advance.
Users can also view, edit, and delete saved Memory, making it possible to correct outdated or incorrect information.
Disadvantages and Limitations
Agent Memory is limited to a maximum of 50 memories per user per agent.
When the limit is reached, older Memory is automatically deleted to make room for new Memory.
Memory automatically created from conversations is generally managed separately for each agent and is not automatically shared with other agents.
However, there also appears to be an exception, although I have not tested it.
When a user manually adds Memory from Memory & Preferences and selects All Agents, it can be registered as User-Level Memory available to multiple agents.
This User-Level Memory can hold up to 50 memories separately from each agent’s Memory.
Thus, Agent Memory can share some information across agents, but it does not automatically share everything remembered by each agent from conversations with all other agents.
② Data 360 Agentic Memory and Context
Agentic Memory and Context manages AI agents’ past conversations and information extracted from them in Data 360 and provides the necessary Context to agents.
It can extract and continuously use Facts, Preferences, Session Summaries, and other information about users from ingested conversations.
- Facts: Facts and information about users.
- Preferences: Users’ likes and preferences.
- Session Summaries: Summaries of conversations.
The GetContext API can also retrieve past conversations, accumulated Memory, and other information.
I tested its implementation in the following article shortly after the release.
A particularly important point is that information associated with Individuals or Unified Individuals in Data 360 can be used by multiple agents.
Get Nobuyuki Watanabe @marketingcloudtips’s stories in your inbox
Join Medium for free to get updates from this writer.
For example, if a user tells a product consultation agent, “I prefer lightweight products,” and this is extracted as Profile Memory, another support agent assisting the same user later can use that information.
However, information that can be shared across agents primarily includes user-associated Facts and Preferences; not all conversation history can be shared unconditionally.
Access controls based on user and agent identification information apply when retrieving conversations.
How to Use It
Agentic Memory and Context cannot be used simply by adding settings to Agent Script as with Agent Memory.
- First, register the agent in Data 360.
- When an agent is registered, the Data Space configuration and necessary infrastructure are automatically prepared in Data 360.
- Then use APIs to ingest conversations, extract Memory, and retrieve Context.
- Memory extraction is automatic, but implementation is required to ingest conversations and connect the retrieved information to agents.
- Furthermore, Facts, Preferences, and similar information are extracted periodically, so not all information is saved as Memory immediately after a conversation.
- On the other hand, ingested conversations and Session Summaries are described as becoming available for Context retrieval within seconds of ingestion.
Advantages
The greatest advantage is the ability to continuously use user information across multiple agents and conversations.
By using Unified Individuals through Data 360 Identity Resolution, Memory associated with multiple Individuals can also be retrieved in an integrated manner.
Access controls based on Data 360 Object-Level Security, Field-Level Security, and Record-Level Security are applied.
Another feature is that the Memory Management API can programmatically create, retrieve, update, and delete Memory.
Disadvantages and Limitations
Agentic Memory and Context requires a Data 360 environment.
Although the Data 360 configuration is automatically prepared when an agent is registered, actual use requires implementation of conversation ingestion, API integration, and related processes.
Consequently, its implementation and operation require a broader range of design and development than Agent Memory, which can be enabled in Agent Script.
As of October 2026, when this article was written, it is provided as Limited GA.
The Salesforce Developer Guide states that Agentic Memory and Context is “free” during Limited GA, but the formal pricing structure has not been announced.
In the future, Flex Credits are expected to be consumed for processes such as LLM-based Memory generation.
The statement that the feature itself is free during Limited GA does not mean that all related Data 360 processing is free.
Before using it in production, confirm the availability conditions, relevant Data 360 processing, and effects on credits.
③ Differences Between Memory, Context, and Variables
One natural question is whether Agent Memory or Agentic Memory and Context eliminates the need for Variables previously used in Agentforce.
The conclusion is that Memory, Context, and Variables serve different roles, so the arrival of Memory does not make Variables unnecessary.
First, let us clarify their respective roles.
- Memory: A mechanism for remembering preferences, wishes, and other information from past conversations and using them in subsequent conversations.
- Context: Information an agent refers to when answering or making decisions. It includes the current conversation, retrieved data, relevant Memory, and more.
- Variables: A mechanism for explicitly retaining values required for the current conversation state or business process and using them as Action inputs or for conditional branching.
Consider an agent that accepts registrations for internal training courses.
If a user previously said, “I would prefer to take online training,” Agent Memory can remember that preference and use it in the next conversation.
The agent can refer to past Memory and the current conversation as Context to recommend training appropriate to the user.
If the user then says, “I would like to register two people for next Wednesday’s Salesforce training,” the agent needs to obtain the training name, registration date, number of attendees, and other information and pass it to the registration process.
In such cases, Variables allow required values to be explicitly retained and passed to Actions such as Flow or Apex.
In other words, Memory remembers past information, Context provides information for the agent’s decisions, and Variables manage the values necessary for business processing.
Even if Memory retains past preferences, that information is not automatically assigned to Variables and precisely mapped to input fields on registration forms.
Similarly, with Data 360 Agentic Memory and Context, using information retrieved through the GetContext API for business processing requires integration that extracts the necessary values and passes them to Actions.
For information that requires accuracy, such as dates, numbers of people, and monetary amounts, it is important to confirm the user’s current wishes rather than treating past Memory as a confirmed value.
Agentforce also has Context Variables. These are variables for passing information about users, Sessions, and other entities to an agent, and they do not mean the entirety of Context described here.
It is therefore important to use Memory to leverage past information, Context to reflect it in the agent’s decisions, and Variables to control current business processing.
By combining these three appropriately, agents can provide natural responses that take past interactions into account while also performing accurate business processing.
④ Where Is Memory Stored, and How Long Is It Retained?
This is another important point for organizations using Agentforce.
For Agent Memory, Salesforce’s official help explains that users’ conversation data used for Memory is retained within Salesforce.
It also explicitly states that Data 360 is not required for the standard Get User Memories Action.
However, this does not mean that Agent Memory is not stored in Data 360.
A Salesforce technical article introduces an Agent Memory Platform based on Data 360. However, the official documentation I reviewed does not specifically state the database or object in which Agentforce Builder’s Agent Memory is stored. I would like to investigate this further. 🤔
In contrast, Agentic Memory and Context explicitly stores and manages conversations and Memory in Data 360. This is confirmed.
Memory Retention Period
For Agent Memory, I could not confirm a specific retention period, such as 30 or 90 days, in the official documentation available as of October 2026.
However, it is limited to 50 memories per user per agent, and when the limit is reached, older Memory is automatically deleted.
For Agentic Memory and Context, a mechanism is provided to manage Memory expiration through validTo.
Expired Memory is not physically deleted and can be made valid again by updating validTo.
However, the expiration date of Memory and the period for which the data is actually retained are separate matters.
I also could not find a specific number of days defining a uniform retention period for Agentic Memory and Context in the official documentation reviewed.
Therefore, when organizations use Memory, it is important to check policies on data retention and deletion, as well as limits on the number of saved memories.
⑤ Why Is There a Feature to Disable Memory?
In October 2026, a feature was added that allows Conversational Memory usage to be controlled for an entire organization at once.
Previously, Memory could be disabled individually for each agent through Agent Script. With this update, administrators can disable it in bulk from the organization-wide settings.
This raises a question: Agent Memory makes things more convenient for users, so why would it need to be disabled?
Remembering past information can certainly eliminate the need for users to repeat themselves and may allow agents to provide more appropriate answers.
However, in an enterprise, remembering past information is not necessarily desirable for every business process.
For example, consider the following cases.
1. When Handling Personal or Confidential Information
Agents handling HR consultations or internal confidential information may encounter personal or highly sensitive information in conversations.
Such information does not necessarily need to be used continuously in future conversations.
For example, it may be inappropriate for an agent to refer to information disclosed by a user during a temporary consultation in a conversation on another day.
Therefore, it is important to be able to restrict Memory usage according to business needs and an organization’s information management policies.
2. When Remembered Information Becomes Outdated or Incorrect
Agent Memory automatically remembers relevant information from conversations, but that information is not always correct.
For example, if a user previously said they frequently traveled overseas for work but now handles only domestic work, referring to old Memory may produce an answer that does not reflect their current situation.
Users can, of course, view, edit, and delete Memory, but not all users will manage it regularly.
It is therefore necessary to consider not only the convenience of remembering past information but also the impact outdated or incorrect information may have on answers.
3. When an Organization Wants Centralized Memory Management
Centralized control by enterprise administrators is especially important.
Previously, Memory had to be enabled or disabled separately for each agent.
In an organization with many agents, checking and changing every agent’s settings individually can be a considerable burden.
If internal information management policies change or rules for using Memory are reviewed, the organization may also want to temporarily suspend Memory usage across the whole organization.
This update allows administrators to stop Memory usage across the organization regardless of individual agent settings and apply corporate policies.
These are practical considerations for enterprise use; Salesforce has not officially stated them as the reasons it added this feature.
Behavior When Disabled
When Conversational Memory is disabled across the organization, the following applies even if Memory is enabled in individual agents.
- Creation of new Memory stops.
- Use of existing Memory stops.
- The Memory & Preferences icon in the Agentforce Panel is hidden.
However, disabling Memory does not delete existing Memory; it remains stored.
In other words, disabling Memory and deleting Memory are different operations.
This setting controls Agentforce Conversational Memory. The release notes reviewed do not state that it can also stop Data 360 Agentic Memory and Context with the same organization-wide setting.
Setup Instructions
- Conversational Memory is enabled by default for the organization.
- To disable it across the organization, follow these steps.
- Enter Einstein Generative AI in Setup’s Quick Find.
- Open Einstein Audit, Analytics, and Monitoring Setup.
- Disable Enable Conversational Memory for Agentforce.
⑥ Which Should You Use?
Although both features aim to remember past conversations, the appropriate choice depends on the use case.
For example, if an internal Employee Agent should remember a user’s previously stated preferences or preferred answer format and use them again in subsequent conversations with the same agent, Agent Memory is suitable.
It can be enabled from Agent Script without implementing complex external integrations.
Agent Memory can also be used by a Service Agent that needs to remember a customer’s preferences or support-related information for subsequent conversations.
On the other hand, Data 360 Agentic Memory and Context is suitable when preferences that a customer shared with a product consultation agent should also be available to another support agent.
It is particularly beneficial when multiple agents serve the same customer or customer information needs to be used continuously across different conversations.
However, Agentic Memory and Context assumes API integration and requires additional design for implementation and operation.
Regardless of which Memory feature is used, Variables and Actions remain important for explicitly managing values in processes such as registrations, orders, and customer information updates.
Although these are provided as separate features, Salesforce’s public documentation does not fully establish whether their internal storage infrastructure and processing are completely independent.
Conclusion
Agent Memory and Agentic Memory and Context both allow agents to remember past interactions. However, Agent Memory offers relatively easy Memory usage at the individual-agent level, while Agentic Memory and Context enables Context sharing among multiple agents using Data 360.
Of course, Agent Memory can also share User-Level Memory across agents, so the ability to share information alone is not a complete distinction.
The introduction of these Memory features does not make Variables unnecessary.
Memory continuously utilizes information obtained from previous conversations, while Variables explicitly manage values needed for current business processes. They have different roles.
And although Memory is convenient, it is not necessarily desirable to remember every piece of information unconditionally.
I believe the new ability to disable Memory for an entire organization is an important improvement, as it allows companies to control its usage according to their information management policies.
At the same time, some aspects, such as the precise storage location and retention period of Memory, remain unclear from the official documentation alone.
As these specifications become clearer, it should become easier for enterprises to design how they operate Memory.
It is important to choose the appropriate feature depending on whether you want an individual agent to retain continuous memory, multiple agents to make use of customer information, or specific values to be managed accurately in business processing.
In this article, I organized the differences between the two Agentforce Memory features based on official documentation.
That’s all for this article.
Nobuyuki Watanabe
https://www.linkedin.com/in/nobuyuki-watanabe/ (+Follow me)
