The useful change is the combination of ready-made interfaces and Salesforce-controlled execution: employees can ask questions, modify records, and invoke workflows from another application while Salesforce remains responsible for enforcing its business rules. Salesforce’s announcement establishes the core architecture and three initial components—Claudeforce, Slackforce, and Agentforce Coworker—but availability differs across those experiences. For administrators, the immediate decision is which workflows merit a pilot, with Teams availability and the cost of multi-step work still requiring particular care.
AIforce turns Salesforce’s Headless Toolkit into employee-facing products
Salesforce introduced Headless 360 on April 15, 2026, describing a platform whose capabilities could be called through application programming interfaces, Model Context Protocol tools, and command-line interfaces. An API provides a programmatic route to a service; MCP provides a connection through which an AI application can use exposed tools and context. In Salesforce’s model, an agent calls the underlying capability instead of navigating the screens a person would normally use.
September’s AIforce announcement packages that approach into recognizable working environments. Salesforce calls the underlying architecture the Headless Toolkit, exposing data, workflows, business logic, and other platform capabilities through MCP, APIs, plug-ins, skills, and developer tools. AIforce supplies employee-facing experiences on top of that foundation. The distinction helps explain the announcement: the toolkit is what developers build with, while Claudeforce, Slackforce, and Coworker are ways employees encounter those capabilities.
The documented progression is therefore from programmable access toward prebuilt experiences. Salesforce’s April announcement emphasized tools for coding agents, rich interfaces across different applications, and controls for evaluating agent behavior. September adds a prepared Claude sales experience, collaborative Slack interfaces, and an assistant inside Salesforce Lightning. Organizations can investigate those products without first designing an entire front end of their own.
“Headless” also does not mean “without an interface.” Salesforce’s announcement describes interfaces composed dynamically around the work at hand: a user asks for a view, and the system assembles relevant information and actions. A salesperson could work through a Claude-generated view; a team could use an interactive Slack surface. The architectural claim is that the presentation changes while the Salesforce data and business rules remain underneath.
That gives existing Salesforce customers a specific reason to pay attention. Their investment includes approval processes, access restrictions, record relationships, and workflows, as well as the information stored in customer records. Reusing those capabilities through another application could reduce the amount of business logic an integration must recreate. That is an architectural benefit to evaluate, not a measured productivity improvement established by the announcement.
Claudeforce gives Claude 37 sales skills, with beta boundaries
Claudeforce is Salesforce’s partnership with Anthropic; its first product is Salesforce in Claude. Salesforce describes a prebuilt MCP connection and 37 sales skills covering work from prospecting to pipeline hygiene—the maintenance needed to keep sales opportunities accurate and useful. The count is confirmed in Salesforce’s September announcement and product material, rather than resting solely on Techzine’s reporting.
The ready-made packaging is significant. Salesforce says the product replaces work that its own early users performed manually: connecting MCP servers, managing authentication, and assembling skills. Its Claudeforce page describes a plug-in that brings those pieces together. For an IT team, the value proposition is a prepared sales integration instead of a collection of components that must first be joined and maintained.
The described workflows extend beyond asking for a summary of CRM records. Salesforce’s product material includes daily action plans based on pipeline changes, account planning, meeting preparation, and actions routed back through Salesforce. It also describes interactive views generated inside Claude. Those are relevant differences for organizations deciding whether they need an informational assistant or one authorized to change business records.
There is a material discrepancy in Salesforce’s availability wording. The dated September 15 announcement says Salesforce in Claude is available to all customers in beta, after pilots involving Deloitte, GitLab, and Legora. The Claudeforce product page retains wording that describes access for selected pilot customers and a planned September open beta. The announcement supports reporting a beta release, with actual access subject to customer agreements and regional availability; neither record justifies treating it as unrestricted general availability.
Sales is the initial focus. Salesforce’s announcement identifies Tableau analytics and skills for service, marketing, commerce, and industries as future additions. Its product page lists further “coming soon” areas, but those entries are roadmap scope, not capabilities on which a deployment should depend today. A sales-team pilot can evaluate the announced offering; a service or marketing rollout would be buying ahead of the documented release.
Salesforce also describes controls over write-side autonomy on the Claudeforce page. Claude can ask before sending an external email, or be allowed to send once the organization is comfortable with that behavior. The practical distinction is between permission to perform an action and the decision to require a person’s approval before it happens. An account owner may legitimately possess broad authority, while the organization still wants review before an assistant exercises it.
Slackforce makes Salesforce work collaborative inside Slack
Slackforce takes a different approach to the interface. Its headline addition, Slackforce Surfaces, lets users assemble live information from Salesforce, Slack, and other tools into an interactive view that colleagues can filter, explore, comment on, and act on together. Salesforce describes this in its announcement, and SiliconANGLE’s September 15 reporting also identifies Surfaces as a shared interface built from those sources.
The useful difference from a posted summary is the ability to keep working with the information. A written account briefing can inform a conversation, but Salesforce is proposing a surface on which the team can manipulate the view and perform work. Techzine describes sharing, discussing, editing, and filtering Salesforce information inside Slack. The collaboration environment becomes an operational interface, rather than simply the place where someone pastes the result of work performed elsewhere.
Salesforce gives a concrete example of what Slackbot can do on this foundation: identify accounts that have gone quiet, examine support cases and Slack conversations for context, reassign an owner, create a follow-up task, and draft an email intended to recover the relationship. These are vendor-described capabilities, not results from a WindowsForum test. They nevertheless show why the distinction between retrieving information and executing actions is central to this announcement.
A related addition, Slack CRM, supports creating accounts, logging call notes, and updating records through prompts inside Slack. These are recognizable CRM tasks with outcomes a pilot can evaluate. The appropriate success criteria follow directly from the work: whether the intended record was updated, whether the correct field or task changed, and whether the user remained within their authorized scope. A fluent answer in the chat window is only part of that outcome.
For organizations standardized on Microsoft Teams, Slackforce is evidence of Salesforce’s intended interaction model, not proof that the same features are already available in Teams. Surfaces, Slackbot, and Slack CRM have specific Slack descriptions in the launch material. Any Teams evaluation needs its own supported feature and availability boundaries; Salesforce’s broader headless architecture does not establish feature parity between collaboration applications.
Agentforce Coworker brings existing agents into Lightning—and puts Teams on the roadmap
Agentforce Coworker starts in Salesforce’s own Lightning interface. Salesforce describes an assistant that reasons across accounts, activity, and history, then calls specialized Agentforce agents the organization has already built and deployed. This makes Coworker a front door to existing agent capabilities as well as an assistant in its own right. Salesforce says it operates within existing permissions and business rules.
The company’s September announcement says Coworker is immediately available to Salesforce customers and reports 100,000 user activations during its first 35 days. That is an adoption figure supplied by Salesforce, not a measure of sustained use or task accuracy. Techzine separately reports that Adecco announced plans to give its 27,000 employees access. Those figures indicate deployment interest, but the stronger basis for an IT decision remains the work Coworker can perform in a particular organization.
The Microsoft-specific development is Coworker’s intended expansion beyond Lightning. In its September 22 report, Techzine says Microsoft Teams is high on Salesforce’s roadmap and that OpenAI is another intended destination. Its suggestion that Teams could arrive at any time supplies no firm release date, tenant eligibility, or deployment procedure. On that evidence, administrators should treat Teams as a roadmap item when scheduling a rollout.
Salesforce’s launch announcement names Microsoft among companies involved in Headless Toolkit integrations. That confirms the broader partner direction, but it does not establish a release date for Agentforce Coworker in Teams. Keeping those claims separate prevents a general architecture announcement from turning into an assumed product entitlement.
The practical implication for a Teams-based business is straightforward: identify suitable Salesforce workflows now, but tie deployment approval to the specific Teams offering that becomes available. The important scope includes which agents it can invoke and which actions it supports, not merely whether a Salesforce-branded assistant appears in a Teams conversation. Lightning availability alone cannot answer those questions.
Salesforce permissions travel with AIforce, but pricing needs a workflow-level answer
Salesforce’s central governance claim is that requests use existing permissions and business rules: the agent sees what the requesting person is permitted to see, and actions route back through Salesforce. Its announcement also promises zero data retention by the model provider for business data used to answer a request. These are Salesforce’s stated design commitments, and they should be evaluated within the terms of the particular product and customer agreement.
Reusing Salesforce authorization is valuable because an external interface should not create an additional route around CRM access restrictions. It also changes where an administrator should focus a pilot. The question becomes whether the intended Salesforce identity, permissions, and business rules carry through the external experience, and whether the organization has chosen an appropriate level of autonomy for permitted actions. Inherited access control and human approval address different parts of that decision.
The same principle extends to partner-built experiences. Techzine reports Headless Toolkit integrations involving AWS, Google, Lovable, and Vercel, including Gemini Enterprise accessing Salesforce context and Lovable-built applications querying data or performing actions within the connected user’s permissions. Salesforce’s announcement corroborates those companies’ participation in the broader toolkit network, although it does not document every integration’s capabilities.
AgentExchange is the distribution point for this expanding set of applications, agents, tools, and integrations. Salesforce’s April announcement described it as bringing together Salesforce apps, Slack apps, and Agentforce agents and tools. The administrative consequence is that selecting an interface and selecting the underlying capability may become separate decisions. A marketplace listing can make something easier to discover; the organization still needs to decide whether that component belongs in its approved workflow.
Pricing is the less settled part of the proposition. Techzine reports that Salesforce executives did not provide a clear, unified explanation of AIforce and Headless Toolkit costs. Its report identifies several commercial constructs: an Agentforce add-on at $125 per user per month, user licenses at $5 per user per month, and Flex Credits at $500 per 100,000 credits, with a standard AI action consuming 20 credits. These reported prices describe different items, not interchangeable packages or a complete AIforce quotation.
The credit arithmetic is simple even when the bill is not. At the reported rate, one credit costs half a cent, making a 20-credit action cost $0.10. That is a conditional unit calculation, not the cost of a user request, an API call, or a completed business workflow. Techzine specifically reports that the cost of a simple API call remained unclear, so mapping each prompt to a ten-cent charge would be unjustified.
For procurement, the useful unit is the complete task the organization intends to run. The Slackbot example includes examining information, reassigning an owner, creating a task, and drafting an email; the announcement does not specify the billable action count for that sequence. Before scaling that workflow, an organization needs a quote explaining the required licenses, the chargeable operations, and the applicable consumption terms. Techzine’s report of executive interest in outcome-based pricing is a discussion of possible commercial models, not an announced tariff.
AIforce pilots should start with an available workflow, not a promised surface
Start with a bounded task in an available product, and make both its authorized outcome and commercial treatment part of the evaluation. Salesforce in Claude offers a documented sales-focused beta; Coworker has an announced Lightning implementation; Slackforce has concrete collaboration and record-update scenarios. These provide a firmer starting point than a cross-platform deployment whose Teams scope and timing remain unspecified.
The most useful practical takeaways are:
- Evaluate Salesforce in Claude as a sales-focused beta, and resolve access against your customer agreement before promising it to employees.
- Keep Tableau, service, marketing, commerce, and other planned Claude skills outside the committed scope of an initial deployment.
- Choose an explicit action boundary, such as retrieving account context versus updating records or sending external email, and apply the available approval controls accordingly.
- Confirm that the external experience uses the intended Salesforce permissions and business rules, including for actions that modify records.
- Require a task-level cost explanation that distinguishes user licensing, billable agent actions, and API usage instead of treating every prompt as a standard 20-credit action.
- Schedule a Teams rollout only when the specific Coworker offering, supported capabilities, and access requirements are established.
For developers, the toolkit also creates a build-versus-adopt decision. A prepared sales or collaboration experience may cover the needed task; a custom application built on the Headless Toolkit may be appropriate when it does not. Salesforce’s architecture makes both approaches possible, but a custom interface still needs a justified purpose beyond reproducing an experience the vendor already supplies.
AIforce gives Salesforce’s headless strategy a concrete shape: Claude receives packaged sales skills, Slack receives shared operational interfaces, and Coworker provides access to specialized agents from Lightning. The next purchasing decision should follow that same specificity—an available interface, an authorized workflow, and an understandable bill. Teams expands the potential reach of that model, but organizations can assess its underlying value now without treating the roadmap as a shipping commitment.