Agentforce
AIforce vs Agentforce vs Headless 360: which layer you are buying
Three names now describe how work reaches Salesforce without a person clicking through Lightning, and they are not three products. Agentforce is agents that act on your data. Headless 360 is the MCP servers and APIs that expose your org to any client. AIforce is those packaged into surfaces you switch on. This is what you configure in each, who the user is, where governance sits, and how each one bills.
The question every architect gets the day after a keynote like that is whether the company needs AIforce. The question is hard to answer because it assumes AIforce is a thing you add. AIforce is closer to a name for a layer that was already there, and the useful reply is a map of three layers and what you do in each.
Agentforce, Headless 360 and AIforce describe three different ways for work to reach Salesforce without a person opening a Lightning page. They overlap in the plumbing and differ in who the actor is, what you configure, and what you pay for. Get the map right and the “do we need it” question answers itself.
The one-line version of each
Agentforce is the platform for building and running agents: software that takes a request, reasons over Salesforce data with a model, and acts through Flows, Apex and prompt templates. The actor is an agent. You configure topics, actions and guardrails, and you meter it in credits. What Agentforce is covers the parts.
Headless 360 is the set of hosted MCP servers and APIs that expose the platform to any client. The actor is whatever connects: Claude, an AWS assistant, your own app. You configure an External Client App, the OAuth flow and which operations are exposed. I described the hosted MCP server when Salesforce shipped it for Data 360.
AIforce is Salesforce’s packaging of Headless 360 into surfaces you turn on, announced on September 15 as a live interface layer. The actor is a person in Claude, Slack or Lightning. You configure the surface and the permission it runs under.
Salesforce describes the toolkit underneath as an open architecture of MCP servers, APIs, plug-ins and skills, and Patrick Stokes has said the difference from raw Headless 360 is that these are productised into things you switch on rather than build against.
Who is acting
The clearest way to tell the layers apart is to ask who is doing the work.
In Agentforce, an agent acts. A customer or an employee makes a request, and the Atlas engine plans, calls actions and responds. The human may be in the loop for approval, but the reasoning and the tool calls belong to the agent, and the agent runs as a configured agent user with its own permission set. The agent user permissions decision is the governance decision.
In Headless 360, an external client acts, and it acts as the person who authenticated. When Claude’s plugin calls Discover, Describe and Dispatch on the hosted MCP server, the call carries the user’s OAuth token, so validation rules, sharing and Flows apply exactly as they would for that person on a page layout. No agent user is involved, only the user, reached through a different door.
AIforce inherits that. A seller asking Salesforce in Claude for a pipeline review is a person acting through Headless 360, with Claude as the reasoning layer on the client side. Coworker is the case where the two meet: a person asks in Lightning, and Coworker routes the work to an Agentforce agent, so the request starts as a person’s and finishes as an agent’s.
What you configure
Agentforce configuration lives in Agentforce Builder: topics with classification descriptions and scope, actions mapped to Flows, Apex or prompt templates, instructions, guardrails, and the model choice. Since July, new agents are authored on Agent Script. The work is agent design, and most of the build time goes into topics and actions.
Headless 360 configuration is integration work. An External Client App with the MCP scope, per-user OAuth, the API version, and a decision about which operations the server may dispatch. Salesforce’s May 2026 developer guidance on connecting Claude to the hosted MCP servers is the shape of it. Once connected, the client discovers operations itself, which is what makes the layer reusable across clients.
AIforce configuration is the smallest of the three and the one most likely to be underestimated. Salesforce in Claude is one org-level connection. Coworker is a permission set and an enablement decision. Slackforce needs the Slack plan and the Salesforce connection.
Salesforce’s line is that there is no new permissions model to stand up. True, and it means the permissions model you already have is the one every surface will exercise.
Where governance sits
Each layer has one governance seam, and they are in different places.
For Agentforce it is the agent’s own definition: what topics it may handle, what actions it may call, what the agent user may see, and the Trust Layer around the model calls. You govern the agent.
For Headless 360 it is the connection: which operations the server exposes, which client apps are allowed, and the fact that every call runs as a real user. You govern the door, and you rely on the user’s permissions for everything behind it.
For AIforce it is the user’s permissions, full stop. Salesforce’s statement is that every request runs on existing permissions and business rules and every agent sees only what the person asking can see.
Nothing new needs governing, which is exactly why a profile that was over-broad for years becomes a problem the week Claude can read through it. If you enable any surface, the pre-work is a permission review, not an agent review.
How each one bills
Agentforce meters on credits. A standard action consumes 20 Flex Credits, a voice action 30, and the September editions bundle 500,000, 1 million or 2.75 million credits per org. Coworker’s consumption depends on a permission-set choice, and the Coworker post explains which one.
Headless 360 calls are API calls against your org’s API entitlement. The model on the other end bills on the client’s contract, not Salesforce’s.
AIforce bills the way its surfaces do. Salesforce in Claude has no published price and runs on two meters, your Salesforce API entitlement and your Anthropic contract. Slackforce Surfaces are included on Slack Business+ and Enterprise+. Coworker is included with the credit caveat.
The Claudeforce questions page has the current state of each, and none of it is a single AIforce price.
The map on one page
| Agentforce | Headless 360 | AIforce | |
|---|---|---|---|
| What it is | Platform for building and running agents | Hosted MCP servers and APIs that expose the org | Those servers packaged as switch-on surfaces |
| Who acts | An agent, as an agent user | An external client, as the authenticated person | A person in Claude, Slack or Lightning |
| What you configure | Topics, actions, guardrails, model | External Client App, OAuth, exposed operations | The surface and the permission it runs under |
| Governance seam | The agent definition and the Trust Layer | The connection and the user’s permissions | The user’s permissions |
| Billing | Flex Credits per action | API calls against your entitlement | Per surface: Claude contract, Slack plan, credits for Coworker |
| When you need it | Work an agent should do autonomously | You are building your own client | People want Salesforce inside a tool they already use |
Which one you need
You need Agentforce when there is work an agent should do without a person driving each step: resolve a case, qualify a lead, book a slot, and the named agents or your own. If nobody wants an agent to act on its own, you do not need Agentforce for that workflow.
You need Headless 360 when you are building the client yourself: an internal tool, an integration with Amazon Quick or Gemini Enterprise, a custom MCP client. This layer is the one developers use, and the MCP pattern is the thing to understand before touching it.
You need AIforce when people want to work with Salesforce from Claude or Slack and you do not want to build anything. Most organisations fit that description, which is why Salesforce gave it the keynote. The decision is which surface, for which team, with which permissions, and my AIforce post covers the screen-or-surface call per workflow.
Most orgs end up with all three. Agents for the autonomous work, a headless connection or two for the builders, and one or two AIforce surfaces for the people. The mistake is treating them as competing options rather than layers, and buying the top one without reviewing the permissions the bottom two already exposed.
Understanding the basics
Is AIforce a replacement for Agentforce?
No. Agentforce is where agents are built and run. AIforce is how people reach Salesforce from Claude, Slack or Lightning without the Salesforce UI. Coworker connects the two by routing a person’s request to an Agentforce agent.
Is Headless 360 the same as AIforce?
Headless 360 is the set of hosted MCP servers and APIs that expose Salesforce to any client. AIforce is Salesforce’s packaging of those into surfaces it names and switches on. Developers building their own client use Headless 360 directly. Everyone else meets it through an AIforce surface.
Which permissions does an AIforce surface use?
The user’s own. Salesforce states that every request runs on existing permissions and business rules and that each agent sees only what the person asking can see. There is no separate AIforce permission model to configure, so reviewing profiles and permission sets is the preparation.
How is AIforce priced?
AIforce is not priced as one thing. Each surface bills its own way: Salesforce in Claude has no published price and consumes both Salesforce API entitlement and Anthropic tokens, Slackforce Surfaces are included on eligible Slack plans, and Coworker’s cost depends on a permission-set setting that decides whether it consumes credits.
Buy the layer, not the name
AIforce is a good name for a real change: the front end to Salesforce is becoming whichever tool the person is in. But the name sits on top of two layers you may already own, and the decisions that matter, which agents to run and which permissions to expose, live in those layers.
Answer the architect’s question this way. You already have Headless 360 if you are on a current release. You have Agentforce if you have agents. AIforce is the switch that lets people use both from somewhere else, and the only thing to buy first is an afternoon with your permission sets.
If you want the three layers mapped against your org, with the permission review done before the first surface goes on, talk to us, or start with the Agentforce readiness assessment.
