Context comes first in Salesforce's six-part model

On September 10, 2026, Salesforce published a post describing what it calls a trusted foundation around AI, so that agents can understand the business, reason and plan, take action, and stay inside enterprise controls without each one rebuilding those pieces. The post breaks that foundation into six capabilities, and the first one it lists is Trusted Context. That ordering puts the data question ahead of the agent question, which is the part platform owners should sit with.

The other five are Trusted Agency, Trusted Action, Trusted Governance, Trusted Security, and Trusted Models. Over all six sits an AI Control Plane, which the post says will register agents, set identity and policy, observe behaviour and outcomes, and control cost across Salesforce and third-party AI. Our sibling piece covers what that control plane needs to make action explainable. This one stays on the context layer, because that is where an agent's boundary actually gets drawn, on purpose or not.

What Salesforce puts inside Trusted Context

The post describes Trusted Context as the layer that brings customer context together with data, metadata, semantics, knowledge, and real-time signals, so that AI has a shared understanding of the customer and the business. It names Data 360, which sits under our Data Cloud coverage, alongside Informatica, MuleSoft, and Tableau behind that layer. It also quotes Rohan Kumar, Salesforce's president and chief platform and engineering officer, saying that what will differentiate an enterprise is "the trusted, proprietary context it brings to that intelligence".

Read that list slowly. Semantics and knowledge are definitions rather than fields, and definitions are where two teams who share a customer record still find room to disagree. We covered that in what a shared customer record really needs. A person on the forecast call can hear that sales and service mean different things by an active account and sort it out. An agent reading a shared semantic layer takes whichever definition won, at runtime, with nobody in the room.

Shared context is a permission surface

The security reading follows from the word shared. If every agent draws on the same context, whatever sits in it is available, in principle, to every agent that can reach it. Salesforce's post keeps identity, permissions, privacy, and runtime security in a separate capability called Trusted Security, and puts lineage and quality controls under Trusted Governance. That split is tidy on a slide. In a real org it means three capability owners share one question, which is what a given agent may know about a given customer at a given moment.

Here is the situation we would test first. A renewal agent reads a churn-risk signal that a support model produced from case sentiment. The signal is accurate and sits in the shared context, so the agent offers a retention discount. Nobody decided that a support-side inference was safe to act on commercially, and the account team finds out when the customer forwards the email. The field-level permission was fine. The boundary that failed was the one nobody had drawn around what that signal was for. We saw the same problem in where permissions should be owned in an agent connection, and sharing context by design makes it sharper.

A shared understanding is also a shared mistake

Salesforce's own words for Trusted Context are a shared understanding of the customer and the business. We would take that literally in both directions. When it is right, every agent benefits at once. When it is wrong, because an integration dropped a status update or a real-time signal landed out of order, every agent is wrong together, which is far harder to notice than three tools disagreeing.

That is the operating boundary we mean. How far an agent should be trusted to act is set by how much of its context you can vouch for, and sharing the context raises the cost of that vouching rather than lowering it. The Winter ’27 case that governed CRM data comes before autonomous work was already pointing this way. The September 10 post makes it the first item on the list.

The control plane only sees what the context lets it see

The post says behaviour and outcomes get observed in the AI Control Plane. Observing an outcome tells you what the agent did. Explaining it means knowing what the agent knew, and once real-time signals are in the mix, the context at the moment of action may be gone by the time anyone reviews it. The post does not describe a snapshot of context at decision time, and that snapshot is the first thing we would ask for.

Without it, the review after a bad action becomes an argument over whether the data was wrong or the agent was. The post names Salesforce Guardian and Agent Fabric among the technologies involved. Our guess is that the answer sits between them, but the post does not say.

The list to write before early 2027

On timing, the post says many of the foundational technologies are available now, with the new capabilities and the unified experience planned for early fiscal 2028. Salesforce's fiscal year runs ahead of the calendar, so we read that as early 2027, and anything more precise is a question for your account team.

The work that pays off before then is dull and specific. Pick one agent that is already running and write down every field, definition, and signal it reads. Next to each one, write who owns it and who gets paged when it goes stale. Our agent readiness check covers the rest of that exercise. The row with no name in either column is your boundary. Start there, because that is the row a shared context will hand to every agent at once.