Your Agentforce Agent Remembers the Session. It Does Not Remember Last Night's Run.

If you run an Agentforce agent on a schedule, here is an uncomfortable question: what did it learn this week? Not what did it do. What did it learn. If you are honest, the answer is probably nothing, and that is not a configuration mistake. It is how the platform's memory is designed.

Inside one session, Agentforce remembers plenty

During a live conversation, an Agentforce agent keeps up fine. A customer describes an issue, shares an order number, asks a follow-up, and the agent tracks the thread without making anyone repeat themselves. Salesforce gives builders two mechanisms underneath that. Context variables come from the messaging session: pre-chat form data, fields on the Messaging Session object, even information carried over from previous messaging sessions. They are set when the session starts and cannot change during it. Custom variables hold action outputs: whether the customer authenticated, intermediate results that feed later actions, flags that decide which topics are available. Together they make one conversation coherent.

None of it survives the session ending. Context and custom variables are session state by design. When the conversation closes, they are gone.

The CRM is not the agent's memory

This is the part that fools people in demos. An Agentforce agent opens a chat and seems to know the customer: the account, the open cases, the order history. It knows all of it because it read Salesforce. The CRM and Data Cloud are the agent's data source, and Salesforce's own comparison of the platform calls this out directly: Agentforce's context comes from CRM data plus Data Cloud, and it is strongest where the data already lives in Salesforce.

But knowing the customer is not the same as remembering the work. The record says there are three open cases. It does not say that last night's scheduled run already investigated them, concluded two were duplicates of an older case, and escalated the third after a reasoning chain the agent could reuse. So tonight's run reads the same three cases, re-investigates them, and re-derives the same conclusions. It pays full token price for thinking it already did. The data persists; the agent's experience of working with the data does not.

Scheduled runs are the worst case

Every scheduled execution is a fresh session. Picture a nightly pipeline review that flags at-risk deals and drafts follow-up. On Tuesday it figures out that deals where a specific competitor appears always stall after the second call, and it starts prioritizing them. On Wednesday the run begins with amnesia. The lesson is not in a variable, not in the conversation, and not in the CRM, because the CRM stores deal facts, not agent judgment. The agent either rediscovers the pattern from scratch or sails past it. Week after week, run 100 executes the task exactly as blindly as run 1. You are renting the same reasoning every night and throwing the receipt away.

Salesforce clearly sees this gap, because the company just announced the fix as its headline feature. The new long-horizon runtime is built for work that spans days and weeks. Its three pillars are memory that preserves context and progress across sessions, durable execution that keeps plans running and lets them resume when steps fail, and dynamic steering that adjusts behavior from user feedback mid-flight. Hunter, the outbound sales agent, is the first to run on it. It is in pilot now, with general availability expected in November 2026, and Salesforce plans to bring more agents and eventually customer-built agents onto it.

That is genuinely the right architecture. It is also not what you have today. Every other agent in the current lineup wakes up, does one job, and forgets.

Three ways to bridge the gap now

One option is to make the agent write its own lessons down. End each run by writing decisions, exceptions, and what changed into Data Cloud or custom objects, and have the next run query them first. For Salesforce-centered teams this keeps everything inside the platform they already pay for. Public pricing gives you the shape of the cost: $2 per conversation, Flex Credits around $0.10 per action, or Agentforce 1 Editions from $550 per user per month. The limitation is structural, not financial: you design the schema up front, you decide in advance what deserves to be remembered, and the memory only ever holds what you thought to save. A filing cabinet, not a memory.

A second option is to hold out for the long-horizon runtime to go generally available and move your scheduled work onto it. That is a roadmap bet with a November 2026 date and unpublished pricing for the runtime itself. Fine as a plan, risky as the only plan.

The third option is to give the agent a memory that is not tied to any platform's roadmap. An external memory layer the agent reads when it wakes up and writes to before it sleeps: tonight's decisions, the exceptions it hit, the patterns it noticed. Not the transcript of a chat, but the working knowledge of the job. This is what makes a scheduled agent compound: run 100 is visibly sharper than run 1 because it stands on the other 99. And it works the same whether the agent runs inside Agentforce, n8n, or a cron job on a server.

Vilix AI exists for exactly this. It is cloud-hosted, so there is nothing to provision or maintain. One shared memory over MCP follows your agent across every tool it touches: Agentforce, n8n, Claude Code, your phone apps, all of them. It keeps full conversation history, not just extracted facts, so a run can revisit what was actually said and decided. The free plan is free forever, the 7-day Pro trial asks for no credit card, and your data is portable: export everything or wipe it anytime in a portable format.

Salesforce is building session-spanning memory for one agent in a pilot. Your scheduled agents cannot wait for a roadmap. Give them a memory that works on every run, starting tonight.