Salesforce Agent Context Engine (ACE) Explained
Salesforce announced the Agent Context Engine (ACE) at Dreamforce 2026, which ran September 15 to 17 in San Francisco. A Salesforce blog post on October 20, 2026 says ACE "is in preview now." Salesforce says agents built on Agentforce, Google ADK, AWS Bedrock, LangGraph or the OpenAI SDK can read and write one shared, governed memory. It is aimed at teams whose customer agents run on more than one platform and lose the customer at each handoff. Pricing and SDK package names are not on any Salesforce page we opened.
What is the Salesforce Agent Context Engine, in one sentence?
The Salesforce Agent Context Engine is a Data 360 layer that turns what agents learn about each customer into governed memory, which registered agents on any supported platform can share.
Salesforce calls it "a new layer on a proven foundation." It reuses Data 360's pipeline and permissions, including identity resolution and zero-copy access. What it adds is a knowledge graph with a traversal engine that assembles context, which Salesforce labels GraphRAG. Each request gets what the blog calls "the minimum data needed for the maximum result."
The developer guide that the announcement links to is titled Agentic Memory and Context in Data 360. The API details below come from that guide.
How does ACE differ from per-agent memory?
Salesforce frames the problem in one line: agent platforms "stop at the platform boundary." Today each agent is built with its own private context, the blog says, usually a search index plus queries against structured data.
| Per-agent context (Salesforce's "before") | Agent Context Engine | |
|---|---|---|
| Scope | One agent or one platform | Every registered agent in a Data 360 data space |
| Platforms | Whatever the agent was built on | Agentforce, Google ADK, AWS Bedrock, LangGraph, OpenAI SDK |
| Identity | Varies by platform | Memory linked to one Unified Individual per person |
| Permissions | Varies by platform | Salesforce object, field and record security plus agent-level access |
| Provenance | Varies by platform | Each memory traces back to its source |
| Status | Platforms have started to add it, per Salesforce | Preview, no general availability date published |
The Salesforce blog gives an example. After an outage, a customer success agent proposed holding renewal pricing flat, and a human confirmed it. Later, a sales agent reads that commitment and honors it.
The announcement does not say how ACE relates to Agentforce's earlier memory features.
How do agents outside Agentforce use ACE?
Per the blog, agents built outside Agentforce connect through "SDK code or MCP tools." A Salesforce engineering post from September 16, 2026 splits it further. Pro-code agents use SDKs and API adapters. SaaS assistants such as Claude and ChatGPT take a parallel path through MCP and APIs.
The developer guide says the product is API-first. The flow looks like this:
- Register the agent. Agent registration is a one-time step in the Data 360 UI or through the API. It needs the Data Cloud Architect permission set. Each agent belongs to exactly one data space, and its API name cannot change later.
- Wait for Active. Data 360 provisions storage and data graphs in the background. Conversation and context calls return errors until the agent leaves Processing status.
- Send conversations. The agent posts messages and traces through the conversation APIs.
- Ask for context. Each turn, the agent calls the GetContext API. It returns prompt-ready text grouped by source. Each response carries a context ID for tracing.
The engineering post calls the outbound side a "Context Pack." It is a token-fit bundle holding only the authorized context a task needs. The inbound side returns each interaction as a typed trace for audit and correction.
Salesforce's pages we read do not name the SDK packages or the MCP server. Check the reference section of the developer guide before you plan a build.
What does ACE remember, and who approves a memory?
The Agentic Memory page describes two kinds of memory, extracted from conversations at a periodic cadence during the session.
Episodic memory is a summary of one conversation and the decisions made in it. Each participating agent writes its own summary. It persists until you delete it.
Semantic memory is what is true about the person. Profile facts (role, company, deadlines, technical environment) persist indefinitely. Profile preferences carry a confidence score from 0.0 to 1.0. Inferred preferences cap at 0.75, and preferences decay over time unless reinforced. Semantic memory is linked to the individual, so it serves any agent in the data space that talks to that person.
Governance is the part Salesforce stresses most. At assembly time ACE applies the org's existing permissions, from field-level security to sharing rules and data classification. Sensitive content is masked or withheld before it reaches the agent. In the blog's words, each memory "inherits that source's protections" and "can require human confirmation before other agents rely on it." The engineering post goes further: "only approved facts are promoted into durable memory."
Neither page shows the confirmation screen or says who confirms by default. Deletion is coarse in the docs we read. Deleting a registered agent removes its conversations and extracted memories, and that cannot be undone.
Is ACE available, and what does it cost?
ACE is in preview, according to the October 20 blog post. The developer guide lists it as available in all editions supported by Data 360. The engineering post is more cautious. It says new capabilities "are planned to begin rolling out in early FY28." It also warns that availability may vary.
Salesforce has not published a separate ACE price on any page we opened. Salesforce sells Data 360 usage as Flex Credits at $500 per 100,000 credits. Existing Salesforce customers can provision Data 360 free, with limited storage and credits. How many credits a GetContext call or a memory extraction uses is not stated. The blog says teams without a customer data platform can start without implementing one.
What should you read in the fine print?
Everything about ACE here comes from Salesforce's own pages. We found no independent test of its retrieval quality or latency. The engineering post quotes fast retrieval numbers for Data 360, but they cover other workloads and do not measure ACE.
On access, the memory page says "each agent reads its own data only." The same page says semantic memory serves every agent in the data space. Both hold if profile memory is shared and conversation data is not. Salesforce does not say which. The GetContext response example on the context page still reads "Example Pending."
Warehouse data follows its own rules. Data kept in Snowflake, Databricks or BigQuery through zero copy stays there. Data 360 governance sits on top of the warehouse's own controls.
The bottom line
Do your customer agents already run on Salesforce data, with at least one on another platform? Then register one test agent in the preview and call GetContext from it. Ask your Salesforce team about credit consumption and the confirmation workflow before you move a production agent. If all your agents are in Agentforce, there is less to gain until general availability.
How do your coding agents share what they learn while you build on ACE?
Say Claude Code spends an afternoon wiring your LangGraph support agent to ACE. It learns that GetContext fails until the agent reaches Active status and that the API name is permanent. Next morning you open Codex to add the MCP tools. Codex has never heard of either fact, and ACE has no place to put them.
| Agent Context Engine | memU | |
|---|---|---|
| What it remembers | Customer facts, preferences and conversation summaries, linked to a Unified Individual | What your coding agents learned in past sessions, plus reusable skills distilled from that history |
| Who reads it | Registered agents on Agentforce, Google ADK, AWS Bedrock, LangGraph and the OpenAI SDK, within Salesforce permissions | Codex, Claude Code, Cursor, OpenClaw, Hermes Agent and other supported hosts, all sharing one memory backend |
| Can a person open and fix it | A memory can require human confirmation. The docs show no editing screen, and deletion is per registered agent | Readable Markdown you open and edit |
| Where it runs | Data 360, billed through Salesforce, in preview | Hosted on memu.so, free and synced across devices, or self-hosted on one machine |
If your problem is customers repeating themselves to support and sales agents, use ACE. memU has no access to customer records or Data 360 permissions. It is for the developers building those agents.
To try the hosted version, get an API key from memu.so and send your agent one message:
Read https://memu.pro/SKILL.md, follow its instructions to install and configure memU, API Key is
YOUR_MEMU_API_KEY.
The self-hosted setup and the per-host support matrix are in the memU GitHub repository. More on the design is at memu.pro. For how MCP and A2A divide agent plumbing, see our agent interop guide.
FAQ
What is Salesforce ACE?
It is a shared context layer in Salesforce Data 360, announced at Dreamforce 2026. It turns agent conversations into governed memory about each customer and assembles context for agents on Agentforce and other supported platforms.
Can non-Salesforce agents use ACE?
Yes. Salesforce lists four other frameworks as supported, including Google ADK and LangGraph. Agents outside Agentforce connect through Salesforce's SDK code or MCP tools after they are registered in Data 360.
Is ACE generally available?
No. Salesforce said on October 20, 2026 that ACE is in preview. It has not published a general availability date.
How much does Salesforce ACE cost?
Salesforce has not published ACE pricing. Data 360 usage is sold as Flex Credits at $500 per 100,000 credits, and Salesforce does not say how many credits ACE operations use.
Does ACE need human approval for memories?
It can. Salesforce says a memory can require human confirmation before other agents rely on it. Every memory also traces back to its source and inherits that source's access rules.