The one-sentence version
Salesforce Headless 360, announced on 15 April 2026, exposes the capabilities Salesforce has built over 25 years as APIs, Model Context Protocol (MCP) tools, and CLI commands — so an AI agent can use the platform without a human ever opening a browser tab.
That is a genuine architectural shift, not a marketing rename. For two decades the browser was the assumed entry point to Salesforce, and every integration worked around that assumption. Headless 360 inverts it: the UI becomes one client among several, and the platform itself becomes programmable from anywhere.
How it relates to Agentforce 360
These are two different layers, and confusing them is the most common mistake we see in planning conversations.
- Agentforce 360 is the reasoning layer — where agents are defined, how they plan, and how they are evaluated and observed.
- Headless 360 is the programmable access layer over the platform — how agents and code reach Salesforce data, workflows, and business logic without a UI.
Put simply: Agentforce 360 decides what to do. Headless 360 is how it reaches out and does it. You can use Headless 360 without building a single Agentforce agent, and plenty of teams will — it is a developer platform story as much as an agent story.
What is actually in the box
MCP tools and coding skills
Headless 360 ships with more than 60 new MCP tools and over 30 preconfigured coding skills. MCP is an open standard for giving AI models structured access to external systems, and Salesforce adopting it means coding agents get live, governed access to your org — your data, your workflows, your business logic — rather than a stale snapshot.
Salesforce cites support for the coding agents developers already use, including Claude Code, Cursor, Codex, and Windsurf. Crucially, this is live access to the real platform, so the same permission model that governs a human user governs the agent.
Data and DevOps access
- Data 360 — API access to unified business data
- DevOps Center MCP — CI/CD operations exposed to agents and scripts
The agent control plane
This is the part most teams underestimate, and it is the part that determines whether you can actually run agents in production:
- Agent Script — declarative behavior rules and guardrails
- Testing Center — surfaces logic gaps and policy violations before release
- Custom Scoring Evals — evaluates the quality of an agent's decisions, not just whether it responded
- Observability and Session Tracing — post-launch monitoring of what agents actually did
- A/B testing — compare agent versions against each other on live traffic
If that list reads like standard software delivery tooling, that is precisely the point. Agents are now being treated as software that ships, not configuration that gets toggled on.
The experience layer
Rich interactive components render natively across Slack, mobile, ChatGPT, Claude, Gemini, and Teams. The practical consequence: the surface where your users work no longer has to be a Salesforce page for them to be working in Salesforce.
What changes for your team
| Before | With Headless 360 |
|---|---|
| Integrations built per-endpoint against REST/SOAP APIs | Agents discover and call governed MCP tools directly |
| Agent quality assessed by spot-checking transcripts | Custom Scoring Evals and Testing Center run before release |
| Production issues diagnosed from logs after the fact | Session Tracing shows the agent's actual decision path |
| The browser is the platform's front door | API, CLI, and MCP are equal front doors |
The honest caveats
Three things are worth saying plainly, because the announcement coverage mostly did not.
Your permission model is now load-bearing in a new way. When agents reach the platform through MCP tools, sharing rules, field-level security, and profile design stop being a back-office concern and become the primary control on agent behavior. Orgs with permissive, historically accreted security models will feel that immediately.
Data quality gets exposed faster. A human reading a messy record applies judgment silently. An agent reading the same record through an API does not. Headless access removes the human buffer that has been quietly compensating for bad data for years.
Governance has to be designed, not inherited. The control-plane tooling exists, but nothing forces you to use it. Teams that skip Testing Center and evals because the agent "seems fine in the sandbox" are building the exact failure mode this tooling was designed to prevent.
Where to start
- Audit your permission model before you expose anything headlessly. Assume every MCP tool will be called by something that does not use judgment.
- Pick one internal, low-stakes workflow and build it headlessly end to end — the learning curve is in the governance, not the code.
- Stand up Testing Center and at least one custom evaluation before your first production agent, not after your first production incident.
- Decide deliberately which surfaces your users will work in. "Everywhere" is a strategy that produces support burden.
At Maple Wave AI, we treat the access layer and the reasoning layer as one design problem, because in production they fail together. If you are planning headless agent work and want a second opinion on your org's readiness, that is exactly what our assessment covers.