Salesforce Headless 360: What Agent-First CRM Means for Buyers

Salesforce just shipped Headless 360, a rebuild of its platform that exposes the entire stack (Salesforce CRM, Data 360, Customer 360, Agentforce, Slack) as REST APIs, MCP tools, and CLI endpoints designed for AI agents to call directly. Marc Benioff's line is "no browser required, our API is the UI." That sentence is the whole product. The CRM you used to log into is now a programmable substrate that agents read, write, and orchestrate against, with Salesforce holding the data model and audit trail underneath.

What Salesforce Actually Shipped

Five pieces matter, and they ship together as the Headless 360 release.

Full platform exposure. Every core object (Accounts, Contacts, Opportunities, Cases, Custom Objects), every workflow, and every governance control is reachable through APIs, MCP tools, or CLI. Reads, writes, approvals, and triggers are all callable without going through Lightning UI. Existing REST and SOAP APIs are still there, but the new MCP layer is what makes the platform first-class to agent runtimes that already speak MCP.

Agentforce Vibes 2.0. The native agent dev environment now ships with an open agent harness, meaning you can build inside Salesforce using Anthropic's agent SDK or OpenAI's Agents SDK with multi-model support (Claude, GPT-5, Gemini). The harness gives the agent org-aware context (your data model, your permissions, your workflow definitions) without you having to plumb it in. This is a meaningful upgrade over earlier Agentforce, which was effectively single-model and walled off from external SDKs.

Agentforce Experience Layer. You define an agent experience once and render it on Slack, Microsoft Teams, mobile, ChatGPT, Claude, Gemini, or any MCP-capable client, without rebuilding a frontend per surface. This is the design pattern that matters most for distribution: the agent goes to where users already are, instead of forcing users into a new console.

Lifecycle tooling. Testing Center, Custom Scoring Evals, A/B Testing API, Session Tracing, and a Salesforce Catalog let you evaluate agents, find policy gaps, run experiments, and trace what an agent did and why. Most internal agent projects we see fail not at the model layer but at the "how do we know this is safe to ship" layer, so this is the part of the release that production teams will care about most.

AgentExchange. The new marketplace unifies roughly 10,000 Salesforce apps, 2,600+ Slack apps, and 1,000+ Agentforce agents, tools, and MCP servers from partners like Google, DocuSign, and Notion. A $50M builders fund sits behind it. This is the distribution channel that turns Headless 360 from a platform release into an ecosystem play.

From System of Record to System of Execution

For twenty-five years the operating assumption around CRM was that humans entered data and looked it up. Salesforce's product surface (Lightning, dashboards, list views) was optimised for that. The bottleneck was always the human at the keyboard. Headless 360 is a bet that the bottleneck is moving. Agents read structured data faster, write it faster, and chain workflow steps faster than any human user, and Salesforce wants to capture that motion inside its own data model rather than watch it happen in a separate orchestration layer.

The shift from "system of record" to "system of execution" is also a competitive defence. If agents can call any CRM through a thin MCP server, the value of any specific CRM compresses unless that CRM bundles the orchestration, evals, and distribution surfaces. By shipping Vibes, the Experience Layer, and AgentExchange together, Salesforce is trying to be the place where agentic workflows run end-to-end, not just the database those workflows happen to read from. That is a reasonable strategy, and similar to the broader pattern we wrote about in AI autopilots vs copilots: vendors that sell finished work outcomes capture more spend than vendors that sell tools.

Build Inside Agentforce, or Drive From Outside?

The question every team will face within a quarter of seriously evaluating Headless 360 is whether to build the agent inside Agentforce or to keep an external orchestrator (Claude Agents SDK, OpenAI Agents SDK, or a custom runtime) and call Salesforce as one of many MCP tools. There is no single right answer, but the heuristic is data gravity and orchestration scope.

Build inside Agentforce when the agent's work is mostly inside Salesforce: lead enrichment, opportunity hygiene, case routing, quote generation, contract drafting against Salesforce CPQ. The native harness, evals, and Session Tracing give you the shortest path to a production-grade agent with one governance plane and one identity model. You also get the Experience Layer for free, so the same agent can answer a sales rep on Slack and a customer on the web without rework.

Drive from outside when the workflow spans Salesforce plus systems Salesforce does not own: a separate data warehouse, an ERP, internal tools, billing, observability stacks. In that pattern Salesforce becomes one MCP server in a portfolio of tools, and the orchestration logic sits in your own Claude or GPT-5 agent. Your audit trail then has to span both runtimes, which is more work, but you keep the agent portable.

Most enterprises will end up running both patterns in different parts of the business. The thing to avoid is letting the "easy" native path quietly become the only path, because that is how vendor lock-in compounds. We covered the broader containment patterns in running AI agents as host processes is a production mistake, which applies whether the agent runs in Agentforce or somewhere else.

What Changes for Buyers

Five practical changes are worth flagging now, before pilots turn into commitments.

1. Licensing economics. Salesforce licensing has been priced around human seats. Headless 360 enables a lot of work to happen with no human ever logging in. If your seat count is inflated relative to active human usage (a common state in mid-market and enterprise orgs), the rollout is a chance to renegotiate based on agent-driven usage rather than nominal seats. Salesforce will of course want to add agent-usage pricing on top, so the savings argument is not automatic. Run the math both ways.

2. Identity for non-human callers. Most Salesforce orgs were not designed with autonomous callers in mind. Default profiles and permission sets often grant broader scopes than agents need, and audit logs were built for human accountability, not agent reasoning. Before any agent gets write access to production, redesign your service identities with least-privilege scopes, separate identities per agent capability, and an approval flow for high-risk actions (mass updates, deletions, owner reassignments). This is unglamorous work that pays off the first time something goes sideways.

3. Data exposure at the MCP boundary. An agent reading the full Account or Contact object can leak more than a human would, simply because it is faster and tireless. Treat the MCP server as a redaction boundary. Decide which fields agents can read in the clear (most), which fields are masked or tokenised (financial, PII, private notes), and which are entirely hidden. Salesforce's Data 360 layer can support this, but only if you configure it deliberately.

4. Audit and reproducibility. Session Tracing exists because regulators and internal risk teams will ask "why did the agent do that?" and you need a defensible answer. Make sure tracing is on by default for any agent that touches regulated workflows (insurance underwriting, healthcare claims, financial reporting), and that the trace retention matches your record retention policy.

5. Vendor portability. The Experience Layer is genuinely useful, but it makes Salesforce the orchestration plane for agent UX. If you ever need to migrate, recreating that across multiple surfaces is a real cost. Negotiate data portability and export rights into the contract now, while you have leverage. Specifically: agent definitions, eval suites, training data, and Session Tracing logs should all be exportable in open formats.

Where Headless 360 Will Land First

Three patterns tend to ship first in any agent platform release, and Headless 360 fits all three.

Sales operations. Lead enrichment, opportunity hygiene, follow-up drafting, pipeline reviews. The work is intelligence-heavy, the data lives mostly inside Salesforce, and reps will accept agent-drafted outputs as long as they can review before sending. Agentforce Vibes 2.0 is a reasonable shortcut here.

Customer service triage. Case classification, routing, suggested responses, knowledge base lookup. The Experience Layer matters a lot in this category because the same agent can serve a tier-one rep in the Service Console and a customer on a website chat without separate builds. We covered the broader pattern in our AI customer support case study.

Cross-system workflows. Salesforce plus ERP, Salesforce plus billing, Salesforce plus document generation. This is the "drive from outside" pattern, where Salesforce is one MCP server among several. The pieces that make this work (open agent harness, MCP tool exposure, AgentExchange tools from Notion, DocuSign, Google) are all in the release.

The pattern that will land later, despite vendor framing, is anything that requires deep judgement: account strategy, win/loss analysis, complex deal structuring, executive briefings. Agents will draft inputs into those decisions, but the decisions themselves stay human for the same reasons we covered in copilots vs autopilots. Buy the marketing accordingly.

A Pragmatic First-Quarter Plan

For a company already on Salesforce, a sensible 90-day plan looks like this.

1. Inventory. List the top 20 workflows in Salesforce by frequency and human time spent. For each, mark whether the work is intelligence-heavy, who owns it, and whether the outcome is verifiable. This is the same shape as the framework in our autopilot guide, applied inside one platform.
2. Pick one read-only pilot. Start with a workflow where the agent can only read and summarise (pipeline review, account briefing, case triage with human send). Read-only agents are easier to ship and almost as useful, and they let your team build the eval and tracing muscle without production write risk.
3. Design service identities. Before turning on write access, design least-privilege profiles for the specific agent capabilities you intend to ship. One identity per capability, scoped to the minimum object set.
4. Turn on Session Tracing. Configure retention, decide which fields are redacted at the boundary, and confirm the audit log integrates with your existing risk tooling.
5. Run an A/B test against the human baseline. Use the new A/B Testing API to compare agent-handled cases against human-handled cases on quality, time, and customer feedback. The economic case lives or dies on this measurement.
6. Decide build-inside vs drive-from-outside. By the end of the quarter you will have one workflow shipped and a clear sense of whether your next ten workflows want to live inside Agentforce or in an external orchestrator. Make the call deliberately.

This sequence avoids two common failure modes: shipping a write-capable agent before the identity model is ready (operational risk) and signing a multi-year Agentforce expansion before you know whether your workflows actually want to live inside Salesforce's orchestration plane (commercial risk).

The Short Version

Headless 360 is a real shift, not a marketing repackaging. The platform is now genuinely agent-first, with a credible answer for development (Vibes 2.0), distribution (Experience Layer), governance (Session Tracing and Evals), and ecosystem (AgentExchange). The smart buyer move is to treat it as both an opportunity (faster automation, cleaner integration patterns, potentially lower licensing if seat counts are inflated) and a governance problem (identity for non-human callers, redaction at the MCP boundary, vendor portability). Pilot one read-only workflow this quarter, design the identity model before any write access, and decide build-inside-versus-drive-from-outside on data gravity rather than vendor preference. The companies that get this right will be running their CRM as infrastructure within a year. The ones that do not will end up with a fast, audited, well-governed Lightning experience and a competitor whose agents do the work in the background.

Frequently Asked Questions