It's been two days of Dreamforce 2026 and I think it's time to talk about what's actually changing for architects, developers and enthusiasts in the Salesforce ecosystem.

As always, Dreamforce is packed with marketing statements and bold narratives, which is why we'll focus strictly on the technical side of those announcements.

AIforce

Salesforce introduced AIforce, describing it as a new interface layer on top of Customer 360, Data 360 and Agentforce.

AIforce is primarily a product layer (keep this in mind) around the headless capabilities Salesforce has already been building, including: Headless 360, Hosted MCP servers, APIs, skills and plugins.

You have already been using Salesforce in Claude, Copilot and other AI Agents for a long time now, therefore from a technical standpoint - nothing has changed.

If you were asleep for the last part of the year though, allow me to remind you what Headless 360 is.

Headless 360 wasn't introduced at Dreamforce. Its Hosted MCP Server entered beta earlier this year and Salesforce expanded its headless capabilities again in August.

The idea is that Salesforce itself provides an MCP layer for discovering and executing Salesforce capabilities instead of making every developer build that layer independently.

Without it, your implementation could look like this:

Claude
   ↓
Your MCP Server
   ↓
OAuth
   ↓
Salesforce APIs
   ↓
SOQL / Apex / Flow
   ↓
if-else conditions
   ↓
Result

There is nothing wrong with this architecture. In fact, this is how many of us have already been connecting AI Agents to Salesforce.

The problem is ownership.

You or your AI Agent has to define the tools, understand the APIs, maintain the contracts and decide which Salesforce endpoint should be called. And when Salesforce changes or extends those capabilities, maintaining the integration remains your responsibility.

Headless 360 moves part of that responsibility back to Salesforce.

The Headless 360 MCP Server exposes four tools:

discover

describe

dispatch

dispatch_readonly

Behind them, Salesforce maintains an expanding set of operations and skills.

Say I ask Claude:

Find Experience Cloud users linked to Contacts with no Title who haven't logged in for 30 days.

Claude does not need a separate tool definition for every Salesforce operation it might potentially use.

It can first ask Salesforce what is available:

Prompt
   ↓
discover(
  "find Experience Cloud users with
   missing Contact Title and no recent login"
)
   ↓
Relevant Salesforce operations

discover performs a semantic search across the operations available through Headless 360 and returns the most relevant ones.

Once Claude decides which operation it needs, it can request its specification:

describe(selected_operation)
   ↓
Parameters
Dependencies
Required APIs
Execution steps

Then it can execute it:

dispatch(...)

or, if the operation only reads information:

dispatch_readonly(...)

That is the actual technical value of Headless 360. Salesforce can add another hundred supported operations behind Headless 360 while the MCP interface exposed to Claude remains the same.

Koa

Salesforce and NVIDIA introduced Koa, Salesforce's first CRM reasoning model for Agentforce.

Unlike AIforce, there is actually a new model behind this announcement.

Koa is based on NVIDIA Nemotron 3 Super and Salesforce has post trained it specifically for enterprise and CRM workflows.

Practically speaking, imagine the following scenario: A customer receives a damaged product and asks for a refund.

Koa could be given tools such as:

Get Order

Check Refund Policy

Create Refund

Create Replacement

Escalate Case

The model needs to determine which tools to use and in which order.

Customer Request
   ↓
Get Order
   ↓
Check Refund Policy
   ↓
Choose Next Action
   ↓
Refund / Replace / Escalate

Salesforce then evaluates whether the model actually completed the task correctly.

The process is repeated across synthetic scenarios covering different workflows, personas and industries. Salesforce says the training environments cover more than 14 industries.

The purpose is not to make Koa know your Salesforce org.

  • It doesn't know your business.
  • It doesn't know your custom objects.
  • It doesn't know your rules.

That information still has to be provided at runtime.

What Koa is trained to understand better is the pattern of enterprise work itself, particularly workflows that require multiple steps, multiple tools and decisions between them.

I suppose we'll see how things turn out in the near future.

Koa Does NOT Replace Atlas

Salesforce has the Atlas Reasoning Engine and now it also has a Koa Reasoning Model.

They are not the same thing and Atlas remains responsible for executing the Agentforce process.

Koa is one model that can be called when that process requires probabilistic reasoning.

Agentforce
   ↓
Atlas
   ↓
Agent Graph
   ↓
Does this step require an LLM?
   ↓
Koa / another supported model

If an Agent already knows:

Amount > $1,000,000
   ↓
Require Approval

there is no reason to ask Koa whether one million is greater than one million.

Missionforce + OpenAI

Another announcement worth mentioning came from Missionforce.

Salesforce announced an expanded OpenAI partnership for government customers where authorized users can work with Missionforce capabilities through ChatGPT.

Technically, this follows the same headless model we've already discussed: ChatGPT becomes another client interacting with Salesforce capabilities.

The more interesting part is the Missionforce Policy Engine.

The goal of this new engine is to take an approved policy document and use an OpenAI model to convert it into structured rules and corresponding test cases.

This creates a separation:

Policy Document
   ↓
LLM interprets it
   ↓
Rule Code + Tests
   ↓
Human Review
   ↓
Deterministic Execution

In this case, once the policy has been converted and approved, the actual decision can be executed through deterministic rules instead of asking the model to reinterpret the same document again.

As someone who has been working with file management systems for quite some time, I've thought about building something of the kind myself and it's nice to see I'm not the only one.

Google & AWS

Salesforce also used Dreamforce to expand its partnerships with Google Cloud and AWS. I want to emphasise “expand” because these partnerships had already been established before Dreamforce.

For Google Cloud, Salesforce announced that Gemini Enterprise can use Salesforce's headless architecture to work with Salesforce data and actions without customers building the entire integration themselves.

Salesforce also confirmed that Hyperforce is already running production workloads on Google Cloud with North American general availability planned for November 2026.

AWS follows a similar direction.

Salesforce is expanding model choice through Amazon Bedrock and exposing Salesforce context and capabilities into AWS products.

These announcements confirm that Salesforce is standardizing the same pattern across more AI platforms:

AI Client
   ↓
Standardized Salesforce Access
   ↓
Salesforce Data + Logic + Actions

We can still build custom integrations where they make sense. The difference is that we increasingly won't need to build the basic connection ourselves every. single. time.

Two Days In

If you're looking for my take so far, the direction is pretty obvious: we're moving towards exposing more and more Salesforce capabilities to different interfaces, such as Claude Code and ChatGPT, allowing them to work with Salesforce data and workflows without leaving the Agent window.

This is good news and there is nothing wrong with moving in this direction.

At the same time, I encourage you to remember that most of your users will still be using the Salesforce interface just as intensively as they were before.

These integrations can consolidate access in some scenarios. In all the remaining ones, please go ahead and improve your user experience.

Salesforce Updates