SAP enterprise AI agents strategy centers on context and controls

SAP enterprise AI agents will need more than a general-purpose chatbot interface if companies expect them to run business workflows, SAP senior solution advisor Max McPhee said during an SAP-presented session at VB Transform 2026. In a conversation with VentureBeat Research lead analyst Rob Stretchay, McPhee argued that the useful line between an assistant and an agent is whether the software is grounded in the company’s own systems, terms and process data.

McPhee’s case is a practical one for enterprise buyers: agents that act inside finance, procurement, HR or operations systems need company context and enforceable permissions, not a broader model with better conversational polish. SAP did not disclose adoption figures, customer counts or performance benchmarks for the approach in the discussion.

Why does SAP say enterprise AI agents need knowledge graphs?

McPhee said agents begin to feel less like chat tools when they can work from enterprise-specific context rather than generic information. He compared the problem to onboarding an employee, with a software-specific twist: the agent needs the organization’s operational knowledge in formats it can retrieve reliably.

That is where SAP is positioning knowledge graphs and vector-embedded data. McPhee said those formats make it easier for an agent to locate information and interpret internal terminology, including acronyms and informal business shorthand that a conventional chatbot might fail to understand.

A knowledge graph connects business entities and relationships, such as customers, orders, suppliers, systems and processes, so software can reason across them rather than treat each record as an isolated document. In SAP’s telling, that structure gives agents a map of how work happens inside a particular company.

Governance moves from policy to execution

McPhee also tied agent deployment to SAP’s long-running role in process control. He said the company is adapting its governance model for more flexible systems that can take action, rather than only route a predefined workflow.

One mechanism he cited is the use of machine learning to check agent behavior. According to McPhee, some customers are running agents inside processes while adding anomaly detection and machine-learning validation as guardrails, similar to the way SAP has used intelligent approval recommendations.

Identity is another constraint in SAP’s model. McPhee described a setup in which both the user and Joule, SAP’s generative AI assistant across its cloud applications and Business Technology Platform, must have access rights to a system. A user with permission to use S/4, for example, would still be blocked from reaching it through Joule if the assistant itself has not been granted that access. The point is to prevent agents from becoming a workaround for existing controls.

SAP is trying to map the systems it does not own

McPhee said many SAP customers tell the company that SAP represents only a small share of their overall enterprise environment. That creates a problem for agents built around SAP’s own application knowledge, because decades of customization and non-SAP tools shape how work actually gets done.

SAP’s answer includes acquisitions and investments aimed at mapping and automating beyond its core software. McPhee pointed to LeanIX, which he described as a tool for understanding enterprise architecture, and Signavio, the process-mining company SAP acquired. He also cited SAP’s investment in Berlin-based automation company n8n and said SAP is embedding n8n natively into Joule Studio, its intent-based low-code environment for building agents.

McPhee warned that older on-premises systems may limit agent rollouts if companies do not modernize them. His argument was that autonomous agents can put new throughput demands on legacy infrastructure, so the systems underneath may need upgrades before companies expand agent-driven execution.

This story draws on original reporting from VentureBeat.