Two Salesforce announcements landed a week apart, and they point in opposite directions. One says the agent does not have to live in the org. The other packs more into it. Both raise the same question, which is what each team, each org, each license line and each credit is actually for.
We argued something close to this a year ago
Last September we published Don’t make AI your landlord, get ROI. The argument: a vendor who bolts a proprietary AI layer onto its platform and charges for it becomes your landlord. You pay extra rent on a smart apartment and get no say in the wiring. Two disciplines followed from it. Choose your own intelligence, and keep data access open enough that you can. Then measure what the rent buys — every AI action consumes credits, and those credits should be answerable to the business process they serve. We leaned on MIT’s finding that 95% of generative AI pilots fail, and read the failure as one of ownership rather than of technology.
We held that loosely. It was a position, not a prediction, written more in hope than in confidence. The year has been kinder to it than we expected.
What Claudeforce actually changed
On 26 August, during its Q2 FY27 earnings call, Salesforce announced Claudeforce with Anthropic. The visible artefact is Salesforce in Claude, a plugin carrying 37 prebuilt sales skills. A seller reads and updates live CRM records without opening Salesforce, and the actions route back through the platform, so permissions and business rules still apply.
The plugin is not the interesting part. The harness is. Salesforce in Claude is enabled by AIforce, which exposes business data and workflows to any agent through MCP servers, APIs and CLI tools, and that sits on Headless 360, introduced at TDX in April: the platform’s capabilities published as APIs, MCP tools and CLI commands rather than as screens. Benioff’s framing was that the UI is the AI.
One clarification, since it will come up. Claude has been a reasoning model inside Agentforce since late 2025, powering the Atlas Reasoning Engine and running by default in Vibes and Coworker. That was the same placement in a different coat: a frontier model wired underneath the platform’s own agent layer, still sold inside the org. Claudeforce reverses the direction, and rightly so. One arrangement puts the model under the platform. The other puts the platform under the model, where the customer holds the choice of head. They are not two versions of the same architecture.
It is early, and worth planning against as such. Salesforce in Claude is available to pilot customers with an open beta announced for September, and on the platform side the Headless 360 MCP server is in beta and API version 67.0 or later is required. Not where a quarter’s revenue process belongs this month.
The reversal, and what it concedes
The concession is in the architecture rather than in any statement: the interface does not have to be the platform’s. Reasoning outside the org, business rules and the record inside it. That is our year-old argument, published by the platform itself.
Agentforce, as an AI layer sold by the seat inside the org, was the wrong shape. Not the ambition — the placement.
Then the editions arrived
On 3 September, Salesforce announced new Core, Advanced and Max editions for Agentforce Sales, Service and Industries. Every tier now carries Agentforce, Slack and Slackbot, embedded agentic analytics on Tableau Next, data security and a Premier Success plan. Flex Credits are included by tier: 500,000, 1 million, 2.75 million. Pricing is $195, $395 and $550 per user per month, each presented as more value than the edition it replaces. Max holds the Agentforce 1 price, and existing Agentforce 1 customers can move across at no extra cost. Future Max editions are also to include an allocation for Headless 360 capacity.
Read the two announcements together. One says the head can be anywhere. The other consolidates more into the seat: AI injected in more places, and several heads at once — the Salesforce UI, Slack, Tableau. Headless, meanwhile, arrives as capacity allocated inside the most expensive tier. That is the sentence we keep re-reading, because API-led access is something we had assumed the platform held by design.
Perhaps bundling is fine. Fewer SKUs to piece together is a real convenience, and a credit allocation you did not have to negotiate is a real head start. But bundling removes none of the work.
A line item on an order form does governance work almost by accident. Someone has to ask for it, someone has to sign for it, and at every renewal it reappears as a row with a number beside it, so the question — does anyone actually use this? — gets asked at least once a year. A bundled capability asks nobody. Slack, agentic analytics and a few million credits arrive switched on for every team, with no requester and no owner, and the judgment about whether a given team needs a given head still has to be made. It just moves out of the purchase, where the calendar forced it, and into the estate, where nothing forces it at all. Which is why the answer now has to come from measurement rather than from the contract.
Three ways to put AI on an org
Agentforce, bundled inside the org. Was wrong, for the reason above.
Claudeforce. Getting better. Reasoning outside, business rules inside, reaching the org through its own APIs.
Your own MCP server, in front of those same APIs. Works too. Any AI, including Claude. Simple, decoupled, flexible, and scoped to exactly what you choose to expose. We have built this and we run it, which is the only reason we are comfortable recommending it.
None of this is a rejection of the platform. The backbone stays in Salesforce: the objects, the record types, the validation rules, the audit trail. What moves out is the head, and with it the choice of model, the scope of what an agent can reach, and the meter.
Decoupling is the simpler path, and the one that lasts
Bundling and decoupling are both offered as simplification, and they do opposite things to your estate. A bundle simplifies the purchase: one line instead of nine. Everything inside it still has to be configured, secured, trained on and maintained in your org, whether a team asked for it or not. That is accretion by procurement, the same mechanism that produced the complexity we spend our days measuring: every year adds, almost no year subtracts.
Decoupling simplifies the thing you operate. One backbone in Salesforce. One API surface you chose to expose, readable in an afternoon. One model, swappable when a better one ships, on a meter you can attribute to a process. The assets can run on a cloud you already own, and the scope shrinks as easily as it grew. Sustainable, here, means you can still change your mind in two years, and the estate you hand to the next architect is smaller than the one you inherited.
What the bundle makes urgent
The economics already moved from licenses to consumption. Benioff has said Salesforce will spend around $300 million on Anthropic tokens in 2026, most of it on coding work. What the spend is for matters less than its scale: that is what running an agentic platform costs in tokens. On your side of the table, credits now arrive by the million inside an edition, and a credit is only cheap until someone asks what it produced.
So the questions get more specific, not less, and they are the same four every time:
- Per team. Which teams need which head — the Salesforce UI, Slack, an agent in Claude, an agent of your own? All of them everywhere is the default, not a decision.
- Per org. What does each org actually run? A bundle applied to an org where half the business processes produced no measurable work last quarter buys agentic capability for structure nobody uses.
- Per license line. Which lines map to an org you can analyse, and which map to nothing anyone can name? An unmapped line is a question with a dollar figure attached.
- Per credit. What did past token consumption serve? Consumption is defensible only when set against the business process it moved.
The subtraction nobody does
Before extending any agent surface, subtract. Clean the org of unused processes and objects that nothing reads. Set past token consumption against the processes it actually served. Then focus the new agentic surface on what is left, rather than spreading it over everything the bundle happens to enable.
The reason is unglamorous: an agent will reason very well over a dead process, at full price. In the synthetic five-org estate we use for demonstrations — illustrative figures, not customer results — 254 business processes resolve into 126 with no activity in the period and 47 holding no records at all. Point a well-configured agent at that and it works confidently across the dead half, burning credits on nothing anybody needed. Structure you cannot see is structure you cannot decide about, which is why the measurement comes before the agent.
Own the value, audit the rent
The landlord problem has not gone away. It has changed shape: fewer line items, more inclusion, a meter you do not read. The remedy is the same one we proposed a year ago, and it is now easier to execute, because Salesforce has published the seam. Choose your own intelligence, expose only what a job needs, and hold every seat and every credit answerable to a business process someone owns.
Do not be a tenant. Be an owner.
Stood Flows measures a Salesforce estate by business process — structure, real usage and contract cost — read-only, with no Stood cloud in the data path. A Quickstart is a couple of hours with one of our experts, walking the first steps on an org you own. If it is the decoupled side you want to discuss, we are happy to talk through the MCP assets we run ourselves.