At Sapphire 2026, SAP presents Autonomous Enterprise as the future of enterprise software. Ambitions are grand. But behind the glossy keynote lies a fundamental strategic choice that directly contradicts the direction the rest of the market is taking. While other companies are open and choosing headless architectures, SAP is choosing an architecture that sidelines external AI agents and requires everything to go through a Joule.
SAP’s central message in Sapphire 2026 is clear: The company wants its software to run business processes autonomously, rather than simply recording the results of human work. More than 50 Joule assistants manage more than 200 specialized agents across finance, supply chain, human resources, procurement, and customer experience. The new SAP Business AI Platform integrates SAP Business Technology Platform, SAP Business Data Cloud, and SAP Business AI into a single management environment. At its core is the SAP Knowledge Graph.
That’s impressive. The underlying data ambitions are also really strong. SAP stores 50 years of business-critical process data in a single integrated system. No other vendor has finance, supply chain, procurement, human resources, and production so deeply interconnected. But that’s it.
SAP closes its doors
While Salesforce and ServiceNow have opted to go fully open in recent weeks, SAP is taking a different path. 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 schedule or execute calls on their own. In layman’s terms, external AI agents can no longer use SAP APIs.
The API policy is as follows
CEO Christian Klein tried to calm the situation by saying customers would not have to pay for access to their data. However, in SAP, verbal warranties and contractual obligations are different matters. Meanwhile, the policy remains the same. External AI agents cannot use SAP APIs.
During Sapphire 2026, we discussed this with Chief Customer Officer Thomas Saueressig. He defended the policy as necessary governance for multi-tenant platforms. Still, his conclusion was clear. For agent use cases, A2A via Joule is the only way. The public API is for static applications, not dynamic third-party AI agents.
Differences between Salesforce and ServiceNow
The timing makes the contrast even more harrowing. In April, Salesforce announced Headless 360, an architecture that allows you to access data, workflows, actions, and more through APIs, MCP tools, or CLI commands. Over 60 new MCP tools can be used from Claude Code, Cursor, or any MCP-compatible runtime. There is no need for a proprietary AI interface as a required gateway. External agents can directly invoke deterministic actions like starting a flow, creating a record, or running a report, and Salesforce takes care of it for you. Single inference layer. Definitive, auditable, testable.
Last week, ServiceNow announced Action Fabric at Knowledge 2026. Two decades of workflows, playbooks, approval chains, and business rules are now exposed to any AI agent via REST APIs and MCPs. Again, this is possible without additional LLM reasoning. A layer of intelligence is automatically built into every action. Well-defined deterministic processes, access with governance, and open architecture.
Both Salesforce and ServiceNow have explicitly chosen a headless model, the platform as the execution layer, leaving the choice of AI to the customer. Agents can perform predefined actions directly on the platform and receive intelligent responses from knowledge graphs and metadata. You cannot make double inferences unless you choose to do so.
Forced diversion architecture
Things are different with SAP. During a Q&A at Sapphire, the CTO classified APIs as outdated technology, while A2A (Agent 2 Agent) and MCP (Model Context Protocol) are new and modern. SAP only supports A2A for external AI agents to communicate with Joule, while other countries primarily use MCP as an open standard. SAP uses MCP internally for Joule and its own gateways, but its scope is limited externally.
As a result, SAP welcomes external agents, but only via A2A and Joule. This is a more expensive workaround and always results in double inference. Direct access to the API is legally blocked. This immediately causes problems. The results are not deterministic and are open to Joule interpretation.
There is also a new Integration Suite MCP Gateway released in Q2. The same API access as before is provided, but via MCP and with an additional charge per call. This essentially acts as an agent tax for the use of external AI agents with SAP data. However, SAP’s own architecture center and Saueressig are clear. Anyone who needs an intelligence layer, knowledge graph, business context, and process logic should use A2A and Joule. The MCP gateway is not that route. This is a paid gateway to the same data that customers previously had access to through direct API calls, and it does not have the intelligence that SAP positions as a key differentiator.
In SAP, intelligence is only possible through Joule. Anyone who seeks intelligence must pass through Joule. This means additional reasoning to understand the query, what actions are required, and what data and intelligence should be added. This is despite the fact that the external AI agent is already performing its own inference. Double the inference, double the latency, double the cost. This is not a choice, but an architectural requirement imposed by SAP.
Saueressig claims that A2A is the new standard for agent communication. Agents communicate via A2A, which simply means double reasoning. Basically, he’s right, but that’s only because SAP chose to go A2A-only.
determinism problem
We also asked about the capabilities that Salesforce and ServiceNow offer to take decisive actions on their platforms through APIs. When dealing with complex processes, absolute consistency is required. Consider disputing fraudulent charges on your credit card. Multiple actions across different financial systems must always be performed in the same way. The moment you involve LLM and reasoning, that guarantee is gone. The AI model determines the steps for each run, but those steps are not always the same. Salesforce and ServiceNow argue that it’s better to define and call these steps in a deterministic workflow. An LLM is not always required.
Saueressig argues that if you have a complex task that requires multiple steps, Joule works perfectly well because it has the context to execute those steps precisely and precisely through its knowledge graph and metadata. Joule can actually call deterministic workflows internally. However, the problem is that it is not 100% certain because it involves an inference step.
Saueressig said that to achieve a clear, deterministic, rule-based process, agents should not be used at all. Standard automation via public APIs should be used. They are open and you can make phone calls. The only problem is that if a fraudulent credit card charge dispute is initiated through an external agent, SAP’s policy does not allow the agent to call the API.
SAP may face many questions regarding this from organizations that want to use external AI platforms and have strict compliance requirements.
SAP’s argument and why it’s not convincing
SAP’s argument is that the business context of Joule is so valuable that a mandatory route through Joule is justified. The Knowledge Graph provides correlations between finance, supply chain, HR, and procurement that don’t exist anywhere else. This 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 has real value as an intelligent orchestrator.
However, I see two problems with this argument.
First, if Joule is truly better, there’s no need to legislate it and make the old route more expensive. Customers will naturally choose Joule. The fact that SAP is mandating this through its API policy suggests that SAP itself is not convinced that customers will choose Joule anytime soon.
Second: Salesforce and ServiceNow also have knowledge graphs and do not block direct API access, even though they have intelligence built into their platforms. They believe this layer of intelligence is valuable enough to attract customers without legal enforcement. Both provide an API to perform predefined actions directly on the platform and the ability to communicate with agents. It also returns information from the knowledge graph without requiring an additional LLM layer. SAP, like other industries, could have simply added a governance layer to its APIs and tightened rate limits.
The numbers tell a different story
According to DSAG Investment Survey 2026, only 3% of all SAP customers use Joule in production. At the same time, 77% of SAP companies actively leveraging AI are actually using Microsoft Copilot. SAP has now cut off the direct path to the AI tools that 97% of its customers already use. It looks like a strategy to keep customers from going elsewhere, rather than a strategy to attract customers to Juul.
Saueressig argues that this is not a representative study because fewer than 100 organizations participated in the study and the numbers do not reflect reality. He says 68% of Fortune 500 customers use SAP AI, but he’s not referring specifically to Joule. SAP has been offering AI capabilities in its software for a decade. Therefore, the actual Joule adoption rate is unknown. The €100 million fund that SAP has provided to SAP partners to help customers adopt and implement Joule sends another signal.
this is not the first time
In 2017, major SAP customers were shocked to learn that connecting external systems to SAP without the appropriate licenses could cost them millions of dollars. A British judge has ruled that Diageo owes SAP more than GBP 54 million because Salesforce users indirectly accessed SAP data. SAP also pursued AB InBev for a reported $600 million. That dispute was eventually resolved. SAP introduced a digital access model in 2018 as a compromise. Now in 2026, the same pattern appears to be repeating itself, but this time it involves AI agents rather than CRM users.
SAP partners: this strategy doesn’t work
This analysis is shared by SAP partners who have joined Sapphire. They expressed surprise at the API blockage. While connections to the outside world are allowed, connections to the inside through proprietary tools are restricted, hence the use of terms such as “lock-in,” “walled garden,” and “firewall.” In the long term, these partners expect this strategy to become unsustainable. Because the industry is moving in exactly the opposite direction. They are attending an SAP conference and do not want their names quoted.
conclusion
As far as we’re concerned, the autonomous enterprise isn’t a bad idea at all, but the forced migration to SAP’s underlying AI stack certainly is. This is a more closed platform rather than a fully open platform like other industries. The question is whether the organization is willing to run everything through Joule, and whether SAP is willing to bear the consequences if it doesn’t.
