Agentforce agent memory: why your agent forgets, and what 'memory' means today

Ask a room of practitioners what they most want from their agent and “memory” comes up fast. The agent should remember the customer. It should remember what happened last time. It should stop asking for the order number it was given ninety seconds ago. Reasonable asks, all of them, and the reason they’re hard is that “memory” is one word doing the work of three, and the three have completely different answers.

Underneath the wish are three distinct capabilities: session state (what the agent holds within one live conversation), grounding (what it can retrieve about the world when it needs it), and durable memory (what it carries forward from one conversation to the next, months later, across channels). Two of those are shippable, documented features you can configure today. The third is mostly an engineering direction Salesforce is building toward. Real, but not a toggle in Setup. Conflate them and you either underuse what you already have or architect a workflow around a capability that doesn’t exist yet.

This post separates the three cleanly. What a stateless model is, what carries context inside a session, why grounding is not memory, how to fake cross-session continuity with the tools that exist, and, carefully labelled as such, where the platform is heading with “Agentic Memory.”

The default is amnesia, and that’s structural

Start with the uncomfortable fact: a large language model has no memory at all. Each inference call processes a fresh context window and produces a response; when the call returns, nothing about that exchange persists inside the model. Statelessness isn’t a bug in Agentforce. It’s a property of the architecture every LLM agent is built on. Anything that looks like memory is something the platform assembled and handed to the model on that turn, not something the model retained from the last one.

That reframes the whole problem. “How do I give my agent memory?” is really “what does Salesforce put back into the context window on each turn, and how do I control it?” Answer that and the mystery dissolves, the agent isn’t forgetting because it’s dumb; it’s forgetting because nobody arranged for the fact to be present when it reasoned.

There are exactly three sources of context the platform can draw on, and it’s worth naming them precisely because the fixes are different for each.

Source one: session state, conversation history and variables

Within a single live session, two mechanisms carry context.

The first is conversation history. The Agent API is explicitly session-based: startSession returns a sessionId, and every sendMessage call carries that sessionId plus a sequenceId you increment per message, so the platform can thread the exchanges together and feed prior turns back into the reasoning context. That’s why an agent can answer “and what about the second one?”, the earlier turns are in scope. It’s also why very long conversations start to wobble, which we’ll get to.

The second, and the one you control, is variables. This is the deterministic layer, and it’s the single most important tool for making an agent stop re-asking what it already knows. Salesforce splits it into two families:

Context variables carry system-provided facts, referenced with the $Context prefix. Most are read-only once the session starts. You set them at startSession and they hold. The one documented exception is $Context.EndUserLanguage, which is editable mid-session (only during a sendMessage call). On messaging channels, context variables can be auto-populated from Messaging Session record fields, including custom ones, via a pre-chat form.
Custom variables carry facts you capture during the conversation: a verified customer ID, an email, a case number. Their value can be set by an action’s output or set manually, and once set, that value persists for the rest of the session, unaffected by later turns.

We wrote a whole post on the taxonomy and the traps: context vs. session vs. custom variables, the read-only rule, and the pre-chat pattern that ships an impersonation hole if you trust it. The one-line version for this post: a variable is where you put a fact you need to be exactly right every time. An instruction that says “remember the customer’s ID” is a suggestion to a probabilistic model; a variable is a named slot that holds the ID unchanged until the booking action reads it. If your agent forgets things it was told in the same conversation, that is almost always a variables problem, not a memory problem, and it’s fixable this sprint.

In Agent Builder the configuration is two checkboxes and a description: mark a variable “Allow value to be set by API” if an external system supplies it, and “Allow LLM to use value” with a written description if you want the reasoning engine to see and use it. In metadata these are ConversationVariable and ConversationContextVariable. Referenced in classic instructions with the {!$Context.…} / {!$customVar} merge syntax; in the newer Agent Script authoring layer, as @variables.<name>.

Source two: grounding is retrieval, not memory

The second source of context is grounding, and the reason it gets filed under “memory” is that a well-grounded agent sounds like it remembers things. It doesn’t. Grounding is retrieval: at reasoning time, the platform pulls relevant records, knowledge articles, or unstructured content into the context window so the model answers from your data instead of from its training. Structured CRM data, Data 360 retrievers running semantic search over the vector database, knowledge articles, all grounding.

The distinction that matters operationally: grounding is demand-driven and document-tied; memory is stateful and identity-tied. Grounding answers “what is this customer’s current balance?” by fetching the record. Memory would answer “this customer always disputes the first invoice” by carrying a learned fact forward. Grounding makes the agent answer better; memory would make it behave smarter over time. The two are complementary, and most teams get enormous mileage from grounding alone, which is exactly why the data foundation decides the agent’s quality far more than any prompt tweak does.

So when someone says “the agent should remember the customer’s history,” nine times out of ten they don’t need a memory system. They need the history to be grounded: unified in Data 360, related through Data Graphs so the agent knows how a customer connects to their orders, cases, and entitlements, and retrievable on demand. That’s shippable today.

Source three: cross-session continuity, the part you build yourself

Here’s where it gets honest. If you want an agent to carry something from this conversation into next month’s conversation (a stated preference, a decision, an outcome) there is no click-to-enable “long-term memory” store you point the agent at today. What there is: the primitives to build it yourself, and they’re not exotic.

The durable substrate is your data, and the pattern is write-then-ground:

Write the fact back. When the agent (or a human) establishes something worth keeping (a communication preference, a resolution, a risk flag) persist it with a deterministic action: update a field on the record, create a custom object row, or write to Data 360. An Apex invocable action or a Flow does this reliably; the LLM decides whether, your platform decides how.
Ground it next time. On the next session, that fact is now part of the customer’s grounded profile: retrieved like any other record, and optionally hydrated into a context variable at session start (from Messaging Session fields, say) so it’s present from the first turn.

That’s cross-session continuity, assembled from parts that all exist and are all governed. It’s more work than flipping a switch, but it has a property the switch wouldn’t: every remembered fact lives in a record you can see, correct, permission, and delete. For anything customer-facing, that auditability isn’t a consolation prize. It’s the requirement. A memory you can’t inspect is a compliance liability, not a feature.

The same pattern is how state moves between agents in a multi-agent setup: variables act as shared, structured state passed between a supervisor and its specialists, so a fact captured by one is available to another without re-deriving it.

Context rot: why longer conversations get worse

Before the roadmap, the failure mode that surprises teams most. Conversation history, retrieved grounding, and action outputs all compete for the same finite context window. As a conversation grows, newly retrieved content and later turns crowd out the earlier ones, so the agent ends up reasoning over a stale or incomplete slice of its own conversation. Salesforce has a name for it: context rot.

Their own list of production symptoms is worth memorizing, because it’s exactly what teams report and misdiagnose:

Resolution rate drops as conversations get longer.
Escalation rate runs higher than the pilot predicted.
The agent re-asks a question it already got an answer to.
The agent forgets an earlier turn.
It demos beautifully on scripted paths, then degrades on real, unscripted sessions.

Notice that “re-asks a question” and “forgets an earlier turn” appear on this list too, the same symptom can come from a missing variable (fixable now) or from context rot (a design problem). Telling them apart is half the debugging.

The mitigations Salesforce recommends are all design, not magic: redesign long knowledge articles into single-topic chunks so retrieval returns the relevant paragraph instead of the whole document; carry key facts in variables rather than re-deriving them each turn; use deterministic filters to strip irrelevant topics at the system level instead of hoping instructions hold; and split monolithic agents into supervisor/specialist designs so each agent keeps a smaller, cleaner context. Every one of those also shows up as a lever in the cost math, because a bloated context is a bloated bill, stuffing full history back into every prompt to fake statefulness inflates tokens on every single turn.

Where Salesforce is heading: “Agentic Memory” (read this label carefully)

Salesforce’s engineering team has publicly described a durable memory system they call Agentic Memory, and it’s interesting, provided you read it as what it is: an engineering and architecture direction described in a February 2026 Salesforce Engineering write-up, not a documented admin feature with a Setup toggle or a GA/beta/pilot label you can turn on today.

What they describe is the shape of memory done properly at platform scale:

Memory externalized into structured records in a real-time data layer, kept separate from the prompt, with explicit lifecycle control.
A pipeline that decides, for each candidate fact, whether to add, update, delete, or ignore it, so memory doesn’t just accrete noise.
A split between short-term context tethered to the active session and long-term memory linked to a persistent profile graph that endures across sessions and channels.
Write and read gates, confidence scoring, memory compaction, and source tracking, plus hybrid matching (similarity search plus semantic checks) to keep duplicates and drift out.

If that architecture sounds like a disciplined version of the write-then-ground pattern above (records, lifecycle rules, confidence, governance) that’s exactly the point, and it’s the strongest signal about how to build interim memory today: structured, governed, inspectable, with explicit rules about what gets written and what gets forgotten. Build it that way now and you’re aligned with where the platform is going rather than against it.

What you should not do is put “turn on Agentic Memory” in an implementation plan, promise a stakeholder a cross-session profile graph as a configured feature, or design a workflow that assumes an out-of-the-box durable-memory object exists. Until it appears in official Setup documentation with a status label, treat it as the horizon, not the toolbox. Presenting an engineering-blog concept as a shippable feature is precisely the kind of overreach that turns a confident demo into a broken promise.

The takeaway

“Give the agent memory” is three requests wearing one coat. Pull them apart and each has a clear answer. Within a session, the agent already threads conversation history, and variables are how you make it hold a fact deterministically. That’s your fix for re-asking, available now. Across the world, grounding on a unified Data 360 foundation is how it knows the customer’s real history. Also now, and usually the higher-use investment. Across time, cross-session continuity is something you assemble from write-back actions and grounded reads, in records you can govern, more work, but auditable by construction. And the fully managed, profile-graph version Salesforce’s engineers are building is the direction, not yet the destination.

Get the first two right, build the third deliberately, and don’t ship against the fourth until it’s real. An agent that never forgets what it was just told, and always knows what your data already knows, clears the bar that most “memory” complaints are about.

Understanding the basics

Does Agentforce remember previous conversations?

Not automatically as a durable, cross-session store you enable. Within a single session, Agentforce threads context through conversation history (the Agent API is session-based, keyed on a sessionId and an incrementing sequenceId) and through variables that hold facts deterministically for that session. Across separate conversations, continuity is something you build: persist the fact worth keeping with a deterministic action (update a record, write to Data 360), then ground it on the next session so it’s retrieved like any other data. Salesforce’s engineering team has described a managed “Agentic Memory” system with a persistent profile graph, but as of now that is an architecture direction, not a click-to-enable Setup feature.

What’s the difference between grounding and memory in Agentforce?

Grounding is retrieval, at reasoning time, the platform injects relevant records, knowledge, or unstructured content into the context window so the agent answers from your data rather than from the model’s training. It’s demand-driven and tied to documents or records. Memory is stateful continuity tied to an identity. Facts and preferences carried forward over time. Grounding helps the agent answer accurately; memory would help it behave consistently across sessions. Most “the agent should remember the customer” requests are grounding requests, solved by unifying the data in Data 360 and retrieving it on demand.

How do I stop my Agentforce agent from re-asking for information?

If it’s re-asking within the same conversation, that’s almost always a variables problem, not a memory problem. Capture the fact (a verified ID, an email, a case number) into a custom variable (set by an action’s output or manually), and reference it in later actions and instructions so downstream steps read the stored value instead of asking again. If the re-asking only happens in long conversations, suspect context rot: the finite context window is crowding out earlier turns, and the fix is design: carry key facts in variables, chunk long knowledge, use filters, and consider splitting the agent.

Is “Agentic Memory” available to configure now?

No documented admin configuration exists for it as of this writing. “Agentic Memory” (the profile-graph system with read/write gates, confidence scoring, and add/update/delete/ignore lifecycle logic) comes from a Salesforce Engineering write-up describing how the platform approaches durable memory under the hood. It carries no GA, beta, or pilot label in that source and no Setup documentation. Build cross-session memory today with governed records and grounding; watch the official release notes for when a managed memory feature lands with a real status.

Trying to work out whether your “memory” problem is a variables fix, a grounding project, or a genuine cross-session design, and how to build it so every remembered fact stays governed? Talk to us. Getting the state model right is exactly the work that makes an agent feel continuous instead of amnesiac.