Memo: Salesforce and SAP Are Making Opposite Bets About How Agents Will Use Enterprise Software. The Rest of the Stack Is About to Have to Pick a Side.
In April 2026, Salesforce launched Headless 360 with sixty-plus MCP tools that let any external agent operate the entire CRM directly. Six months earlier, SAP shipped its MCP Gateway with an explicit architectural decision in the opposite direction: external agents should talk to SAP's agents, not to SAP's APIs. Both companies are using the same protocol. They are making opposite bets about what the protocol is for. Most readers of either announcement are missing this. The split is the most consequential strategic divergence in enterprise software in 2026, and every other platform – Microsoft, ServiceNow, Workday, Oracle, Atlassian, Snowflake, Databricks – is currently inside the planning meeting where they have to pick a side.
On April 15, 2026, at TrailblazerDX in San Francisco, Salesforce announced what its co-founder Parker Harris framed in a single rhetorical question: Why should you ever log into Salesforce again? The accompanying product, Headless 360, is the most significant architectural shift in the company's twenty-seven-year history. Every capability in the Salesforce platform – data, workflows, business logic, compliance controls – is now exposed as a REST API, an MCP tool, or a CLI command. More than sixty new MCP tools shipped at launch, with over thirty preconfigured coding skills, and explicit support for external coding agents including Claude Code, Cursor, Codex, and Windsurf to operate the platform without a browser. Pricing is shifting from per-seat to consumption-based, an acknowledgment that when the agent is the user, the seat model is dead.
Six months earlier, in November 2025 at SAP TechEd, SAP made what looked at the time like a parallel announcement. The MCP Gateway, built on SAP's Integration Suite, would convert APIs and Flows into MCP tools usable by Joule, SAP's first-party agent. SAP announced an ABAP MCP server for the first half of 2026, a Storefront MCP server for SAP Commerce Cloud in Q2 2026, and a steady drumbeat of MCP-related shipping through TechEd and into early 2026. Press coverage treated it as MCP plumbing for ERP – the same story Salesforce would later tell, just on a six-month delay.
That reading is wrong. The two companies are using the same protocol to execute opposite strategies, and the strategies imply different futures for the entire enterprise stack.
The decisive document is buried in SAP's own architecture guidance, published quietly to the SAP Architecture Center in early 2026: "For external interoperability between vendors and third-party agents, SAP prioritizes A2A over direct MCP server exposure." That single sentence is the divergence. Salesforce wants its platform's MCP tools to be called directly by any agent in the market. SAP wants external agents to talk to Joule – its first-party agent – which will then decide whether and how to invoke the platform's MCP tools on the caller's behalf.
Same protocol. Opposite philosophy. The press has, almost without exception, missed the consequence.
The substrate bet and the broker bet
The two strategies need names, because right now the analyst coverage is using the same word ("MCP-enabled") to describe two architectures that have radically different implications for security, pricing, vendor power, and which third parties get to participate.
Call them the substrate bet and the broker bet.
The substrate bet, which Salesforce is running, says: the durable layer in agentic enterprise software is the platform that every agent calls into. Make the platform itself agent-callable from any surface, by any agent, with the platform's data and workflows and trust controls intact. The strategic prize is being underneath every workflow that an agent runs, whether the agent is built by Salesforce, by a customer, by Cursor, by Anthropic, by a startup nobody has heard of yet, or by a competitor. The platform wins by being the thing that gets called. Per-seat pricing dies because the seat dies; consumption pricing takes its place because the unit of value shifts to invocations.
The broker bet, which SAP is running, says: the durable layer is the first-party agent that holds the platform's privileges. External agents should not get direct platform access; they should request work from the platform's own agent, who decides – under the platform's governance model – whether and how to fulfill the request. The strategic prize is being the agent that other agents have to talk through. MCP exists internally so that Joule can do its work efficiently. Externally, SAP prefers A2A – the agent-to-agent protocol – which is structurally a delegation interface rather than a tool interface. The platform wins by being the thing that gets asked. Pricing remains anchored to the agent's seat or runtime, because Joule remains the addressable unit of value.
These are not implementation differences. They are different theories of where the trust boundary should sit in agentic enterprise software, who carries liability when an agent does something wrong, and which third parties get to participate in the economy that forms on top.
The substrate bet maximizes ecosystem participation and ecosystem dependence on the platform. The broker bet maximizes platform control over what agents can actually do.
Both bets are defensible. They cannot both be right.
What each company is implicitly claiming about the next five years
The two bets encode three sharply different claims about how the agentic enterprise will evolve.
Claim one: where does the customer's trust live?
Salesforce is betting that the customer's trust lives in the platform's data, workflow, and governance layer – not in any particular agent. The Einstein Trust Layer applies to every Agentforce session regardless of which agent invokes it. Data masking, field-level security, zero-data-retention agreements with LLM providers – these are platform-level enforcements that travel with the data regardless of who is calling. The customer trusts Salesforce because Salesforce sits at the gate of every invocation. The identity of the calling agent is, structurally, secondary.
SAP is betting that the customer's trust lives in the first-party agent that has been credentialed against the platform. Joule is the entity the customer has approved, scoped, and given permissions to. An external agent that wants to act in SAP needs to convince Joule, through A2A, to act on its behalf. The trust boundary is the boundary of Joule, not the boundary of the platform. Customers trust SAP because Joule is the only thing inside SAP's perimeter that talks to outside agents at all.
If you believe enterprise customers, in 2027 and beyond, will be more comfortable approving platforms than approving agents, Salesforce is right. If you believe customers will demand a single, named, accountable agent at the boundary of every platform – with everything else on the outside subject to that agent's judgment – SAP is right.
Claim two: where does liability sit when an agent does something wrong?
The Air Canada precedent already established that companies cannot disclaim responsibility for the chatbots on their websites. The next wave of cases – which will arrive within eighteen months, given the deployment rate – will ask a sharper question: when an external agent invokes an enterprise platform via MCP and produces a harmful outcome, who is liable? The agent's builder? The user who deployed the agent? The platform that exposed the tool?
The substrate bet implicitly accepts that the platform shares liability for every invocation. If Salesforce is the substrate every agent calls into, Salesforce's trust layer is the last enforcement point before action is taken. That is both a feature – Salesforce can market the trust layer as the reason a customer should consolidate onto Headless 360 – and a risk. Every poorly-built external agent that does something bad through a Salesforce MCP tool becomes a Salesforce problem.
The broker bet implicitly tries to push liability outward. Because external agents must go through Joule, SAP's first-party agent becomes the accountable actor, and the external agent becomes a requester rather than an operator. This is a defensible legal posture that the substrate model gives up by design. If you believe the next eighteen months will produce a wave of enforcement actions that punish platforms for the actions of third-party agents calling their tools, SAP's position is much more comfortable to be in.
Claim three: where does pricing power eventually accrue?
Salesforce has already moved to consumption pricing for Agentforce, and the broader signal is that per-seat pricing is over. The substrate bet ends in a model where Salesforce extracts value per invocation – regardless of which agent is doing the invoking. The agent ecosystem on top is encouraged to grow, because every agent in the ecosystem is a meter that runs Salesforce's billing system.
SAP has not made the equivalent pricing move publicly. The broker bet is consistent with continuing to price the agent itself, because the agent is the named entity holding the customer relationship. Joule's seats, Joule's runtime, Joule's per-workflow charges remain the addressable unit. If external agents want to participate, they participate as suppliers to Joule rather than as customers of SAP's APIs. SAP captures less of the per-invocation flow but maintains a clearer line of sight to what each customer's agent stack is doing.
If you believe agentic enterprise software ends in a world dominated by a small number of horizontal platforms with everything called via API, the substrate bet wins the pricing war. If you believe it ends in a world where each major enterprise vendor runs its own first-party agent and external agents are required to negotiate with those agents to get anything done, the broker bet wins.
Why the rest of the stack now has to pick
Salesforce and SAP did not converge on opposite doctrines by accident. Both companies have spent two-plus years internally arguing about which architecture to ship. Salesforce went substrate publicly two and a half years before the Headless 360 announcement, according to its own framing. SAP has been operationally committed to the broker model since at least mid-2025. Each company picked the doctrine that played to its existing strengths – Salesforce's ecosystem-friendly platform DNA versus SAP's deep integration into governed, regulated, complex enterprise workflows where Joule's role as accountable orchestrator is a feature, not a constraint.
The other major enterprise platforms have not yet had to commit publicly, but they will, in 2026 and into 2027. Each of them is, right now, inside the planning meeting where the substrate-versus-broker decision gets made. The signals so far:
Microsoft is hedging. Microsoft 365 Copilot looks substrate-shaped – exposed through endpoints, callable by external agents – but Microsoft's Agent 365 framing positions Microsoft's own agents as the privileged operators inside the enterprise. Watch the next eighteen months of Microsoft's Agent Builder and the maturity of its A2A versus MCP investments; Microsoft will have to land more clearly on one side.
ServiceNow is structurally pulled toward the broker model. Its core asset is the workflow graph, and exposing that graph to arbitrary external agents undermines the consulting-implementation economy that surrounds it. Expect ServiceNow's Now Assist to harden into a Joule-style first-party agent that brokers everything.
Workday has the same structural pull as ServiceNow but a weaker position to enforce it. HR and finance workflows are too cross-platform for a pure broker model to hold; Workday will probably end up in a hybrid, but the hybrid will lean broker.
Snowflake and Databricks are structurally pulled toward the substrate model. The data lives in them; the value of being called increases as more agents call. Snowflake's MCP and Cortex Agents posture and Databricks' equivalent moves through 2026 should both look substrate-shaped.
Atlassian is the most interesting wildcard. The developer-tools company has always been ecosystem-friendly, which suggests substrate, but its recent investments in Rovo are first-party-agent-shaped, which suggests broker. The choice Atlassian makes will tell you something about whether broker is becoming the default for any platform where the first-party agent can be made strong enough to defend.
The point is not that any of these companies will exactly replicate Salesforce or SAP. The point is that the architectural design space is now bracketed by the two doctrines, and every platform is going to land somewhere on the line between them. Customers, partners, and developers buying onto these platforms are implicitly buying into a doctrine, often without realizing they are doing so.
What this means for the people buying enterprise software in 2026
If you are an enterprise architect or a platform-strategy leader making decisions in the next twelve months, the substrate-versus-broker frame is the single most useful lens for evaluating any platform's "agent-ready" claims. The right question is no longer does this platform support MCP? – the answer is now uniformly yes, and the answer no longer tells you anything. The right question is which doctrine does this platform's MCP support encode?
Three operational implications follow.
Audit how each platform exposes MCP, not whether it does. Read the docs. If the platform's MCP servers can be called by any agent the customer authorizes – Claude Code, Cursor, in-house, third-party – the platform is running the substrate bet. If the platform's MCP servers are primarily wrapped behind a first-party agent that mediates external requests, the platform is running the broker bet. The marketing language will not tell you which is which. The architecture documentation will.
Match the doctrine to the workflow, not the vendor logo. Different workflows want different doctrines. Anything that involves heavy multi-vendor orchestration, high-volume low-stakes transactional work, or developer-facing automation is a better fit for substrate platforms. Anything that involves regulated industries, ambiguous specification, high accountability, or strong governance requirements is a better fit for broker platforms. Trying to force a substrate platform to behave like a broker (by wrapping it in heavy middleware) or a broker platform to behave like a substrate (by exposing first-party-agent capabilities to external callers) is the most expensive form of architecture mistake an enterprise can make in the next two years.
Price the doctrine into the contract. Substrate platforms will move to consumption-based pricing on the agent invocation. Broker platforms will continue pricing the first-party agent as a seat or runtime. The total cost of ownership in three years looks very different under each model, and finance teams should be modeling both. The right time to negotiate consumption-rate caps and broker-tier transparency is before the platform commits the customer to a five-year contract on whichever doctrine it has chosen.
The bottom line
Salesforce and SAP have, in the same six-month window, committed to opposite theories of how agentic enterprise software works. Both companies are using MCP. Only one of them believes external agents should call MCP directly. The split is not a temporary divergence that will reconcile as the protocol matures. It is two different bets about where trust, liability, and pricing power sit in an agentic enterprise – bets that are downstream of each company's existing strengths, and that imply opposite futures for the ecosystem that forms on top.
The rest of the enterprise stack is now inside the meeting where this gets decided. Some will land substrate, some will land broker, and the hybrids will be unstable until they pick a center of gravity. The customers buying these platforms are also picking a doctrine, whether they know it or not. The architects who name the doctrine in their evaluation criteria will, in eighteen months, look like they had foresight. The ones who didn't will be explaining to their CIO why the platform they chose cannot do – or will not do, or will not be allowed to do – what they need the platform to do, because the doctrine the vendor encoded into the architecture has implications that the procurement deck never discussed.
There are two bets on the table. Both are real. Both are well-resourced. The protocol they share is incidental. What matters is the doctrine.
Sources: Salesforce's Headless 360 announcement at TDX 2026 (April 15, 2026) and accompanying press; SAP's MCP Gateway and Joule announcements from TechEd 2025 forward; SAP Architecture Center documentation on the prioritization of A2A over direct MCP server exposure for external interoperability; trade-press coverage from Salesforce Ben, Apex Hours, SaaStr, Techzine, AIMultiple, and Prolifics. All technical details about MCP tool counts, A2A versus MCP scoping, pricing model shifts, and Joule's role as orchestrator are drawn from public statements by Salesforce and SAP between November 2025 and May 2026. The substrate-bet and broker-bet framing is original to this memo