Salesforce Just Gave Up the Interface. Here’s What It Bought.
For twenty years, using Salesforce meant opening Salesforce. That assumption is now gone.
At Dreamforce, Salesforce unveiled AIforce, which it describes as a live interface layer that brings the full power of Salesforce to wherever people and agents work. It launches on three surfaces: Claudeforce, Slackforce, and Agentforce Coworker. Marc Benioff called it an interface revolution.
The framing is right. The conclusion most people are about to draw from it is wrong, and it will cost them a quarter to find out.
What actually shipped
AIforce is not a product. It is an umbrella, and underneath it sits the architecture you have been hearing about all year. AIforce runs on the Headless Toolkit, which Salesforce describes as “the open architecture that exposes every element of the Salesforce platform, giving builders and developers MCPs, APIs, plug-ins, skills, and developer tools.”
Headless is the plumbing. AIforce is the promise. If your team has been building a Headless 360 narrative, it is not wrong. It now sits one level below the line your business will actually hear.
One thing to get right before anyone builds a plan on this: the three surfaces did not ship at the same maturity. Salesforce in Claude, which is the surface most of the analysis below concerns, was piloted by Deloitte, GitLab, and Legora and is now available to all customers in beta. Beta is not a reason to wait. It is a reason to scope a pilot rather than a rollout, and to put the review cycle in the same quarter as the pilot instead of after it.
The three surfaces are one engine behind three front doors. Salesforce is explicit that every request runs on existing permissions and business rules, and every agent sees only what the person asking can see.
So Salesforce authorization is the common control across all three. That is worth stating precisely, because it is not the same claim as “these are equally secure.” Retention, egress, logging, and where an answer ends up all differ by surface. What does not differ is who is allowed to see what. Authorization is the constant. Everything else about security is a variable, and most of the analysis published this week will blur the two.
The variable is context reach
The question is not which surface your people prefer. It is where the reasoning happens, and what the model can see when it gets there.
Salesforce in Claude is for questions with messy inputs. One naming point first, because it will save you an argument later. Claudeforce is the lane, not a product. It carries two things. The first is Salesforce in Claude, the seller-facing surface. The second is the Salesforce Development plug-in for Claude Code, which ships with more than 40 skills, access to a broader Salesforce skills library on GitHub, and sub-plug-ins that load dynamically to take on development work. If your team builds on the platform, that plug-in is arguably the more consequential half of Claudeforce, and it carries an entirely different risk profile. When someone says “we’re evaluating Claudeforce,” ask which one they mean. Everything below is about Salesforce in Claude.
Claude is the client, Salesforce is the server. Salesforce arrives as a prebuilt MCP server inside Claude, which means the usual integration tax is already paid: no manual setup, no authentication plumbing, no hand-mapping skills to actions. Thirty-seven prebuilt sales skills come with it, covering prospecting through pipeline hygiene.
This is the only surface where the model reasons across things that were never ingested anywhere: the deck a client sent you, your own research, a second MCP server, the open web. Salesforce becomes one source among several. Note that the launch skills are sales skills. Prospecting and pipeline hygiene are judgment problems with dirty inputs, not retrieval problems. That is not an accident.
Slackforce is for questions where the hard part is people. Slackbot reasons across Slack conversation and Salesforce context at once. It can surface which accounts are going quiet, read the support cases and threads that explain why, reassign an owner, open a follow-up task, and draft the win-back email without anyone leaving the channel. The reasoning is ordinary. The coordination is the expensive part. That is the cleanest version of the claim, and Slackforce itself complicates it: the same lane ships Slack Code, a multiplayer coding agent that gives a team a shared session to work with an agent on a project together. Coordination is still the expensive part there. The reasoning it coordinates is not ordinary at all.
Agentforce Coworker is for questions you will have to defend. It stays inside your existing permissions and business rules, keeps nothing outside your trust boundary, and calls the specialized Agentforce agents you have already built and deployed. Narrowest reach, strongest audit story, and the most proven of the three: Salesforce reports one hundred thousand users activated Coworker within its first 35 days.
There is no safest surface. There are two boundaries.
The instinct is to rank the three on a single line from risky to safe, with Claude at the dangerous end because a third party is doing the thinking. That line does not exist. There are two independent boundaries, and each surface crosses a different one.
The vendor and model boundary. Does reasoning leave Salesforce the company? For Salesforce in Claude, yes, and that is the entire point of the product. Salesforce mitigates it directly: business data is used to answer the question at hand and is not retained by the model provider. Zero data retention is a strong answer. It is still a different answer than never left, and in a bank running third-party model risk review, that difference is a six-week conversation. Slack is a Salesforce company, so Slackforce adds no new vendor to your paper. Coworker adds nothing at all.
The publication boundary. Where does the answer land once it exists? Slack is the surface that moves here, and it is worth being exact about what we are and are not saying. Slackbot does not bypass Salesforce permissions, and nothing in the announcement describes a gap. Every person gets an answer scoped to what they are already entitled to see. The exposure worth thinking through is a governance question rather than a security one: a legitimately authorized synthesis can land in a channel whose membership is wider than the membership of the records behind it. Nothing was breached. Something was published, and a published artifact outlives the permission check that produced it. Salesforce in Claude and Coworker are single-player by default, so the answer stops with the person who asked.
Read those together and the picture inverts. Salesforce in Claude carries vendor exposure and no publication exposure. Slackforce carries publication exposure and no vendor exposure. Coworker carries neither, and pays for it with the narrowest context reach of the three.
No surface is safer than the others. They fail different reviews. Which review your organization actually runs is the routing decision.
So the rule: route by where the hard part of the question lives, and by which boundary your business can defend crossing. Not by where your people like to sit.
One caveat on the framework, so you can keep using it in six months. Three surfaces is today’s count, not the shape of the thing. Salesforce says more will be announced soon, and AgentExchange already names interfaces from Amazon Web Services, Google, and Microsoft alongside Anthropic. Route by the boundaries rather than by the surface names. The list will change. The two boundaries will not.
The work moved up the stack
Read this line from the announcement carefully: “No new permissions model, no migration, no custom integration work. Admins connect once and teams get access on day one.”
Take it at face value, because it is true, and understand exactly what it commoditized. Getting a surface connected to Salesforce is now close to free. Getting it to do anything defensible is not. Identity mapping, which actions an agent is permitted to take, what your sharing model actually looks like under load, and how any of it gets observed afterward, none of that moved. What changed is that the connector stopped being the billable center of the project.
The value moved up, to three places:
- Routing. Which workloads belong on which surface, and whether you can defend that answer to a CFO and a CISO in the same meeting.
- Readiness. What your data and sharing model actually look like before you flip the switch. Authorized access to a messy org produces confidently authorized nonsense.
- What happens after. How agent actions get observed, tested, and explained once they are writing back into the systems that run your business.
The deliverable that matters is a routing policy, not an integration project. It is repeatable, and it is the one thing nobody can undercut you on price to deliver.
Where this goes
Benioff traded the interface for the moat, and it was the only move on the board. He is betting that people will work in Claude, in Slack, in whatever comes next, and that the durable position is owning the context, the permissions, the workflow, and the governance underneath all of it. We think he is right.
Which means the companies that get value out of AIforce in the next two quarters will not be the ones that switch on the most surfaces. They will be the ones who decided, deliberately and in writing, which kind of question belongs where, and which boundary they were willing to cross to answer it. In regulated industries that decision has a shorter fuse than most teams expect, which is why we have been writing about where the work actually happens since well before the interface layer had a name.
At Atrium, that judgment is the work: where reasoning should happen, what has to be true before you allow it, and how you prove afterward that it went the way you said it would. It is the same discipline behind $1B in measured customer impact, and it is what our Anthropic and Salesforce practices do together rather than separately.
The connector was never the hard part. It just used to look like it.