Salesforce’s Headless 360 announcement at TDX 2026 reframed what a CRM platform actually is. The harder question for most enterprises is whether their operating model can keep up with what the technology now exposes.
On 17 April 2026 in San Francisco, Salesforce unveiled Headless 360, the result of an architectural rebuild that began two and a half years ago. The pitch is direct. Every capability in the Salesforce platform is now exposed as an API, an MCP tool, or a CLI command. More than 60 new MCP tools and 30 preconfigured coding skills give agents complete, live access to records, automations, flows, and platform services. A new experience layer renders interactive components such as decision tiles, rebooking workflows, and status cards into Slack, Teams, WhatsApp, mobile, ChatGPT, Claude, Gemini, and any client that supports MCP apps. The browser, in other words, is optional.
Joe Inzerillo, Salesforce’s President of Enterprise and AI Technology, framed the shift bluntly. The endpoints are no longer for humans clicking through screens. They are for agents working on a person’s behalf. That is a different operating assumption from the one most CRM programmes were built on, and it explains why the announcement matters even to organisations that have no immediate plan to deploy autonomous agents.
What did Salesforce actually announce with Headless 360?
Salesforce Headless 360 is an architectural redesign that exposes every Salesforce platform capability through an API, an MCP tool, or a CLI command, allowing AI agents and external clients to invoke records, flows, automations, and platform services without requiring a Salesforce browser session. It includes more than 60 new MCP tools, 30 preconfigured coding skills compatible with Claude Code, Cursor, Codex, and Windsurf, and an experience layer that renders interactive components natively into Slack, Microsoft Teams, WhatsApp, ChatGPT, Claude, Gemini, mobile, and any MCP-compatible surface. It was unveiled at TDX 2026 on 17 April 2026 as the result of a 30-month architectural rebuild.
The release also includes a layer of production controls that close gaps developers had previously been forced to fill with custom tooling. The Testing Center identifies logic gaps and policy violations before launch. Custom scoring evals grade agent decisions against domain-specific standards. Agent Script lets teams pin behaviour to explicit business logic where reasoning freedom is unsafe. Observability and session tracing make root-cause analysis possible when an agent drifts in production, with Salesforce promising resolution in hours rather than weeks. A/B testing runs multiple agent versions against live traffic at the same time.
Bundled alongside the platform release is Agentforce Vibes 2.0, the development companion that now supports Claude Sonnet and GPT-5 and claims a 40 per cent reduction in build cycle times by collapsing the loop into a single connected experience. The other named products to know in this announcement are Agent Fabric, Data 360, and DevOps Center MCP. No public pricing or general availability dates were attached to the headline products, which is worth noting for anyone planning a 2026 roadmap.
Why is every capability as an API a bigger deal than it sounds?
A headless CRM separates the platform’s underlying capabilities from a fixed user interface. Instead of forcing every user, human or agent, through one console, the system exposes its functions as discoverable, callable services. The same record update, approval flow, or decision logic can be triggered from a Slack thread, a voice channel, an external coding agent, or a third-party assistant, without bespoke integration work. The browser becomes one of many possible surfaces, not the canonical one.
The reason this matters more than the marketing suggests has nothing to do with novelty. Salesforce has had APIs for years. Power Platform has connectors. HubSpot has an API graph. What changes here is the assumption underneath the platform. Headless 360 is not building a better screen. It is conceding that the screen is no longer the centre of gravity. That shift, once accepted, breaks a lot of programme assumptions: the way teams train users, the way administrators govern access, the way leaders measure adoption, the way architects assemble customer journeys.
Most CRM programmes are still designed for a world where the licensed seat opens a browser tab. Headless 360 quietly retires that mental model and replaces it with one where capability invocation, not screen visits, becomes the unit of work. Adoption metrics that track logins start measuring the wrong thing. Training that focuses on console navigation starts solving a problem nobody has. Even the licensing conversation shifts, because the value of a seat is no longer about who sees the platform but about who and what is allowed to call it.
What is operating debt and why does it block agent adoption?
Operating debt is the accumulated cost of capabilities that are embedded inside applications, distributed across teams, and only partially defined as discrete services. In CRM terms, it shows up as quoting logic spread across three different orgs, a contract approval flow that lives half in Salesforce flows and half in a manager’s head, a refund policy enforced by tribal knowledge rather than a callable rule. Operating debt is the reason most agents struggle: they need clean, discoverable, well-bounded capabilities to invoke, and most enterprises have never written theirs down that way.
Industry analysis of the announcement, including a sharp piece by diginomica, has landed on the same point. The technology is the easy part. The hard part is whether the enterprise has done the work to define what its capabilities actually are. A platform that exposes 60 MCP tools is only useful if the business has defined the equivalent capabilities on its side. Most have not. Most have applications, processes, and workflows, but capabilities, in the agent-readable sense, are scattered, redundant, or simply not articulated.
Until that gap is closed, exposing more endpoints just means agents can fail more efficiently. Pilot programmes will look promising in narrow use cases where one team has happened to define a capability cleanly, and they will then stall the moment they try to cross a process boundary that nobody owns. The pattern is familiar to anyone who has watched RPA, then iPaaS, then low-code, run into the same wall. Headless 360 raises the ceiling of what a platform can do. Operating debt sets the floor of what an enterprise can use.
How do you define capabilities so agents can actually use them?
Making a CRM capability agent-ready means writing it down as a discrete, named, parameterised service with an explicit owner, a defined input and output, a policy boundary, and a measurable outcome. In practice that requires three steps. First, list the capabilities a business genuinely runs on, not the apps they live inside. Second, map each capability to a single source of truth and a single owning team. Third, define the conditions under which an agent is allowed to invoke it, including data scope, authorisation, and audit. Without those, an agent has nothing safe to call.
This is where most Salesforce roadmaps stop being a technology project and become an operating model project. The work of inventorying capabilities, retiring duplicates, naming the owner, and writing the rules is not glamorous. It is also not optional if Headless 360 is going to do anything for the business. The pattern repeats across Salesforce, HubSpot, and Dynamics 365 deployments. The platforms have shipped agent-ready features faster than enterprises have rebuilt themselves to consume them.
A useful starting point is to pick six to ten high-value capabilities, the ones a customer or an internal user pays for outcomes around, and treat them as a pilot capability catalogue. For each, write a one-page description: name, owner, trigger conditions, input parameters, output, dependencies, policy gates, audit fields, and a success metric. That artefact is what makes the platform’s MCP tooling useful. It is also what makes the next CRM migration easier, because the catalogue is portable across platforms in a way that flows and screens never were.
What governance does an agent-first platform demand?
Governing AI agents in Salesforce requires four controls in place before agents are allowed to act on production data. The first is identity and authorisation, meaning every agent invocation is tied to a service identity with scoped permissions and clear audit trails. The second is policy enforcement, ensuring agent decisions can be checked against business rules through tools like Salesforce’s Testing Center and custom scoring evals. The third is observability, including session tracing so root-cause analysis is possible when an agent drifts. The fourth is human-in-the-loop checkpoints for irreversible actions, such as refunds, contract changes, and customer communications.
Salesforce has built the production controls into the platform, which is a meaningful step. Testing Center, custom scoring evals, Agent Script, A/B testing, and session tracing close gaps that previously required custom tooling. But the controls only work if someone has decided what good looks like. An A/B test on agent behaviour is only useful if the business has agreed on the success metric. A scoring eval is only useful if the policy it scores against has been written down. The platform now offers the instruments. The organisation still has to play the score.
Compliance teams will want to pay close attention to session tracing in particular. Audit obligations under Europe’s evolving AI rules and sector-specific regulators do not vanish because the action came from an agent rather than a logged-in user. If anything they intensify. The traceability bar is higher when the actor is non-human, the decision is opaque, and the user who triggered the request never saw the underlying logic. Treat session tracing as a regulatory artefact, not a developer tool, and the budget conversation becomes much easier to have.
Where does this leave the human user experience?
Headless architecture does not remove the human interface. It relegates it. The Salesforce console will still be the cockpit for power users, administrators, and complex case work. What changes is that routine record updates, status checks, approvals, and workflow handoffs increasingly happen in whatever surface the user already lives in: Slack for the sales rep, Teams for the operations manager, mobile for the field engineer, ChatGPT for the analyst exploring an account. The platform follows the user. The user no longer follows the platform. That is good news for adoption, which has historically suffered when employees are forced into a console they only open under duress.
The risk is that the experience layer becomes a thin veneer over a stack the user no longer understands. When an agent renders a rebooking card into Slack, the user sees the card, not the policy that produced it. That makes UX faster and governance harder. The audit trail has to compensate for the visibility the user no longer has. This is where session tracing earns its place in the toolkit, less as a developer luxury and more as the regulatory backbone of an agent-driven CRM.
The Sirocco perspective
Headless 360 is a milestone, and we think it is a clarifying one. It exposes a question Salesforce customers have been able to defer for a decade: what does this organisation actually do, expressed as a set of capabilities a service can call? Most CRM programmes have answered that with applications and workflows, which is why most agent pilots stall. The platform now demands a different artefact, a clean, owned, governed catalogue of business capabilities, and we believe this is where the next 18 months of CRM work will sit.
For our clients, the practical move is not to chase the new MCP tool list. It is to take an honest look at the capabilities the business runs on, identify which ones are well-defined enough to expose to an agent today, and prioritise the remediation of the rest. That is operating model work, not Salesforce work, and it is portable across HubSpot and Dynamics 365 too. The platforms are converging on agent-readiness quickly. The enterprises that benefit will be the ones that have done the unglamorous job of writing themselves down. If you are weighing how to make Headless 360 useful in your environment, we would be glad to help you map the capability inventory and build the governance scaffold that turns the platform’s promise into something your operating model can actually carry.
Get in Touch
If you are weighing how Headless 360 lands in your Salesforce estate, or whether your capability catalogue is defined cleanly enough for agents to call, send a note and we will help you sort the question.
