What AIforce and Agentforce Add to Salesforce

The Platform Is Becoming an Interface and an Agent Runtime

Salesforce now serves as both a place where people run CRM processes and a platform that places its context and capabilities inside other AI interfaces while running agents of its own.

That sounds like one change until the boundaries are made explicit.

Agentforce is the agent-driven layer of the Salesforce Platform. It provides agent experiences, actions, Agent Script, APIs, SDKs, testing surfaces, and developer tooling for building and operating agents that work with Salesforce data and business behavior.

AIforce is a different surface. Salesforce describes it as a live interface layer that brings the platform’s data, workflows, business logic, semantics, permissions, security, and governance to wherever people and agents work. The announced interfaces include Salesforce itself, Slack, Claude, and other places where an AI interaction can begin.

Underneath that distinction, Salesforce positions the Headless Toolkit as an open architecture for exposing the platform through MCPs, APIs, plug-ins, skills, and developer tools.

The important architectural shift is the application gaining more than one front door, with some of those front doors interpreting a goal before selecting a capability.

The question for an architecture team is therefore not “Should we use AIforce or Agentforce?” It is:

Which surface owns intent, which surface owns context, which runtime owns authority and execution, and what evidence proves the requested business result?

This is the second post in AI-Native Architecture on Salesforce. The opening post described how Salesforce applications evolve from explicit CRM automation toward AI-assisted work. This post separates the new surfaces that make that evolution visible.

Salesforce Before These Surfaces

Before the current agentic layer, the Salesforce application had a familiar shape.

A user entered through the Salesforce UI, an integration called an API, or an automation started from a known trigger. The application assembled record context, applied metadata and permissions, ran Flow or Apex, committed a transaction, and sometimes published an event or called an external service.

The interface and the runtime were closely related. Even when Salesforce exposed APIs, the domain model, business rules, and permissions were still understood as part of one application boundary. A team could draw the main path from a screen or integration to the data model and automation that followed.

That did not mean the architecture was simple. Salesforce teams still had to deal with sharing, field access, governor limits, API capacity, asynchronous delivery, deployment dependencies, and configuration drift. But the application usually had a recognizable front door and a known set of operations behind it.

The user asked for a report, update, approval, or task. The application ran a named path.

Today: Two New Ways to Enter the Application

AI changes the front door in two related but different ways.

Agentforce: an agent runtime inside the platform

Agentforce lets a Salesforce-native agent interpret a conversation, route work to a subagent, gather or receive context, and select actions. Salesforce’s current developer documentation describes Agent Script as a language that combines natural-language instructions with programmatic control. Deterministic logic can run business rules, set variables, branch, and run actions; prompt instructions are sent to the language model for interpretation and response.

That combination matters. Agentforce is an agent workflow with explicit places for routing, variables, transitions, actions, and model reasoning, grounded in Salesforce data.

An action can call a Flow, prompt template, or Apex class. An action can also be exposed as a tool that the language model may choose based on the current context. The same application therefore supports two kinds of control:

• the agent definition can run a capability in a specified sequence;
• the model can choose among tools that the agent makes available.

When order is part of correctness, the first form matters. A request to retrieve an order, check eligibility, and then prepare a return should not depend on the model remembering a required sequence. The path can be expressed as deterministic action chaining, with the model handling the parts of the interaction that actually benefit from interpretation.

Agentforce therefore adds a model-mediated decision layer to the Salesforce runtime. It can change how a request is understood, routed, and composed, while the runtime retains ownership of the transaction, permission, and business definition of success.

AIforce: a Salesforce application surface beyond the Salesforce UI

AIforce changes where the interaction can begin. The announced architecture carries Salesforce’s data, workflows, business logic, semantics, permissions, security, and governance into other AI interfaces.

That means a person may ask a question in a workspace where another interface is visible. An external AI interface may retrieve Salesforce context, present an answer, and offer a governed action from the place where the work already happens.

The phrase “from the user’s existing workspace” describes an application-boundary change. The interface has moved while the business capability remains attached to an owned Salesforce contract.

AIforce’s architectural promise is that the request still routes back through the platform’s existing context, permissions, business rules, and action surfaces. The interface changes; the authority and the system of record are meant to remain attached to Salesforce.

The Headless Toolkit: the exposure and composition substrate

The Headless Toolkit sits at a different level again. Salesforce describes it as an open architecture that exposes elements of the platform through MCPs, APIs, plug-ins, skills, and developer tools.

This is the layer that makes “Salesforce anywhere” composable. It can help a builder connect an AI interface to Salesforce capabilities or create a new experience on top of Salesforce’s application model.

An exposure mechanism becomes a business contract when its capability, authorization, input semantics, idempotency, and outcome verification are explicit. MCP can make a capability discoverable, an API can make it callable, and a plug-in can make it convenient.

The Headless Toolkit widens the set of consumers while preserving the need for a governed capability boundary.

Agentforce and AIforce open different surfaces, but the durable path still runs through Salesforce context, governed capabilities, execution, and evidence.

One Application, Several Front Doors

The architectural difference is easiest to see as a path.

conversation or request
  -> interface surface
  -> Salesforce context and semantics
  -> agent routing or capability selection
  -> identity, policy, and action contract
  -> Flow, Apex, platform logic, or external boundary
  -> state change
  -> verified outcome

Each surface follows the same responsibilities through a different path.

An Agentforce interaction may begin and remain inside Salesforce. Agentforce can route to a subagent, expose actions as tools, and combine deterministic instructions with model reasoning.

An AIforce interaction may begin in Slack, Claude, or another supported AI interface. The external surface needs a way to request Salesforce context and capabilities, but the Salesforce platform remains the place where permissions, business logic, and state-changing actions are governed.

An API, MCP server, plug-in, or skill may expose a lower-level capability for a different consumer. That consumer may be a human-facing application, an autonomous agent, a development tool, or an integration service. The protocol says how to interact. The Salesforce application still has to define what the interaction means.

This is why the words “agent,” “interface,” “tool,” and “platform” should not be collapsed into one layer.

A Concrete Example: The Opportunity Review

Consider a sales leader asking:

Find open opportunities that are at risk because of a pricing or delivery issue, summarize the evidence, update the owner, create a follow-up task, and notify the relevant team.

Before AI: a known application path

A Salesforce user might open a report, inspect opportunity records, check a pricing or delivery system, edit an owner, create a task, and send a message. A Flow or Apex action could automate parts of the sequence. An integration could call an external service. An event could notify another subscriber.

The work was distributed, but the user knew which screens and actions they were invoking. The architecture team could assign an owner to each step.

With Agentforce: the platform coordinates an agent interaction

An Agentforce agent can interpret the request, route it to a suitable subagent, retrieve context, and propose actions. The agent may use a tool to find candidate opportunities or call an action that checks pricing status.

The critical design decisions remain outside the model’s prose:

• which records count as open;
• which pricing and delivery sources are authoritative;
• whether “at risk” is a rule, a calculated signal, or a model-generated hypothesis;
• whether changing the owner requires confirmation or approval;
• whether the task and notification belong in one local transaction;
• whether the external notification can be retried safely;
• what evidence proves that the owner changed and the notification was accepted.

Agentforce can make the interaction more flexible while keeping these decisions visible for the architecture and runtime.

With AIforce: the interface moves closer to the work

The same request may begin in an external AI workspace. The person can work from that interface while AIforce brings the relevant Salesforce context and governed capability into the interaction.

That is a meaningful experience improvement. It can also expose a dangerous assumption: if the answer appears in the external interface, people may treat the external interface as the application.

The external surface serves as an entry point and presentation layer. Salesforce remains the owner of the CRM record, the action contract, the permissions that apply, and the state change. An external notification service remains the owner of delivery. The returned summary should link to verified state from those owners.

With the Headless Toolkit: builders compose new surfaces

The toolkit makes the boundary available to builders. A team may use an API, MCP server, plug-in, skill, or developer tool to create a specialized experience around Salesforce data and actions.

That flexibility is valuable when a specialized interface better fits the job. It also shifts responsibility toward the builder. The new interface must preserve the meaning of the capability, surface relevant limits and approvals, carry the right identity, and report partial or uncertain outcomes honestly.

Headless design keeps responsibility with the capability and runtime rather than with a particular screen.

What the New Surfaces Actually Add

1. The front door becomes portable

Salesforce can participate in work that starts in a CRM screen, a collaboration workspace, a customer channel, a coding environment, or an AI interface. The application boundary now extends beyond the visible UI.

This is useful because work rarely follows one application’s navigation. It is risky because the external surface may not carry the same context, identity, confirmation affordances, or error states as the original application.

2. Capability descriptions become part of the application

When an agent chooses among actions or tools, the description of each capability influences selection. Names, inputs, outputs, availability conditions, and instructions become part of the effective program.

That makes action design closer to API design than to copywriting. A vague description can produce the wrong selection. An overly broad action can hide important consequences. An output that says “success” without exposing the committed state invites the interface to overclaim.

The action contract should say what the capability does, what it may change, which inputs it needs, what it returns, and what still requires verification.

3. Context and authority can travel together or be split accidentally

AIforce’s promise depends on carrying Salesforce context and governance to another interface. Agentforce’s promise depends on grounding agent behavior in Salesforce’s application model.

Context and authority are separate responsibilities. An agent may retrieve a record while mutation requires a separate authorization check. A person may see an opportunity while an owner change requires approval. A tool may be callable by an interface while the business action follows its own policy gate.

Treat retrieval, interpretation, authorization, and mutation as separate checkpoints.

4. Platform coordination preserves boundary ownership

The deeper opportunity is platform coordination. Salesforce can assemble context, route agent work, expose capabilities, apply permissions, run local logic, and return structured results across more interfaces.

Platform coordination connects external systems while each system retains ownership of its transactions and failure modes. Payment, pricing, delivery, messaging, and data sources remain separate boundaries, and the overall workflow reports their state explicitly.

The Boundary Checklist

Before exposing a Salesforce capability to Agentforce, AIforce, or another interface, answer these questions:

Boundary	Question	What to make explicit
Interface	Where can the request begin, and what can the user see there?	Context, confirmations, progress, errors, and escalation.
Identity	Which person, agent, integration, or service principal is acting?	User context, sharing, field access, consent, and audit identity.
Context	Which records and external facts are relevant and current?	Source authority, freshness, provenance, and retrieval scope.
Capability	What bounded operation is being exposed?	Inputs, outputs, side effects, limits, and reversibility.
Policy	Which actions need confirmation, approval, or denial?	Deterministic rules outside the model’s interpretation.
Execution	What commits together inside Salesforce?	Flow, Apex, transaction scope, limits, and failure state.
External boundary	What happens outside Salesforce?	Timeout, retry, idempotency, delivery status, and reconciliation.
Evidence	What proves the business result?	Proposal, authorization, execution, committed state, and independent verification.

The checklist is deliberately platform-shaped but product-name independent. It should work for an Agentforce action, an AIforce interaction, an MCP tool, a REST endpoint, or a custom interface built with the Headless Toolkit.

What to Design Now

Start by cataloging capabilities, not interfaces. For each operation, write the domain contract once and decide which surfaces may invoke it. Keep a stable capability boundary underneath the conversation, UI, API, MCP server, or plug-in.

Separate model choice from authority. A model may select a tool; the runtime must still determine whether the acting identity can invoke it with those inputs on that record.

Separate retrieval from mutation. A context provider can find candidates, but the state-changing action should recheck identity, record state, policy, and invariants before commit.

Separate the local transaction from external coordination. If a Salesforce update and an external notification cannot commit together, expose intermediate states such as prepared, committed, delivery_pending, delivered, and reconciliation_required.

Finally, test the interfaces as part of the application. Test whether a model selects the right capability, whether deterministic logic rejects invalid inputs, whether permissions hold across channels, and whether the result can be verified after a timeout or duplicate request.

Failure Modes

The interface becomes the system of record

An external assistant summarizes a request convincingly, and the team forgets that the Salesforce record or downstream service owns the actual state. The remedy is to report source-of-truth state, not conversational confidence.

Protocol mistaken for permission

An MCP tool or API may be reachable while authorization still depends on identity and policy. Keep connectivity, identity, and policy explicit at the runtime boundary.

Context mistaken for authority

The agent can retrieve a record and therefore appears able to act on it. Retrieval scope and mutation authority must be checked separately.

Product names treated as architecture

Teams sometimes describe a design as “AIforce” or “Agentforce” while the context owner, action contract, transaction, and evidence path remain unnamed. Product names are useful handles; the boundary definition comes from those responsibilities.

Hidden external atomism

The interface tells a user that the owner changed and the team was notified. In reality, the local update committed and the notification timed out. The system needs status, retry, idempotency, and reconciliation rather than a single optimistic sentence.

Capability sprawl

Every new channel receives its own slightly different action definition. Over time, permissions, validation, and outcome semantics drift. Reuse the domain capability and adapt the interface around it.

Build It Once

Create a capability card for every Salesforce operation that an agent or external interface may invoke:

capability:
purpose:
allowed_callers:
required_context:
acting_identity:
inputs:
possible_side_effects:
policy_and_approval:
local_transaction:
external_dependencies:
retry_and_idempotency:
result_and_intermediate_states:
verification_query:
audit_evidence:

Then map each front door to that card. Agentforce may choose the capability through a tool, AIforce may surface it in another interface, and an API or MCP consumer may call it directly. The card remains the durable contract.

Will These Terms Survive?

Terminology durability: AIforce, Agentforce, and Headless Toolkit are current Salesforce product and architecture names. They may be renamed, repackaged, or split as the platform evolves.

The durable distinction is more general:

• an agent runtime interprets intent and coordinates model-mediated work;
• an interface layer brings application context and capabilities to where work begins;
• an exposure layer makes capabilities available through APIs, protocols, plug-ins, or skills;
• the application runtime owns authority, deterministic execution, state, and evidence.

That distinction will remain useful even if the current labels move.

Where It Fits in the Map

This post extends the series map from platform substrate to interface and capability boundary:

platform substrate
  -> metadata and data
  -> transactions and limits
  -> identity and authority
  -> APIs and events
  -> deployment and evidence

agentic surfaces
  -> Agentforce runtime
  -> AIforce interface layer
  -> Headless Toolkit exposure layer
  -> governed Salesforce capabilities

The next post asks how much of the agent’s control flow should be explicit. Agent Script is a useful test because it places deterministic logic and model reasoning in the same workflow.

Sources

• Salesforce: AIforce announcement
• Salesforce Developers: Get Started with Agentforce and AI Agents
• Salesforce Developers: Get Started with Agentforce APIs and SDKs
• Salesforce Developers: Agent Script Language Characteristics
• Salesforce Developers: Agent Script Reference: Actions
• Salesforce Developers: Agent Script Pattern: Action Chaining and Sequencing

More in This Series

• Post 01: How Salesforce Applications Evolve with AI