Six capabilities, named by the company selling them
Salesforce has published its most structured public statement yet on where the boundary sits between what an agent may decide and what an agent may do. It landed on September 24 in a Salesforce newsroom post with no byline. This is the company's own account of its own product, so read it as marketing and read the six names anyway.
Rohan Kumar, Salesforce president and chief platform and engineering officer, set out six capabilities: trusted models, trusted context, trusted agency, trusted actions, trusted governance and trusted security. The post describes them as unified by an AI control plane that will discover, manage, evaluate and cost-govern agents across the enterprise stack.
The list matters because of the question waiting in your next design review. Someone from risk or finance will ask what stops an agent doing something it should not, and these six are the words Salesforce will reach for. Having the vocabulary early is not the same as having the answer.
Agency and actions carry the weight
Four of the six cover ground platform teams already buy and audit under other names. Trusted models is model selection. Trusted context is what the agent can see, which we argued in September is where the boundary actually gets drawn. Trusted governance and trusted security are lifecycle, identity and policy work that predate agents by a decade.
The two that answer the design review question are trusted agency and trusted actions. Agency covers what an agent may decide on its own. Actions covers what it may do once it has decided. Those two also get the least ink, which is the ordinary shape of a launch narrative.
A vendor naming a category does not mean a customer can configure it and prove afterwards that it held. Ask where the setting lives, who may change it, and what record shows the limit stopped something. When we read the control plane description in September, explaining a single action was missing from the list, and this post does not put it back.
The entrance moved off the user interface
Khushwant Singh, SVP of product management for Platform, framed the shift in two sentences. "Agents need a different entrance into the enterprise." And: "That's why we opened up Salesforce and all of its trusted capabilities to any AI, any interface, any agent, without requiring a Salesforce UI."
For anyone who owns a Salesforce org, that has a specific consequence. Any control that exists only because a person went through a screen stops applying, including page layout visibility and a step someone has to click past. What survives is profile, permission set, sharing and field-level security, because those hold at the API.
So the audit worth running this quarter is the one against the identity an agent uses rather than the person watching it work. Our permission audit walkthrough covers the mechanics. The output you want is a list of objects and fields an agent can reach that nobody meant it to reach.
An hour to a first agent is a starting speed
Salesforce says Fulton Bank went from first hearing about Agentforce to a working agent in one hour, reached power users within a week, and had 3,000 employees using it six weeks later. The agent was a prebuilt outbound sales one named Hunter, with a cited example goal of reengaging 340,000 dollars of at-risk pipeline. Those figures come from the vendor.
One hour is a claim about how easy it is to start, and it says nothing about whether the output was any good. It also makes governance harder, because anything that can be stood up in an hour will be stood up by people who never asked the architecture team.
So check one thing this week. Find out who currently holds the permission to create and activate an agent in production, count them, and see whether that number matches what your change process assumes.
Seven times return with nothing attached to it
The post describes Southwest Airlines running subagents inside a unified superagent, with millions in productivity gains and seven times the return on investment. No base population, no period, no method. Benchmark percentages elsewhere in the piece are described in the post itself as internal pilots measured against internal benchmarks. Nobody outside the companies involved has verified any of it.
Seven times over what, and by when, is not a figure an architect can carry into a business case. What counts for something is that Southwest and Fulton Bank are named, real customers rather than anonymous references. A named customer can be found at a user group and asked what those six weeks actually involved.
Justin Bundick, VP of AI and intelligence platforms at Southwest Airlines, offered the more useful line: "Your customers will provide you their needs a lot faster in real time than all the planning sessions you could have had internally." Jason Lemkin, SaaStr CEO, was blunter in a shorter excerpt: "Agents are great, right? But you can't trust them." He went on to argue that you need the kind of framework Salesforce has now put a name on.
The meter is the other half of the control plane
Cost-govern sits on the control plane list beside discover, manage and evaluate. A day before this post, we reported that Salesforce's rate card names a usage type for headless calls and leaves the multiplier blank. A control plane that can cost-govern agents and a meter that can bill for them are the same plumbing described from two directions.
Mark Wakelin, EVP and GM for Agentforce, set out three steps: deploy fast, customise and extend, then observe and optimise. Observation comes third, after the thing is live and after it has been extended. That order fits the Fulton Bank hour and does not fit how a change advisory board works.
Put one request to your account team and ask for it in a sandbox with a screen share, not in a slide. Show me the object, setting or policy that holds the limit on what an agent may decide without a human, show me who can change it, show me the log entry when they do, and tell me whether the cost-governance record and the audit record are the same record.
