Salesforce AIforce explained: what a live interface layer means for your org

Of everything announced at Dreamforce 2026, this is the one that changes the shape of a Salesforce programme.

On 15 September Salesforce unveiled AIforce, which it describes as "a live interface layer that brings the full power of Salesforce to wherever people and agents work". The framing in the announcement is blunt: "Instead of fixed UI, AIforce empowers anyone to build composable, intelligent, live interfaces, wherever work happens."

It launches with three surfaces, and it is powered by something called the Headless Toolkit. Both of those matter, but neither is the real story. The real story is in the phrase "instead of fixed UI", and we will come back to it.

#What AIforce actually is

Salesforce says AIforce brings "all the enterprise knowledge inside Salesforce, the data, workflows, business logic, semantics, permissions, security, and governance that already run the business, to any AI interface".

Read that list carefully, because it is doing a lot of work. It is not saying you can query Salesforce from elsewhere. Read-only access to Salesforce data from another tool has existed for twenty years and nobody called it the future of enterprise software. What is being described is the whole operating layer travelling with the data: the rules about who may see what, the logic about what happens next, the actions that may be taken, and the governance that records it.

Underneath is the Headless Toolkit, which Salesforce calls "the open architecture that exposes every element of the Salesforce platform, giving builders and developers MCPs, APIs, plug-ins, skills, and developer tools to create customized AI experiences". The same toolkit is what the AgentExchange partner ecosystem builds on, which Salesforce describes as a network of partners building "interfaces, agents, apps, integrations, workflows, and actions, with a marketplace to discover, buy, and deploy them".

#The three surfaces it launches with

Three very different places, one operating layer behind all of them. That is the design, and it is coherent.

#Why "instead of fixed UI" is the load-bearing phrase

For thirty years, buying a CRM meant buying its screens. The data model, the business logic and the interface arrived as one product, and a large share of every implementation budget went on the interface: page layouts, record types, Lightning pages, the custom component somebody built because the standard one did not fit.

If the interface layer detaches, that spend does not disappear, but it stops being the differentiator. Two organisations can run the same screens and get completely different value out of them depending on what sits underneath.

Which leads to the uncomfortable conclusion, and it is the reason this page exists: when the interface is no longer fixed, the durable value of your org is entirely the quality of its data, its logic and its permissions. Nothing else survives the move. A beautiful Lightning page does not make your contract end date agree with itself. A well-built flow does not help if three fields claim to hold the same status.

Organisations that invested in foundations have just had that investment revalued upward. Organisations that invested in screens have just learned what they actually bought.

#The sentence that should change your roadmap

The most important line in the whole announcement is a security one. Salesforce states: "Because every request runs on existing permissions and business rules, every agent sees only what the person asking can see, and every action routes back through Salesforce."

That is exactly the right architecture, and we have argued for it repeatedly: enforce access at the connection, not in the caller. An agent instructed to respect confidentiality is a request. An agent that physically cannot receive rows the asking user could not open is a control.

But read it again as a statement about your org rather than about Salesforce, and it says something less comfortable. Your existing permission model is now the security boundary for every new surface. Whatever it is today, it is about to be exercised far harder, by far more requests, from far more places, than it was designed for.

Most orgs we assess have at least one of the following, and usually more than one:

• An object left Public Read/Write during an implementation years ago because nobody navigated to it directly
• Field-level security configured on page layouts rather than profiles, so an API read returns fields the interface hides
• An Apex class marked without sharing for a legitimate batch job, now reachable from an agent action
• An integration user with Modify All Data, because it was easier than scoping it

Every one of those was survivable while the only way in was a screen a human had to navigate. None of them are survivable when the platform's own pitch is that agents can reason across accounts, activity and history from three different surfaces.

And note the phrase attached to Agentforce Coworker: "no migration, no new permissions model". That is genuinely good news for deployment speed. It also means it inherits your permission model exactly as it stands, including the parts nobody has looked at since go-live.

#What this does to the centre of gravity

Put AIforce next to the other Dreamforce announcements and a single architecture appears. Koa and Gemini supply reasoning. AIforce supplies interface. Salesforce keeps context, logic, permissions and actions, and the Headless Toolkit is how the other two reach it.

That is the three-layer stack we wrote about in the Salesforce and Google Cloud partnership, and AIforce is Salesforce's own name for the top layer of it. The Google partnership is one consumer of this; Claude and Slack are others.

The strategic implication is worth stating plainly. Salesforce is betting that the valuable, defensible thing is not the screens and not the model, but the governed business context in the middle. We think that is correct, and it is the same bet an enterprise makes when it invests in its data model instead of its page layouts.

#The risk nobody is discussing yet

An interface layer that reaches everywhere also spreads the consequences of a bad context layer everywhere.

Today, if an opportunity's close date is wrong, one person looking at one page sees a wrong date and usually knows enough to distrust it. Tomorrow, that same wrong date is being reasoned over by an agent in Claude, summarised into a Slack thread that three people act on, and used by a Coworker to propose a next step in Lightning. The error does not stay put and it arrives dressed as an answer.

Wider distribution raises the cost of bad data non-linearly. That is not an argument against AIforce. It is an argument for doing the data work before the distribution, rather than discovering it afterwards across three surfaces at once.

#What we would do in the next ninety days

An access trace, first. Not a policy review, a trace. Take the workflow you would most want an agent in, and walk every object and field it touches: the sharing model on each, what a typical user could actually reach through a reasoning chain, and which custom code in the path declares sharing. This is a couple of weeks of work and it routinely surfaces one finding that would have been a serious incident.

Then the context layer. Resolve the facts that disagree across systems, retire the dead fields a model cannot tell apart from the live ones, and write field descriptions worth reading, because descriptions are what an agent uses to decide which field answers a question. Define which actions an agent may take, and the reversal path for each.

Then one surface, narrowly. Agentforce Coworker is the sensible first move for most orgs because it stays inside the trust boundary and needs no migration. Pick one workflow, build a replay set from cases already closed, test refusal in indirect phrasing as well as direct, and name the person who can switch it off without seeking approval.

Then widen. Claude and Slack are where the leverage is, because they are where work happens that never reaches the CRM. But widening before the first three steps are done is how an organisation discovers its permission debt in front of customers.

#The honest summary

AIforce is the most consequential thing Salesforce announced this week, and the architecture is right: one governed context layer, many interfaces, access enforced on every request.

It also quietly relocates where your programme's risk lives. For years the answer to "is our sharing model good enough" was "well, nothing has gone wrong". That answer expires the moment three AI surfaces start reasoning across your records on behalf of every user who asks.

The orgs that get the most from this in 2027 will not be the ones that adopted it first. They will be the ones whose data, logic and permissions were worth exposing.