At Dreamforce 2026 Salesforce said the browser is now optional. Headless 360 makes the platform reachable three ways, through the APIs, the command line, and MCP, with an Experience Layer that renders workflows into Slack, WhatsApp, voice, and mobile without anyone writing custom rendering code. 

Patrick Stokes, President of Applications and Marketing, put it plainly from the stage on 15 September:

Headless 360 was announced at TDX in April and expanded through August. At Dreamforce the architecture picked up three front ends under the AIforce banner: Claudeforce, Slackforce, and Agentforce Coworker.

For the last decade we have largely designed Salesforce around the human experience: what users need to see, which screens they need to navigate, which fields they need to complete, and which workflow they need to follow. 

An agentic experience changes the architectural question. We now need to ask whether, with the Salesforce UI removed, an agent could understand the customer, access the right context, apply the right business logic, and safely complete the outcome. 

There is a fair case for calling this technical debt. We have spent years designing these systems around the end-user experience, and the consequence is that you cannot simply switch on an agentic experience. There is underlying architecture, data, integration, and process work required first to make it effective. By that definition, it is reasonably a form of technical debt. 

That does not mean the existing data model is wrong. It means the criteria for a good data model have changed. 

For Headless 360 specifically, this is the question I would put to an architecture review. If we removed the Salesforce UI entirely and asked an agent to deliver the same business outcome, would our current data model, business logic, and security architecture give that agent everything it needs to do that accurately, efficiently, and safely? 

If the answer is no, that is a strong indicator the organisation needs to evolve its Salesforce architecture for an agentic operating model, rather than putting an agent on top of the existing implementation.

My clients are all asking the same question, which is how we actually deliver this. My answer has not changed since March. Before we talk about the experience, the agent, or what sits on top of Salesforce, there are four things to get right: infrastructure, data, APIs, and security. 

Know what your org is actually running on, what sits on the vendor’s current release line, and what is holding you off it. Customisation that blocks the upgrade path does not just delay new capability. It removes the option to adopt it. 

Agentic architectures will keep evolving quickly. Organisations need a platform that can evolve with them, rather than an architecture where every new capability requires another workaround. 

This is where I think the biggest shift needs to happen. Headless assumes the platform can establish a trusted definition of a customer, account, product, order, case, or whatever business concept the agent needs to reason about. Most organisations have three versions of each, spread across systems integrated at different times for different reasons. 

Historically that was workable. A person can navigate between screens, understand the context, and fill in the gaps themselves. An agent cannot be expected to do that indefinitely. 

If the context required to answer a question or complete an action is spread across multiple objects, systems, and relationships, the agent has to reconstruct it through additional queries and orchestration. That increases latency, complexity, and consumption, and it increases the risk of an incomplete or incorrect outcome. An agent also reasons best when business concepts and relationships are represented clearly. Where important context exists only indirectly, through related records or free-text fields, it has less reliable grounding to work from. 

The data model therefore needs to be designed not just for how a person uses Salesforce, but for how an agent needs to understand the business. This is one of the longest pieces of work and, unsurprisingly, one of the easiest to defer.

My colleague Carlos Langle has written about the data foundation enterprises keep skipping.

Business logic has to be available as a callable capability, deliberately, with a clear contract and an owner. Not exposed by accident because somebody needed a quick integration in 2022. 

An agent needs to know what it can do, what inputs are required, what it will return, and what rules govern the action. That means looking beyond the APIs themselves and reviewing where business logic currently lives across Apex, Flow, validation rules, integrations, and other layers. 

The question becomes whether an agent can reliably invoke a business capability without having to understand the implementation behind it. If not, the architecture is not really agent-ready.

Permission design built around what a person could see on a screen behaves differently when the screen is gone and the request arrives through an API or an agent. This needs to be tested against the new access pattern rather than assumed to carry over. 

The challenge is no longer simply “can Dave see this record?”. It becomes whether this agent can access this information, in this context, on behalf of this user, and whether it can take this action. That requires security, sharing, identity, and permission models to be part of the agentic architecture from the beginning.

Get those four things right and years of platform investment become reachable from anywhere: a Salesforce interface, an external application, Slack, an API, or an agent. Get them wrong and you have exposed bad data, fragmented business logic, and legacy security through a faster channel. 

That is the risk organisations need to understand. Headless is not just removing the UI. It exposes the quality of the architecture underneath it. 

Headless does not remove the interface. It relocates it. Your people still need somewhere to do the work, which in many cases means Slack, an application they already have open, or an agentic interface embedded in an experience they already use. That is a change management programme, and it lands on the same teams already absorbing three other changes this year. The technology may change the interaction model quickly. Changing how an organisation actually works takes longer. 

I also do not believe the no-UI message holds yet. B2C customers and end customers will still need to log in. Organisations are deeply invested in Salesforce and have spent years and significant money setting it up, and for some of them getting to a genuinely headless model would mean starting again. That is a real cost, and it is not the cost the announcement describes. 

The market is still early too. Jason Andersen at Moor Insights and Strategy, writing before Dreamforce, described Headless 360 as a promising architecture in search of a repeatable go-to-market, and named discoverability and pricing as unresolved. That is an important distinction. The architectural direction can be clear while the commercial pattern is still being worked out, which is exactly why I would do the foundation work now and let the experience layer evolve as the market matures. 

None of this is theoretical for us. Over the past year my team has taken a national media organisation live on an order management solution built on Salesforce core, integrated with its ad-serving ecosystem, with Data Cloud underneath it. We also rebuilt an emergency services activity reporting platform on Experience Cloud, replacing an interface that was costing a distributed field workforce time on every submission. 

Neither project was positioned as an AI story. Both were platform and transformation programmes. What they have in common is a foundation that can support an agentic conversation: the data model is structured around meaningful business concepts, business logic is deliberately exposed, integrations are understood, security and ownership are defined, and the configuration is governed. 

That means the next experience does not require starting again. It can build on the investment already there. 

The organisations that cannot yet have that conversation are rarely short of ambition. They are usually carrying three, five, or ten years of decisions nobody has revisited, because the existing UI still works.