Headless 360 and MCP: Claudeforce for Architects

Claudeforce makes Salesforce callable by an AI client over MCP, and for architects that is the headline, not the sales skills. When capabilities are reachable without the interface, the questions you design around change: not which screens and flows, but which capabilities you expose, to which clients, and under which permissions. Governance stops being a setting you configure and becomes the surface of the product. And the familiar build-or-buy choice for agents gains a third lane, with Claude itself as the interface to Salesforce. This is a practitioner's read of what that shift implies. The Claudeforce specifics are attributed to Salesforce and Anthropic's announcement, which we cover in Claudeforce explained; the architecture implications are ours.

I architect Salesforce systems, so I read the Claudeforce announcement for the integration model underneath it, not the demo. The model is the interesting part.

What "callable over MCP, without the interface" actually implies

Per the announcement, Salesforce in Claude is built on Headless 360, Salesforce's release of APIs, MCP servers, and command-line tools that expose Salesforce capabilities without the Salesforce UI, and Claude is the client calling them. Strip that to its architectural core and it says something simple: the interface is no longer the only way in, and increasingly not the primary one. For years the mental model of a Salesforce integration has been "the app, plus APIs for systems to talk to it." Headless 360 adds a third way in that is neither a screen nor a classic system-to-system API. It is a set of capabilities designed to be reasoned about and invoked by an AI client, under the user's permissions.

That distinction is easy to skate past and worth slowing down on. An API is something you integrate against with code you write. An MCP surface is something an AI client discovers and calls, on behalf of a user, at runtime. The design questions are different, and if you architect Salesforce, they are about to land on your desk.

The rows are not competitors so much as three doors into the same building. What Claudeforce does is make the third door a front door.

Permissions become the product

Here is the implication I would put in front of every architect first: when capabilities are callable by an AI client, your permission model stops being a background setting and becomes the thing that defines what the product can do. In the announcement, Salesforce's Patrick Stokes framed it plainly, that if a user cannot see a record, the MCP server cannot either. Read as architecture, that means the AI's power is exactly your permission design, no more and no less. A sloppy sharing model does not just risk a human seeing the wrong record; it defines the blast radius of an assistant acting across your org.

So the governance work moves from the edges to the center. Field-level security, sharing rules, and the principle of least privilege were always good practice; with an AI client operating the CRM, they become the specification for behavior. The teams who will deploy this well are the ones whose permission model is already clean and legible, because that model is now, in effect, the API contract for what an assistant may do. If your org's sharing is a decade of accumulated exceptions, that is the project to fund before the beta, not after. A permission review is unglamorous work, but it is the cheapest insurance you can buy before an assistant starts acting across your org at scale, and it pays off whether or not you ever adopt Claudeforce.

The agent decision gains a third lane

Until now, a team wanting agents over Salesforce chose roughly between two lanes: build on Agentforce, Salesforce's own agent platform, or build a custom agent that integrates with Salesforce. Claudeforce adds a third: use Claude itself as the interface to Salesforce, with the CRM reached over MCP. That does not retire the first two. It sits alongside them, and the right choice now depends on where you want the agent to live and who operates it.

The rough shape, as our analysis rather than anyone's announcement: Agentforce fits when the agent should live inside the Salesforce experience and be governed by it. A custom agent fits when the workflow spans systems Salesforce does not own, or you need model and evaluation control the platform does not give you. The new lane fits when your people already work in Claude and you want them to reach Salesforce from there without a screen. Many real architectures will mix them, and the deciding factors are the same unglamorous ones as always: where the data lives, who operates the thing, and which permission model governs it. If you are weighing these, our Agentforce work covers the platform lane, and evaluating any of them still depends on being able to judge the output, which our guide to evaluating LLM outputs covers.

What this does not change

It is worth saying what stays the same, because launch coverage tends to imply everything is new. The system of record is still Salesforce, and the value Stokes pointed to, the data, the metadata, and years of encoded workflow, is still what makes any of this useful; an assistant calling into an empty or messy org produces confident nonsense. The data-quality and modeling discipline that made Salesforce work does not go away because the interface changed. If anything, it matters more, because an AI client will expose a weak data model faster than a patient human ever did. If MCP itself is new to your team, our explainer on what an MCP server is is the place to start.

What we cannot know until the beta ships

I will end where an honest read has to, on the open questions, because the announcement is a launch post and a launch post is not a spec. We do not yet know the pricing or licensing model. We do not know how far beyond sales the callable surface reaches, or when, since skills for other functions are described only as beginning later in 2026. We do not know the precise boundaries of the governance and data-handling guarantees, which should be verified against your own security review rather than taken from a blog. And we do not know how cleanly this composes with Agentforce in a real, mixed deployment, which is the question I most want to test hands-on.

Those are not reasons to ignore Claudeforce; they are the reasons to engage with it as an architect rather than a spectator. Understand the surface now, get into the beta when it opens, and design your permission model as if it were the product, because with this shift it is. If you want that pressure-tested against your actual org, our AI agents team builds these integrations, and you can talk to us for a builder's read rather than a launch-day one.