At Sapphire, SAP makes the case that enterprise AI is a context problem
At SAP Sapphire 2026 in Orlando in May, SAP made the case that the enterprise AI race will not be won by the company with the best chatbot, the flashiest agent demo, or even the most capable LLM. It will be won, SAP believes, by the platform that can provide agents with enough business context, data access, and governance to do real work within mission-critical systems.
This is a theme many enterprise software vendors are now emphasizing. Atlassian has Teamwork Graph. ServiceNow has Workflow Data Fabric. Salesforce has Data Cloud and Agentforce. SAP’s approach builds on its long-standing ERP foundation: the business processes, data models, authorizations, compliance rules, and customer-specific extensions that reside within its customers’ SAP landscapes.
At Sapphire, SAP consolidated a number of its existing services under a new banner: SAP Business AI Platform. This platform brings together the SAP Business Technology Platform, SAP Business Data Cloud, SAP Autonomous Suite, and SAP Business AI, as well as tools like Joule Work, and strengthens the company’s messaging around the “Autonomous Enterprise.”
As SAP noted at the event, the Autonomous Suite will include more than 50 domain-specific Joule Assistants that orchestrate over 200 specialized agents across finance, supply chain, procurement, human capital management, and customer experience. Joule Work, meanwhile, is SAP’s attempt to make its Joule AI agent service the front door to those workflows across SAP and non-SAP systems.
The real play here, however, is that SAP is aiming to translate its long-standing Enterprise Resource Planning advantage — which has held up across multiple technology eras — into an AI-era context layer.
“What’s not differentiating is the LLMs… Use OpenAI models, use Anthropic models, whatever you like.”
“What’s not differentiating is the LLMs,” SAP CTO Philipp Herzig said during a post-keynote Q&A. “Use OpenAI models, use Anthropic models, whatever you like.” Coding assistants, too, are not where SAP expects to differentiate, he says. “You can use Claude Code, who cares? Use the tool you like. That’s non-differentiated. They’re all amazing.”
What matters, Herzig argued, is everything around the model. The important thing is whether an agent knows the right business entities, can find the right data, has the right access controls, and can be tested against real enterprise data rather than a few happy-path prompts.
For example, he said, too many teams do not build evals at all. They do what he calls “vibe checking.” “They just go in, and they try three things and feel happy with it,” he said.
SAP’s answer to this is to have its platform automatically generate more of that enterprise scaffolding, including product requirements, technical specifications, tests, data connections, security setup, observability, and governance.
Models are a commodity layer
This also means that SAP is very explicit about where it does not want to compete. “We’re not going to build our own large language model, to be clear,” Sean Kask, SAP’s chief AI strategy officer, said in an interview with The New Stack at Sapphire.
Kask’s view is that SAP should partner where generic technology is best available and build where SAP has unique assets. That is why SAP can lean on partner models from companies such as Anthropic, Mistral AI, and Cohere, while also investing in SAP Domain Models for specialized tasks and SAP-RPT-1.5, because it is in these areas where the company believes it has the differentiated data and domain knowledge to make a difference for its customers.
The same logic applies to agent frameworks. Kask noted that SAP agents are built on common open-source frameworks such as AutoGen and LangChain, and if another framework becomes better, SAP can switch. “It’s how we apply it to the business problem and allow those agents to talk to third-party agents,” he said.
This kind of openness is something SAP has focused on in recent years, and the company is not positioning the new Joule Studio, for example, as a siloed SAP-only development environment. Instead, the company is emphasizing that developers can use the models, coding tools, and frameworks they prefer, including no-code and pro-code workflows, n8n for visual orchestration, and Vercel for React-based front ends. And SAP is putting some money behind this strategy with its investment in n8n, too.
Sid Misra, who leads platform marketing at SAP, described this as SAP going “where the developers are.” Developers can use SAP’s own tools for SAP UI5 and Fiori, or bring in newer web and agentic tools where they fit.
For SAP, that’s all fine, because it still provides the context that grounds all of this work, and without this context, none of these AI agents and tools work all that well.
The data layer behind the agent pitch
This is also where SAP’s recent acquisitions come in. The company announced plans to acquire Dremio to make SAP Business Data Cloud an Apache Iceberg-native lakehouse for SAP and non-SAP data. It also announced plans to acquire Prior Labs, a tabular foundation model startup, and recently completed its acquisition of Reltio for master data management.
All of these make sense in a world where agents need structured business data and process knowledge.
But at the same time, relational data is “not going anywhere,” as Yaad Oren, the managing director of SAP Labs U.S. and global head of SAP Research & Innovation, put it in an interview.
Relational data is, in his words, the “bread and butter of databases,” and ERP and SAP S/4HANA systems are built on it.
Oren acknowledged that tabular models are not as flashy as video models or avatar demos, but for SAP’s customers, they obviously matter far more.
Tabular data models may not be “the most sexy thing,” he said. “But for business, more and more people will understand this is a treasure trove. If you do it right, you can have your enterprise data at scale.”
At Sapphire, SAP introduced SAP-RPT-1.5, the next version of its relational pretrained transformer (hence the acronym) for structured data. The bet is that RPT and the Prior Labs technology it has now acquired can reduce the need to build narrow predictive models for every single task and vertical, while still supporting explainability over rows and columns.
Governance as the core differentiator
Another part of SAP’s overall argument is governance. If every department can now build agents, every enterprise will soon have a compliance problem.
SAP’s answer to this is the AI Agent Hub. It is designed to discover, inventory, and govern SAP and non-SAP agents, LLMs, and MCP servers. The company will include this service for all SAP Business AI Platform customers at no extra charge, clearly indicating that it believes this has been a major roadblock to agent adoption in the enterprise.
One area here that SAP is focused on is ‘agent mining,’ which isn’t exactly a household name yet. Oren described it as an extension of process mining. While process mining gives companies a detailed view of their workflows and transactions, agent mining, as defined by SAP, does the same for agents. It catalogs what they did, what actions they took, where they were bottlenecked, and whether they behaved as expected.
Now, as agents “come to life,” as Oren put it, SAP’s customers need to have a deep understanding of what they are doing, just as they would with their human employees.
This governance message also provides context for SAP’s recently updated approach to API access. SAP recently announced a somewhat more restrictive access policy for its APIs. During the Q&A session, Herzig pushed back on the idea that this new API policy was designed to lock down customer access. He argued that in this new age of AI agents hammering these APIs, there is a new need for rate limits, better API hygiene, and a move away from old channels toward governed protocols like MCP and Agent2Agent.
Muhammad Alam, SAP executive board member for product and engineering, added that raw API access is not the same thing as safely invoking business logic. For SAP, the preferred approach is to expose that logic through orchestration and A2A, thereby preserving compliance, auditability, and statutory requirements.
This complicated SAP’s openness message. On one hand, the company is embracing MCP, A2A, n8n, Vercel, and multiple LLMs. On the other hand, SAP clearly wants the most important enterprise work to happen on an SAP-governed layer.
But maybe that’s ok. Kask, for example, does not expect one vendor to become the universal orchestrator anyway.
“Everyone wants to be like the orchestrator and uber agent. I don’t think anyone’s going to achieve that.”
“Everyone wants to be like the orchestrator and uber agent. I don’t think anyone’s going to achieve that,” he said. “You’re going to have one agent and one orchestrator talking to another agent and another orchestrator and, you know, there may be one or several governance platforms in place.”
Avoiding RPA 2.0
For all the agent talk at Sapphire, SAP’s executives also repeatedly returned to a more basic point: none of this will work well if customers simply bolt AI onto broken processes and messy data. In the Q&A, SAP COO Sebastian Steinhaeuser, for example, warned that companies could otherwise “go with light speed into an RPA 2.0 disaster,” where AI gets layered over broken processes and architecture without real governance.
