SAP and Salesforce: AI Integration Clash

Two Platforms, Two Strategies - and Your Integration Project Is Caught in the Middle

A Question That Most Organizations Are Not Yet Asking

Imagine you have successfully deployed Agentforce. Your service agent handles customer inquiries. Your sales agent qualifies leads. Everything runs. Then the agent needs to resolve a delivery delay. For that, it needs production order data from S/4HANA. And this is exactly where a discussion begins that most organizations have not put on their radar yet.

Both Salesforce and SAP speak loudly about the “Agentic Enterprise.” In April and May 2026, both made concrete platform decisions that shape what that concept actually means in practice. Those decisions point in opposite directions — with direct consequences for every organization running both systems.

What Salesforce Announced: The Platform Becomes Infrastructure

On April 15, 2026, Salesforce introduced Headless 360 at its annual TDX developer conference — one of the most significant platform shifts in the company’s 27-year history. The concept is radically simple: everything on the Salesforce platform — data, workflows, business logic — is now accessible via an API, an MCP tool, or a CLI command. No browser. No UI. No human navigation required for an agent to act.

The structural break is significant. For 25 years, Salesforce was a system that humans operated. Headless 360 makes it a system that agents can operate. More than 60 new MCP tools and over 30 preconfigured coding skills are immediately available, usable from Claude Code, Cursor, Windsurf, or any MCP-compatible agent framework.

For process design, the practical implication is this: an external agent can now directly trigger a Salesforce Flow, create a record, or run a report — without a proprietary middleware layer, without additional inference. A single call, deterministic, auditable. Analysts describe the move as Salesforce repositioning itself from a system of record to a system of execution.

What SAP Decided: The Boundary Stays Closed

A few days later, at the end of April 2026, an updated API policy came into effect at SAP. Section 2.2.2 of API Policy v4/2026 states a clear prohibition: SAP APIs may not be used for “interaction or integration with (semi-)autonomous or generative AI systems that plan, select, or execute sequences of API calls.”

In plain terms: anyone running an Agentforce agent — or any other third-party agent — directly against SAP APIs is formally in breach of the terms of use. The only permitted path for agentic use cases is the Agent-to-Agent (A2A) interface through Joule, SAP’s own AI system.

SAP CEO Christian Klein qualified the policy on the Q1 investor call, stating that the intent is not to cut customers off from their own data, but to protect SAP’s domain know-how and prevent performance degradation from uncontrolled agent traffic. The policy text itself, however, remains unchanged. The DSAG — the largest SAP user association in the German-speaking world — has formally criticized the policy and demanded significant clarification, particularly in light of the EU Data Act, which has been in force since September 2025 and anchors customer rights to the data they generate in connected systems.

SAP’s own position at Sapphire 2026 is that Joule is not a wall but an interface. The company presented the Autonomous Enterprise as its strategic vision: more than 50 Joule assistants orchestrating over 200 specialized agents across finance, supply chain, HR, procurement, and customer experience. Joule Work, the new user experience layer, is designed to operate across heterogeneous landscapes — including non-SAP systems — with general availability planned for Q4 2026. The message from Orlando: SAP wants to be the orchestration center, not just the data backend.

The Legitimate Argument — and the Commercial Calculus

SAP’s position is not without substance. S/4HANA carries financial closes, supply chains, payroll. Processes where ninety percent accuracy is not good enough. An uncontrolled agent executing hundreds of API calls in a loop can degrade the performance of a multi-tenant platform. That is a real operational risk, and SAP’s infrastructure argument is legitimate.

But the policy creates an asymmetry that should be named clearly. SAP’s own products — Joule, Business Data Cloud, Agent Gateway — are not subject to the same restrictions. Microsoft Copilot, Salesforce Einstein, and the full range of third-party agentic vendors that have built SAP connectors now face formal constraints. SAP’s own AI products do not. Independent analysts and the consulting community have noted that this bundles competitive positioning inside a governance wrapper. Whether that assessment is fair is a separate discussion. For organizations building their AI architecture today, the asymmetry is the relevant fact.

What This Means for Projects — A Practitioner’s View

From a project perspective, this is not an abstract architectural debate. In manufacturing, the most relevant data typically lives in SAP: inventory levels, production orders, supplier terms, quality records. When an Agentforce agent in a service or sales process needs exactly this data to act meaningfully, it encounters an architectural decision that has already been made in the background.

Three concrete consequences for current and planned projects:

• Any AI architecture that assumes direct API calls from Agentforce into SAP must be reviewed — legally and from a licensing perspective — regardless of whether it functions technically.

• The detour through Joule increases complexity and potentially latency. Organizations that choose A2A via Joule must plan for an additional layer with its own governance requirements, operational overhead, and cost implications.

• The cleanest solution — independent of the policy debate — is a robust integration layer that extracts data from SAP into a governed, agent-readable downstream source. This is not a workaround for the restriction. It is the architecture that should exist in heterogeneous system landscapes regardless.

The broader pattern is worth noting. As enterprise platforms develop their own AI layers, the question of which agents are permitted to access which data — and under what conditions — will become a standard design constraint in implementation projects. It sits at the intersection of licensing, architecture, and process design. That is not a technical problem. It is a consulting problem.

What Decision-Makers Should Do Now

SAP’s API Policy v4/2026 is not a footnote for IT architects. It is a strategic inflection point that affects every AI roadmap decision where SAP is part of the landscape.

Three steps I recommend:

• Audit your current and planned AI integrations. Identify which patterns access SAP APIs directly — today or on the roadmap — and assess them against the new policy.

• Clarify the licensing position with SAP and your licensing advisor before building architectural dependencies on patterns that may not be permitted.

• Design your integration architecture so that agents consume from a stable, governed downstream source rather than directly from the ERP system. This reduces dependency on any single vendor’s access policy and makes the architecture more resilient over time.

Salesforce is opening the platform. SAP is securing the boundary. Both are deliberate strategic decisions. The question is whether your AI architecture knows about them — before the first production agent runs into this wall.