Substrate vs. Broker: Two Emerging Strategies for Enterprise AI

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 Corte

[truncated for AI cost control]