Every manufacturer building an Agentforce channel for dealers eventually hits the same wall: the second channel.
The first agent say, on a DMS portal works fine, because it’s the only thing calling your order logic. The real architectural test comes when a second surface, like WhatsApp, needs to place and cancel the same dealer orders. Do you extend the existing logic, or quietly build a second copy of it for the new channel? Most teams don’t realize they’re at this fork until they’re already past it.
Headless 360 is Salesforce’s move to decouple business logic from any single front end. Historically, Salesforce’s data and process layer (Sales Agreements, Orders, validation rules, Flow) was reachable primarily through Lightning UI. Headless 360 exposes that same layer governed by the same permissions and validation rules through APIs and agent-callable tools, so a UI becomes one access channel among several, not the only one.
For a manufacturer, the shift is this: an Agentforce agent on WhatsApp and a Lightning-based DMS portal aren’t two systems they’re two doors into one kitchen. Order validation, inventory checks, and dealer credit limits get defined once and enforced identically regardless of channel.
Model Context Protocol (MCP) is what makes “one kitchen, many doors” technically real. An MCP server is functionally a facade/adapter layer architecturally similar to a wrapper class sitting in front of existing Apex methods, Flows, or APIs. It doesn’t replace that logic; it exposes it as a standardized, network-callable, self-describing tool any compliant agent can discover and invoke.
The key difference from a typical wrapper class: an MCP tool declares its input/output schema explicitly as structured metadata, and advertises its full capability list to any connecting client. An agent doesn’t need custom integration code to know place_dealer_order(dealer_id, product_id, quantity) exists and what it returns — it discovers this at connection time.
Both the WhatsApp agent and the portal agent call the same tool. Neither owns a private copy of “how to place an order.”
This isn’t a nice-to-have abstraction it’s a hedge against the same fragmentation problem plaguing forecasting data, just one layer up, at the action layer instead of the data layer. McKinsey’s January 2026 research on enterprise AI found companies are creating a “great divide” investing heavily in AI agents while treating the underlying ERP and process layer as an afterthought, producing AI use cases unsupported by the end-to-end processes and technologies needed to scale them, commonly termed “pilot purgatory.” The same research found only about 40 percent of companies report any enterprise-level EBIT impact from their AI initiatives.
That’s the real risk of skipping proper MCP-wrapping: every new channel becomes its own unsupported pilot, not an extension of a governed core. Gartner’s 2026 data and analytics predictions reinforce this from the governance side, noting that as AI systems collaborate more directly with enterprise data, the boundary between human, machine, and organizational intelligence blurs and ungoverned tool sprawl is where that blur turns into risk.
Done right, adding a third channel voice, email, a partner’s own agent means connecting to an existing, tested tool, not rebuilding order logic again. Done wrong, you accumulate exactly the fragmented, ungoverned AI sprawl McKinsey’s research flags as the reason most enterprise AI investment isn’t yet showing up in EBIT.