Salesforce's AIforce Didn't Add One New AI Risk. It Added Three.

Salesforce has launched a new AI surface roughly every few months since late 2024, and it would be easy to read AIforce - the headline announcement from Dreamforce 2026 - as just the next one. It isn't. AIforce is the moment Salesforce stopped treating 'put Salesforce inside an AI assistant' as a single product decision and turned it into a standing architecture: the same CRM data, the same workflows, and the same permission model, now reachable from Claude, from Slack, and from inside Salesforce's own Lightning Experience, at once. We wrote about the governance stakes of Salesforce in Claude back when it was a single pilot heading toward open beta. AIforce is what happens when that same question gets asked from three directions instead of one.

The short answer

AIforce itself isn't a separate product you buy - it's Salesforce's umbrella term, announced at the Dreamforce 2026 keynote on 15 September, for making Salesforce reachable from outside its own interface. Three pieces matter operationally: Claudeforce (Salesforce in Claude, still beta), Slackforce (several Slack-native surfaces already live), and Agentforce Coworker (marketed as available now inside Lightning, though Salesforce's own developer documentation still carries a 'Beta' label on its billing guide). None of that changes what a Salesforce architect actually needs to check - permission sets, field-level security, write-action guardrails - it just multiplies how many places that same question can now be asked from. If your org has permission debt, this is the moment to run it past an outside Salesforce architecture review rather than wait to see which surface your users reach first.

What Salesforce's AIforce actually changed at Dreamforce 2026

Marc Benioff framed AIforce as a 'dynamic interface' layer that carries Salesforce's data, workflows, business logic, and - critically - its existing permissions into whichever surface an employee already works in. That's an architectural claim, not just a marketing line: Salesforce is trying to stop being a destination and start being a layer that other interfaces call into. Three products carry that strategy today.

• Claudeforce - the Salesforce-in-Claude integration we covered in September, still beta-stage, still limited to a sales-skill set with no published pricing.
• Slackforce - a set of Slack-native surfaces (Slackbot in Lightning Experience, Slackforce Surfaces, 'Big Mode', Slack Code) that Salesforce says are already live, while voice and document-generation features remain in pilot.
• Agentforce Coworker - an autonomous assistant built into Lightning itself, which Salesforce says reached 100,000 activated users within 35 days and is now rolling out more broadly.

A fourth piece, Koa, is Salesforce's own CRM-specific reasoning model, built by post-training NVIDIA's Nemotron 3 Super on patterns drawn from Salesforce's own CRM data. It's in customer pilots now - Formula 1, Xero, Baxter Credit Union, and a handful of other named accounts - with general availability targeted for winter 2026, in US regions first. Koa matters less for what it does today, since most pilot customers won't notice a model swap under the hood, and more for the signal: Salesforce wants an underlying reasoning layer it controls end-to-end, built so customer data doesn't cross the trust boundary during inference - a direct contrast with routing a prompt out to Claude or Gemini, even as Salesforce partners with both on the interface layer above it.

What's GA, what's beta, and what's still pilot

Keynote language and a product's actual, documented status aren't always the same sentence. Verify this table before any of it reaches a line in a business case.

How one question now reaches your org's data

The mechanism is the same regardless of which surface the question starts from - that consistency is the point Salesforce is actually selling.

Who should care right now, and who shouldn't yet

Care now if your org already has meaningful Slack-Salesforce usage, is piloting Agentforce Coworker, or was already on the Salesforce-in-Claude beta list - all three surfaces reuse the same permission model, so a gap any one of them exposes was already there. Don't rush if your Agentforce footprint is thin or you haven't yet decided whether you need an AI assistant layer at all - adding three new doors to a house you haven't finished isn't a priority.

• A 50-500 employee org running Service Cloud with one admin managing permission sets ad hoc: care now. Coworker and Slackforce both reach that same permission surface without an extra approval step.
• A multi-region enterprise already running Agentforce agents scoped to specific topics in Agentforce Studio: care less about urgency, more about consistency - make sure the newly-live surfaces respect the same scoping discipline your existing agents do.
• An org still deciding whether it needs Agentforce at all: don't let AIforce's launch pressure that decision. None of this changes whether Agentforce solves a real problem for you.

A pattern from the field

When we designed a set of Agentforce agents spanning sales, service, and e-commerce for an enterprise client, the deciding factor for each agent wasn't 'can this be built' - it was 'does this specific question need this specific grounding.' Some agents stayed grounded entirely in CRM data through Prompt Templates and Apex-backed actions; a smaller number earned Data Cloud's unified profiles because the question genuinely needed that broader context, not by default. That discipline - scope each surface to the question it actually needs to answer, rather than switching on the broadest available grounding because it's available - is exactly what AIforce's three-surface model now rewards or punishes, depending on whether an org already has it. See the full engagement.

What to do now

1. Audit which of your users already have Slack connected to Salesforce data, Agentforce Coworker enabled, or a Claudeforce pilot seat - treat this as one audit, not three, since they all draw on the same permission model.
2. Re-run the permission-hygiene checklist from our Salesforce in Claude piece against Coworker and Slackforce specifically - the checklist doesn't change, only the number of surfaces it needs to cover.
3. If you're already running Agentforce agents, confirm each one's topic and action scope is still the narrowest grounding that answers its actual question - don't let a newly-live surface inherit broader access by default.
4. Ask your account executive, in writing, whether Coworker's current billing status is Beta or GA for your edition before building a cost model around it.
5. If none of this applies yet - you're not on Slack, not piloting Coworker, not on the Claude beta list - note it and move on; there's no action required today.

What to avoid doing prematurely

• Don't plan a reasoning-model migration around Koa - it's in pilot with a handful of named customers, and GA isn't expected before winter 2026, in US regions first.
• Don't treat 'Agentforce Coworker is GA' as settled fact for budgeting - Salesforce's own developer documentation still uses a Beta label on the billing guide as of this writing.
• Don't assume Hunter, the outbound sales agent, is available just because six of the other seven job-ready agents are - it's pilot-only, with GA planned for November 2026.
• Don't widen Slack-Salesforce access just because Slackforce surfaces are live - 'available' and 'already reviewed for your org's data classification' are two different things.

Frequently asked questions

Is Agentforce Coworker the same thing as Salesforce in Claude?

No. Coworker runs inside Salesforce's own Lightning interface; Salesforce in Claude (branded Claudeforce) runs inside Anthropic's Claude. Both call into the same org data under the same connected-user permissions, which is the point of AIforce - the surface changes, the governance model doesn't.

Does using AIforce require buying anything new?

It depends which surface. Coworker and other Agentforce capabilities are sold through a mix of consumption-based Flex Credits and seat-based Agentforce licensing, and Salesforce hasn't published Claudeforce pricing at all yet. Treat any number you hear before it's in your contract as provisional.

Does this change what a Salesforce admin needs to configure?

Not the mechanics - sharing rules, field-level security, and permission sets still govern access exactly as they did before AIforce existed. What changes is exposure: the same configuration gap is now reachable from more places, so a review that used to be optional is worth doing on a shorter timeline.

Do smaller Salesforce orgs need to act on this immediately?

Only if they're already using Slack heavily alongside Salesforce, piloting Coworker, or on the Claude beta list. An org that hasn't adopted Agentforce at all yet should decide whether it needs an AI agent strategy on its own merits - AIforce doesn't change that underlying decision, it just changes what happens once you're in it.

What we're advising clients right now

This is exactly the kind of moment where a short, outside permission-model review pays for itself before any of these surfaces reaches a production user - not because AIforce is unusually dangerous, but because three new entry points make an existing gap three times more likely to get found by someone other than you. Our senior architects have built and scoped Agentforce capabilities inside live Service Cloud environments, which means we've already had the scoping argument - broad grounding by default versus narrow grounding per question - that AIforce's launch is about to force on a lot of orgs that haven't had it yet. If you want a second opinion before Coworker, Slackforce, or a Claude pilot reaches someone in your org, get in touch.

The bottom line

AIforce isn't worth attention because Salesforce added one new AI assistant - it's worth attention because Salesforce stopped treating 'AI assistant' as a single integration and started treating it as a standing property of the platform, with three live entry points already shipped and a fourth, Koa, arriving underneath them. If your permission model was sound before Dreamforce 2026, none of this should alarm you. If it wasn't, you now have three reasons to fix it instead of one, and a lot less excuse to wait for whichever surface reaches your users first.