SAP's Ontology Manager: Bridging Knowledge Graphs and Business Execution for Enterprise Agents

Introduction

At TechEd 2026, SAP unveiled a new enterprise AI architecture centered on the SAP Business Data Cloud Ontology Manager . This component organizes fragmented business data into an ontology containing concepts, relationships, constraints, and data mappings, and links business semantics to execution capabilities via Business Actions . SAP's reference architecture frames this as three stages: Model, Reason, and Execute . The Ontology Manager beta is slated for November 2026, with SAP Knowledge Graph extensions generally available in Q1 2027 (per DSAG announcement).

01 Why Agents Can Access Data But Still Misunderstand Business

SAP illustrates the gap with a concrete example: unfreezing a blocked supplier invoice . An agent can query the invoice ID and payment status, but determining why it was blocked requires traversing purchase orders, goods receipts, and approval records. Even after locating the anomaly, the agent cannot simply change the payment status; it must verify business conditions and user permissions.

These two information layers are distinct:

Data layer : invoice amount, supplier ID, purchase order, goods receipt quantity, current status — retrievable via database queries or APIs.

Business semantics layer : relationships among objects, conditions allowing operations, and which system executes them — scattered across system configurations, process rules, data models, and internal policies.

Existing approaches fall short:

RAG retrieves document snippets but not governed business definitions.

Text-to-SQL generates queries from table schemas without guaranteeing accurate understanding of business semantics across systems.

Function Calling invokes tools, yet tool descriptions often lack complete business constraints.

Example: Procurement and finance systems may both have a Supplier field but use different numbering, hierarchy levels, or master-data rules. A model relying only on field names may incorrectly join records that are technically linkable but business-wise distinct. Embedding mapping rules in prompts or pre-written SQL leads to fragmentation and high maintenance as agent count grows.

SAP aims to solve this by creating an independent, governed semantic layer that multiple agents can reuse, rather than having each agent re-learn business logic from raw schemas.

02 Turning Data Tables into an Enterprise Ontology

SAP's approach builds on existing Data Products (governed data resources with schema, ownership, access rights) and adds the Ontology Manager to define business concepts, relationships, constraints, and mappings to underlying data products.

In a procurement scenario, data resides in supplier master data, purchase orders, goods receipts, and invoice details — each with its own fields, keys, and joins. Business users think in terms of supplier, order, receipt, invoice , not columns. The Ontology Manager formalizes these concepts and maps them to the data products.

An AI-assisted modeling flow (per the Oct 22 reference architecture) reads source schema metadata to suggest concept names, entity relationships, and join mappings. Developers refine these in a visual editor or import existing ontologies. The AI suggestions are based on metadata only; correctness and cross-system entity merging still require business expertise.

Technical standards adopted:

RDF for entity relationships

OWL for concept definitions and semantic constraints

SHACL for graph structure and constraint validation

OBDA (Ontology-Based Data Access) for mapping concepts to underlying data

SPARQL as the graph query language

These are not new standards; SAP's novelty lies in integrating them into the enterprise agent's data access and execution pipeline.

Distinction between Ontology and Knowledge Graph :

Ontology = formal domain model defining concepts, relationships, constraints.

Knowledge Graph = instantiates those concepts/relationships with actual data and metadata, making them queryable.

SAP Knowledge Graph previously linked SAP APIs, business entities, data models, and metadata. The new Ontology Manager extends this to customer-specific SAP and non-SAP data, adding custom business concepts and mappings.

The reference architecture also positions Dremio (federated data access/compute) and Reltio (cross-system entity resolution) alongside the Ontology Manager. Together they aim to let agents locate business concepts first, then follow mappings to relevant data without guessing physical table structures.

This shifts business knowledge maintenance: previously, a supplier-order join logic might live in report SQL, ETL jobs, and multiple agent prompts. Now it can be centralized in a reusable, governed ontology model. When underlying systems change, updating the semantic mapping can insulate upper-layer applications — provided business concepts remain stable and mappings are kept current.

Key insight: Ontology does not make complex business rules disappear; its value is extracting those rules from scattered application logic into independently manageable, reusable enterprise knowledge.

03 SPARQL to SQL: Cross-System Queries Without Full Data Replication

After building the ontology, agents must access business data. SAP's reference architecture offers two paths:

Virtual Knowledge Graph (VKG)

Separates business semantics from physical storage. Developers define concepts and relationships in the ontology, then map them to Data Products. At runtime, a SPARQL query is translated to SQL, with filter pushdown to data sources where possible. No full graph data copy is created per query.

Example: Agent queries a supplier's purchase orders and their invoice statuses. It uses the ontology to find Supplier, PurchaseOrder, Invoice relationships, then the mapping layer generates the appropriate SQL against the underlying tables.

SAP mentions OWL 2 QL reasoning for query expansion based on ontology relationships. This differs from Text-to-SQL where the model must directly understand the database schema; here the model works with business concepts, and the mapping layer handles data access details.

However, VKG still relies on underlying SQL execution. It provides an abstraction, not a database replacement. Cross-system queries remain subject to network latency, remote system load, join execution plans, and permission filtering. SAP documents query translation and pushdown mechanisms but has not published comprehensive benchmark data proving performance advantages under complex enterprise loads.

Materialized Knowledge Graph (MKG)

Uses Apache Spark pipelines to materialize business relationships as RDF triples stored in SAP HANA Cloud Knowledge Graph . This persists semantic relationships, suitable for continuous graph-structured analysis, lineage, or audit scenarios. Trade-offs: extra storage, update/consistency/maintenance overhead.

Thus SAP's suite is not simply a "no-data-movement knowledge graph"; it offers both virtual (runtime query, minimal replication) and materialized (persistent triples) mechanisms for different needs.

SHACL is used for pre-publication constraint checks (mandatory fields, value ranges, relationship cardinality, some cross-entity consistency). This catches modeling errors early but cannot cover all business rules, nor guarantee every real transaction has passed compliance validation. Real-time validation still requires application services and business rule engines.

Engineering value: enterprises can organize multiple data access modes around a unified business semantics. The business layer uses stable entities/relationships; the execution layer chooses between direct data access or materialized graph per query scenario. The real test is whether this abstraction reduces duplicate development and whether the added semantic maintenance cost pays off.

04 Business Actions: Connecting Ontology to Real Business Execution

If Ontology Manager only unified data meaning, it would be a traditional semantic layer extension. SAP's addition of Business Actions is more distinctive.

In the reference architecture, Business Actions bind to ontology business concepts and connect to workflows, backend APIs, or ML inference. A Business Action includes not just an API name but also required inputs, preconditions, and allowed roles. After an agent identifies a business object via the ontology, it can use this metadata to judge applicability and invoke the execution interface.

Contrast with simple tool calling: tool descriptions help the model understand an API's function; Business Actions further bind tool capabilities to explicit business entities and operational conditions.

Revisiting the frozen invoice: Agent identifies the invoice, purchase order, and goods receipt via ontology, queries business state. If a quantity discrepancy needs reconciliation, it selects an exception-handling Business Action rather than directly attempting unfreeze. When process conditions are met, the system may create a handling task via workflow; if finance approval is required, the approval mechanism decides whether to proceed.

Important: This is a technical illustration from SAP's reference architecture, not a disclosed customer production result.

Planned integrations: SAP Build , n8n workflows; S/4HANA OData API , SAP Integration Suite API . The goal is not to make the ontology execute all business logic, but to give agents a clear path from business semantics to governed execution systems.

MCP (Model Context Protocol) plays a key role: Ontology Manager exposes semantic knowledge, query capabilities, and Business Actions via an MCP Server to Joule (SAP's AI copilot). Joule uses these to identify business objects, run SPARQL queries, and invoke operations. MCP solves how tools and contextual capabilities are provided to agents, not all business governance issues.

For inter-agent collaboration, SAP proposes A2A and a governed Agent Gateway so external agents can consume Joule Agent capabilities. MCP and A2A operate at different layers: MCP for agent-to-tool/capability access; A2A for agent-to-agent communication and task delegation.

SAP's FAQ clarifies that external agents indirectly use SAP-side agent capabilities via A2A, not unrestricted direct access to SAP Knowledge Graph. This governance boundary is critical: unrestricted external access would reintroduce complex cross-system identity, permission, and audit challenges. SAP aims to reduce risk via a unified entry point and controlled Business Actions.

Actual permission checks remain with backend systems. SAP's Oct 26 FAQ explicitly states: LLMs cannot serve as authorization enforcement points . When an agent calls a tool, the relevant business system and integration service must verify permissions. For user-representing agents, user context and applicable permissions must be passed; for autonomous agents without live user sessions, separate identities, permissions, and audit trails are required. Agent permissions can be configured as a subset of user permissions.

This draws a clear line: Ontology helps agents understand business objects and available actions, but whether execution is allowed is decided by trusted backend systems. Example: Agent may discover an "unfreeze invoice" Business Action via ontology, but cannot bypass payment review and directly modify status. Write operations still go through the business application's original APIs, permission controls, validation logic, and transaction mechanisms.

Thus Business Actions' value lies in connecting scattered business semantics, tool definitions, and governed execution flows — not in granting LLMs unlimited system operation rights. The model proposes actions; backend systems validate, authorize, and reliably execute. This aligns better with real production requirements than merely adding more tools.

05 Can Ontology Become the Next Infrastructure Layer for Enterprise Agents?

SAP's direction shows enterprise ontology evolving closer to agent execution. Traditionally, ontologies and knowledge graphs unified data definitions, supported knowledge retrieval, organized entity relationships, and improved data integration. As agents participate in real business processes, these capabilities gain new application space.

A question-answering agent may only need correct data; an agent handling procurement exceptions or finance approvals also needs object relationships, operation conditions, and system permissions. If this knowledge stays scattered across prompts, tool descriptions, and custom business code, development and maintenance complexity grows.

A shared business ontology lets multiple agents work on the same semantic definitions, reducing duplicate modeling.

However, ontology does not replace RAG, semantic layers, business rule engines, or workflows. They solve different problems:

RAG excels at retrieving context from unstructured documents.

Ontology emphasizes formalized business concepts, relationships, constraints.

Business rules and workflow engines handle deterministic judgment and execution.

Effective enterprise agent architecture likely requires these capabilities working in concert, not a single replacement technology.

SAP's approach faces practical challenges:

Ontology construction and maintenance : Business concepts change with system upgrades, org changes, process shifts. AI can suggest candidate relationships but cannot guarantee correctness, especially for cross-system entity matching, semantic conflicts, complex approval rules. Data owners and business experts must remain involved. SAP's FAQ admits that UI, governance processes, and conflict resolution for Knowledge Graph content are not yet finalized.

System cost : VKG must handle cross-source query performance and semantic translation overhead; MKG requires continuous data refresh. Adding Business Actions introduces permission propagation, runtime audit, error recovery, long-running process engineering concerns. For simple, stable queries, a full ontology governance and agent orchestration stack may not be cost-effective.

Enterprises should verify whether these new architectural capabilities lower total development/maintenance cost and improve task completion rates. A pragmatic path: start with a bounded scenario like supplier invoice exception handling, establish a few key business objects and relationships, define necessary queries and actions, then measure: reduced erroneous joins? accurate root-cause identification? reduced manual handling? added latency and maintenance overhead from the semantic layer? These metrics prove value better than a knowledge graph demo.

SAP's long-term AI-native North Star architecture envisions a Context Graph combining Knowledge Graph (business entities, relationships, semantics) with Decision Lineage (recording what information the agent gathered, options considered, actions taken, and outcomes). Together, enterprise context would include not just static business knowledge but historical decisions and execution experience. This remains an architectural vision, not yet delivered or production-validated.

Returning to the TechEd release, the most significant aspect of Ontology Manager is not how fast it can generate an ontology, but its attempt to change how enterprise agents consume business knowledge. Previously, agents faced raw tables, APIs, and documents, assembling execution context themselves. SAP proposes a reusable semantic model atop those resources, explicitly linking business objects, relationships, and operational capabilities. Agents then operate in a more stable business context while actual execution remains with existing business systems.

Whether this architecture truly reduces implementation difficulty and improves execution reliability awaits beta delivery and more production validation. But the engineering direction is clear:

The next step for enterprise agents is not merely connecting more systems, but establishing a shared understanding of business objects, relationships, and execution boundaries.

LLMs provide reasoning; ontology provides business semantics; business APIs and workflows provide deterministic execution. How these three reliably connect may matter more than improving any single component in isolation.

References

SAP TechEd 2026 Official Announcement | Oct 27, 2026

SAP Architecture Center: Ontology Manager | Updated Oct 22, 2026

SAP AI-native North Star: Foundation Layer | Updated Oct 23, 2026

SAP AI-native North Star: Frequently Asked Questions | Updated Oct 26, 2026

DSAG: SAP TechEd 2026 Technical Announcements & User Group Observations | Oct 27, 2026