At Sapphire 2026, SAP presents the Autonomous Enterprise as the future of enterprise software. The ambition is grand. But behind the glossy keynote lies a fundamental strategic choice that directly contradicts the direction the rest of the market is taking: while others are opening up and opting for headless architectures, SAP is choosing an architecture that sidelines external AI agents and requires everything to go through Joule.
SAP’s central message at Sapphire 2026 is clear: the company wants its software to execute business processes autonomously rather than merely recording the results of human work. More than 50 Joule assistants manage over 200 specialized agents across finance, supply chain, HR, procurement, and customer experience. The new SAP Business AI Platform combines the SAP Business Technology Platform, SAP Business Data Cloud, and SAP Business AI into a single managed environment. At its core is the SAP Knowledge Graph.
That sounds impressive. The underlying data ambition is also truly strong; SAP has fifty years of business-critical process data in a single integrated system. No other vendor has finance, supply chain, procurement, HR, and production so deeply interconnected. But that’s where it ends.
SAP shuts the door
While Salesforce and ServiceNow have opted for complete openness in recent weeks, SAP is taking a different course. In April 2026, the company quietly published an updated API policy. Section 2.2.2 of API Policy v4/2026 explicitly prohibits the use of SAP APIs by AI systems that independently schedule or execute calls. In plain language: external AI agents are no longer allowed to use SAP APIs.
The API policy stands
CEO Christian Klein tried to calm the situation by stating that customers do not have to pay for access to their own data. But verbal assurances and contractual obligations are two different matters at SAP. Meanwhile, the policy remains the same: external AI agents are not allowed to use SAP APIs.
During Sapphire 2026, we discussed this with Thomas Saueressig, Chief Customer Officer. He defended the policy as necessary governance for the multi-tenant platform. Still, his conclusion was clear: for agentic use cases, A2A via Joule is the only way. The public APIs are for static applications, not for dynamic third-party AI agents.
What Salesforce and ServiceNow do differently
The timing makes the contrast all the more painful. In April, Salesforce announced Headless 360: an architecture where everything, data, workflows, and actions, is accessible via an API, MCP tool, or CLI command. More than 60 new MCP tools are usable from Claude Code, Cursor, or any MCP-compatible runtime. No proprietary AI interface is required as a mandatory gateway. An external agent can directly invoke a deterministic action to start a flow, create a record, or run a report, and Salesforce executes it. A single inference layer. Deterministic, auditable, testable.
Last week, ServiceNow followed up at Knowledge 2026 with Action Fabric: twenty years of workflows, playbooks, approval chains, and business rules, opened up to any AI agent via REST APIs and MCP. Again, this is possible without additional LLM inferencing. The intelligence layer is automatically built into every action. Clearly defined deterministic processes, access with governance, and an open architecture.
Both Salesforce and ServiceNow explicitly opt for the headless model: the platform as the execution layer, with the choice of AI left to the customer. Agents can execute predefined actions directly on their platforms and receive an intelligent response back from the knowledge graph and the metadata. No double inference unless you choose it yourself.
The architecture of the mandatory detour
At SAP, things are different. During the Q&A at Sapphire, the CTO labeled APIs as outdated technology, while he called A2A (Agent 2 Agent) and MCP (Model Context Protocol) new and modern. SAP only supports A2A for external AI agents to communicate with Joule, while the rest of the world primarily uses MCP as an open standard. SAP does use MCP internally for Joule and for its own gateway, but limits its scope externally.
The result: external agents are welcome at SAP, but only via A2A and Joule. This is a more expensive workaround and always results in double inference. Direct API access is legally blocked. This immediately creates a problem: the outcome is not deterministic and is open to interpretation by Joule.
There is also the new Integration Suite MCP Gateway, which will be released in Q2. It offers the same API access as before, but via MCP and with additional costs per call. It essentially acts as an agent tax on the use of external AI agents with SAP data. However, SAP’s own Architecture Center and Saueressig are clear: anyone who wants the intelligence layer, the Knowledge Graph, the business context, the process logic must use A2A and Joule. The MCP Gateway is not that route. It is a paid gateway to the same data that customers could previously access via direct API calls, and it comes without the intelligence that SAP positions as its key differentiator.
At SAP, intelligence is only possible through Joule. Anyone who wants intelligence must go through Joule. This means additional inferencing to understand the query, what actions are needed, and what data and intelligence must be added. This is despite the fact that the external AI agent has already performed its own inferencing. Double the inference, double the latency, double the cost. This is not a choice but an architectural requirement imposed by SAP.
Saueressig argues that A2A is the new standard for agent communication. Agents communicate via A2A, and that simply means double inference. Fundamentally, he is right, but that is only because SAP has exclusively opted for A2A.
The determinism problem
We also asked about the capabilities offered by Salesforce and ServiceNow to execute deterministic actions on the platform via APIs. When dealing with complex processes, absolute consistency is required. Take disputing a fraudulent credit card charge: multiple actions across various financial systems, should always execute the same way. The moment you involve an LLM and inferencing, that guarantee is gone. The AI model will determine the steps on each run, and those steps may not always be the same. Salesforce and ServiceNow argue that it’s better to define those steps in a deterministic workflow and invoke it. You don’t always need an LLM.
Saueressig argues that if you have a complex task requiring multiple steps, Joule works perfectly well, because Joule has the context, via the Knowledge Graph and metadata, to execute those steps correctly and accurately. Joule can indeed invoke a deterministic workflow internally. The problem, however, is that an inference step is involved, meaning certainty is never 100 percent.
Saueressig said that for clear, deterministic, rule-based processes, you shouldn’t use an agent at all. You should use rather standard automation via the public APIs. Those are open, you can call them. The only problem is that if the dispute over that fraudulent credit card charge was initiated via an external agent, SAP’s policy doesn’t allow the agent to call an API.
SAP will likely face many questions about this from organizations that want to use external AI platforms and have strict compliance requirements.
SAP’s argument and why it isn’t convincing
SAP’s argument is that Joule’s business context is so valuable that the mandatory route through Joule is justified. The Knowledge Graph provides correlations between finance, supply chain, HR, and procurement that don’t exist anywhere else. That justifies an intelligent orchestration layer.
There is a grain of truth to that argument. The breadth of SAP’s business data is unique. For complex, cross-domain processes, Joule can genuinely be valuable as an intelligent orchestrator.
Yet we see two problems with that argument.
First: if Joule is truly better, there’s no need to enforce it legally and make the old route more expensive. Customers will naturally choose Joule. The fact that SAP is making it mandatory via API policy suggests that SAP itself isn’t convinced customers will quickly opt for Joule.
Second: Salesforce and ServiceNow do not block direct API access, even though they also have a Knowledge Graph and have built intelligence into their platforms. They trust that this intelligence layer is valuable enough to attract customers without legal coercion. Both offer APIs to perform predefined actions directly on the platform and the ability to communicate with their agents. They also return information from their knowledge graphs without requiring an additional LLM layer. SAP could have simply added a governance layer to its APIs and tightened the rate limits, just as the rest of the industry does.
The numbers tell a different story
The DSAG Investment Survey 2026 shows that only 3 percent of all SAP customers use Joule in production. At the same time, 77 percent of AI-active SAP enterprises do use Microsoft Copilot. SAP has now cut off the direct path to the AI tools that 97 percent of customers already use. That doesn’t look like a strategy to attract customers to Joule, but a strategy to keep them from going anywhere else.
Saueressig argues that this is not a representative study, as fewer than 100 organizations participated in this survey, and the figures do not reflect reality. He states that 68 percent of Fortune 500 customers use SAP AI, but this does not specifically refer to Joule. SAP has been offering AI features in its software for ten years. The actual Joule adoption rate is therefore unclear. A 100-million-euro fund that SAP has made available to SAP partners to help customers adopt and implement Joule sends a different signal.
This is not the first time
In 2017, major SAP customers were shocked to discover that connecting external systems to SAP without the proper licenses could cost them millions. A British judge ruled that Diageo owed SAP over 54 million British pounds because Salesforce users had indirectly accessed SAP data. SAP also pursued AB InBev for a reported 600 million dollars; that dispute was eventually settled. SAP introduced the Digital Access model in 2018 as a compromise. Now, in 2026, the same pattern appears to be repeating itself, this time with AI agents rather than CRM users.
SAP partners: this strategy won’t hold
The analysis is shared by SAP partners who attended Sapphire. They indicated they were surprised by the API blockade. They used terms like “lock-in,” “walled garden,” and “firewall,” because connecting outward is allowed, but connecting inward via your own tools is restricted. In the long run, these partners expect this strategy to be unsustainable. Since the industry is moving in the exact opposite direction. They do not wish to be quoted by name, as they are at an SAP conference.
Conclusion
As far as we’re concerned, the Autonomous Enterprise isn’t a bad idea at all, but the underlying forced migration to SAP’s AI stack certainly is. This isn’t a fully open platform, like the rest of the industry, but a more closed one. The question is whether organizations are willing to run everything through Joule, and whether SAP is willing to bear the consequences if they aren’t.