What Headless 360 Is
TDX 2026 announced Headless 360 — a reframing of Salesforce as a capability layer rather than a destination. MCP tools expose platform actions. A new experience layer renders native interactions across Slack, voice, WhatsApp, custom apps. The architecture flips the historical model: instead of building Salesforce experiences inside Lightning and bridging out to other channels, you build capabilities once on the platform and let multiple channel adapters render them. A “create case” capability defined in Salesforce becomes a Slack slash command, a voice IVR menu option, a WhatsApp button, and a custom mobile app screen — all driven by the same server-side definition with channel-specific rendering.
The Three Pillars
MCP tools (agents call Salesforce platform capabilities). Coding skills (agents write and deploy code with full platform access). Experience layer (one logic, many surfaces — chat, voice, notification, custom UI). Each pillar has concrete primitives:
MCP Tools — defined as Apex classes annotated with @HttpMcpTool:
@HttpMcpTool(name='create-support-case')
global class CreateSupportCaseTool {
@InvocableMethod
global static List<Case> execute(List<CaseInput> inputs) {
List<Case> cases = new List<Case>();
for (CaseInput i : inputs) {
cases.add(new Case(Subject=i.subject, Priority=i.priority, ContactId=i.contactId));
}
insert cases;
return cases;
}
}Coding Skills — agents that write and deploy Apex/LWC through the DX MCP Server, scoped to a permission set.
Experience Layer — channel adapters that subscribe to capabilities. Slack renders as slash commands; voice (via Service Cloud Voice) renders as IVR options; WhatsApp renders as button menus.
Builder Shift
Traditional Salesforce builders designed for LWC pages. Headless 360 builders design for agents and channels. Different mental model — less ‘where does the button go’ and more ‘what’s the capability, and what surfaces consume it’. The skill profile includes API contract design (OpenAPI to MCP tool definitions), conversational UX patterns (voice presents differently from chat), multi-surface testing, and governance configuration (per-capability rate limits, masking, audit policies).
Lightning skills don’t go away — record pages, AppExchange components, and admin-facing surfaces still want LWC. But the center of gravity for new development shifts to capability-first design.
Production Readiness
Headless 360 is early. MCP tools are mostly in Pilot/Preview. Don’t rebuild production on it yet. Do start familiarizing your team; the architecture direction is clear and accelerating. The current GA/Pilot status as of April 2026:
| Component | Status |
|---|---|
| MCP tool definitions | Developer Preview |
| MCP server hosting | Pilot |
| Slack experience adapter | GA (limited) |
| Voice / WhatsApp adapters | Pilot |
| Custom SDK / coding skills | Developer Preview |
Production migrations should target Winter ‘26 GA at the earliest. Greenfield work in scratch orgs is appropriate now.
What Changed in 2026
Pre-Headless 360, exposing Salesforce capabilities to non-Lightning channels meant custom REST integrations, point-to-point connectors, or middleware. Each channel was a separate engineering project. Headless 360 collapses that fan-out — one capability definition serves N channels. The architectural payoff compounds: each new channel costs the experience layer adapter (one-time work) plus the per-capability rendering rules (small per-capability work) instead of full re-implementation per channel.
Common Failure Modes
Designing capabilities for one channel and assuming they’ll work in all. A capability that requires 8 input fields renders fine in Lightning, painfully in Slack, and unworkably in voice. Design for the most-constrained channel first. Second: skipping authentication design. MCP tools called from external agents need clear identity propagation — who is the agent acting on behalf of, and how does that map to a Salesforce User context for FLS and sharing? Build identity-on-behalf-of into capability design from day one. Third: under-investing in error handling. Channel adapters surface errors differently — Slack shows them inline, voice has to verbalize them, WhatsApp truncates them. Design error responses that degrade gracefully across surfaces.
What to do this week
Identify one capability your team currently exposes via Lightning that could plausibly render across multiple channels — case creation, opportunity update, knowledge search are common starting points. Sketch the capability definition (inputs, outputs, side effects). The exercise surfaces design assumptions you’d otherwise carry into production.
