Dreamforce always comes with a pile of announcements, and this year most of them had AI in the name. After going through everything Salesforce put out, one thing stood out: Salesforce is making it easier to use Salesforce without being in Salesforce. Their own line for it was "AI replaces the UI."
AIforce is the clearest example. It takes the data, automation, permissions and business logic you've already built in Salesforce and makes them usable from other AI tools: Claude, Slack, an agent, or a custom application your company builds. Salesforce is still the system of record. It just doesn't have to be the interface anymore.
Sorting Out the Names
The naming gets confusing fast.
Salesforce introduced Headless 360 at TDX earlier this year, then folded it into AIforce in September. They are mostly the same idea under a new name. Headless 360 was the raw MCP servers and APIs, and AIforce is those pieces packaged into products. Around the same time, "Agentforce" dropped out of a lot of product names, though Agentforce 360 itself kept it.
Claudeforce brings Salesforce into Claude using AIforce, a prebuilt MCP server and 37 sales skills. There's also a Claude Code plugin with more than 40 skills for development work. It's in beta, and Salesforce says Deloitte, GitLab and Legora piloted it.
Slackforce takes the same idea into Slack. And for people who stay in Lightning, Agentforce Coworker puts an AI teammate inside the interface they already have. Salesforce says 100,000 users turned it on in its first 35 days.
Get past the product names and the idea is simple: keep your data, permissions, automation and business logic in Salesforce, and let people work with it somewhere else. I wrote about connecting Claude to a Salesforce org with MCP back in April. Dreamforce made it clear that Salesforce now sees that pattern as a core part of the platform.
Slack Is Becoming Part of the Salesforce Experience
Slackforce makes more sense when you look at it this way. A sales rep shouldn't have to open Salesforce every time they want to check an account, update an opportunity or create a task. If they're already in Slack, let them do it there.
Slackbot can now work across conversations and Salesforce data, and Slack CRM lets users create and update records without opening a separate CRM window. It all runs under the identity and permissions the org already has.
For companies that have always struggled with Salesforce adoption, that matters. Instead of trying to convince every user to spend more time clicking around Salesforce, bring Salesforce to where they're already working.
Slack Code
Slack Code brings coding agents into shared Slack channels, so AI development doesn't have to happen between one developer and an agent in a private window. A team can see what the agent is working on, review the plan, look at the changes and work through it together.
I don't think developers are going to abandon their IDEs and start writing everything in Slack. But as agents take on larger pieces of work, this gets more useful. If an agent is working on something for 20 minutes, an hour, or eventually much longer, having that work visible to the rest of the team stops being a nice-to-have.
The MCP Pricing Question
This is the part I most want to see play out.
MCP lets tools like Claude and ChatGPT work with Salesforce data and actions under the org's security model. Salesforce is building managed MCP infrastructure around that. The open question is what the economics look like at scale.
A customer is already paying Anthropic, OpenAI or another provider for the model doing the reasoning. Depending on which Salesforce capabilities the agent uses, there can also be Salesforce consumption costs on the other side. Salesforce didn't publish pricing for any of this at Dreamforce. The announcement carries the standard "pricing and packaging are subject to change" line. Early coverage aimed at CIOs already flags token use as "not zero," and points out that token metering, caps and chargeback aren't things most CRM programs have ever had to govern.
That could all turn out to be reasonable. Salesforce's managed MCP understands metadata, permissions, relationships, validation rules and governance, and it keeps model providers at zero data retention. Building all of that correctly yourself is real work.
But it creates an architecture decision: use Salesforce's managed MCP, or build your own?
Salesforce has mature APIs and MCP is an open standard. A company could build a much smaller server that exposes only what its agents need. This is work we do for clients, and for a sales team it might be five tools: look up an account, list open opportunities, update a stage, log an activity, create a task. Nothing else is reachable, which is its own kind of security model.
Of course, then you own it. You secure it, maintain it, handle permissions correctly and keep up with changes to both Salesforce and MCP.
For many companies the managed option will make more sense. But if MCP usage gets expensive at scale, more companies will do the math on building their own.
What Changes for Architects
For a long time, Salesforce architecture has been about what happens inside Salesforce: objects, Flows, Apex, LWCs, Lightning pages and the experience around them. All of that still matters. What's changing is where the person using it sits.
That changes the conversations we have with customers. Instead of only asking what to build inside Salesforce, we'll also be asking where people want to work, how Salesforce should connect to those tools, and whether the integration layer should be managed by Salesforce or built for the business.
That's the part of Dreamforce 2026 I expect to matter long after the product names change again.