Presented by SAP
Enterprise AI agents make reliable business decisions only when they understand business structure: the relationships between customers, suppliers, products, and financial records; the business processes those records move through; and the business rules that give each data point its meaning. Without that context, an agent can have complete and accurate data and still make the wrong decision. It might block a valid invoice payment, for example, because the invoice itself doesn’t reveal the vendor’s relationship to a parent company or the credit arrangements that apply.
Enterprise AI needs three kinds of business knowledge that general-purpose large language models lack, says Yaad Oren, Global Head of Research and Innovation and Managing Director of SAP Labs U.S.: how business entities relate to one another, the business process surrounding each task, and the exceptions and variations that arise in real-world operations.
“Retrieving data with just a customer’s name and total amount isn’t enough,” Oren says. “You need all the connections around that customer: how many sales orders they have, their satisfaction rate, how many delayed shipments they’ve had, and which manufacturing plant those orders come from. Agents need a knowledge graph that maps those relationships before they can reason well.”
What it means for AI to understand a business
Every enterprise AI task belongs to a process, whether a payment, an order, a shipment or an employee onboarding, and process context tells the agent which step it occupies, what came before it, and what happens next. Exceptions come from the people running those processes, who approve and delay work based on human judgment outside business systems.
“Not everything obeys the letter of a process,” Oren says. “You need to understand when something is an exception, how to manage it, and how to bring it back as an understandable context to the answer or the activity you want.”
The scope of that understanding widens fast once it’s in play. A question that starts with customer information, such as marketing campaigns and discounts, turns into a question about delivery dates, which belong to supply chain management, and then about payments, which belong to finance.
“Connecting everything into a map of your business, with the knowledge graph and the ontology, is where we get value,” Oren says. “The intelligence in AI comes from that.”
Why knowledge graphs and ontologies aren’t enough
A knowledge graph could link every invoice in a company and still leave an agent with contradictory signals if different parts of the business mean different things by “invoice.” For one department, it might refer to a customer payment; for another, a travel reimbursement; for a third, a supplier bill. An ontology resolves that ambiguity by giving each term a consistent business meaning and carrying that meaning across systems and data sources.
“In global corporations with hundreds of thousands of people, those records need to connect to each other and also speak the same language,” Oren says. “The ontology gives you one truth, one voice for all the data you have.”
SAP Business AI Platform (BAIP) is designed to bring data and business context into a governed environment. Its knowledge graph captures relationships among customers, suppliers, assets, products, organizational structures, and business processes, allowing that context to be reused across agents.
But shared meaning gets an agent only part of the way. The platform also has to supply the operational context that determines how a task should be carried out: service-level agreements and payment terms, tax and security policies, regional restrictions, data anonymization rules, and other constraints.
Why agents need models built for business data
There is another challenge lower in the stack. Much of the data inside companies is relational and transactional, organized in tables rather than natural language. General-purpose language models weren’t designed specifically for that structure.
SAP is addressing that gap with tabular foundation models, including its RPT-1.6 (Relational Pre-trained Transformer) and TabPFN-3.5 Plus from Prior Labs, SAP’s frontier AI lab. These models are designed to work directly with structured business data, including characteristics such as missing values, mixed data types, and high-cardinality fields. SAP’s tabular orchestration capability in AI Core handles context selection and data access at runtime so those predictions can be incorporated into production workflows.
“The data inside a business is fundamentally relational and transactional,” Oren says. “You need models that understand that structure natively.”
Governance changes when agents start taking action
The stakes change when an agent moves from answering questions to taking action. A bad answer can be reviewed or ignored; a wrongly blocked payment, rejected order or credit-risk flag can immediately affect a supplier, customer, or business process.
“You always need to challenge the answer,” Oren says. “Business understanding gives AI more knowledge, and it also gives it more boundaries. What you retrieve with it covers policies, security considerations, and everything else relevant to the decision.”
Those boundaries become more important as companies deploy agents across systems and functions. On BAIP, agents operate under uniquely provisioned identities with scoped permissions and an audit trail recording who acted, their authorization scope, and the actions taken. AI capabilities undergo ethics and risk reviews, and agents are assessed on a feature-by-feature basis to ensure alignment with applicable regional policies, privacy laws, and regulatory requirements.
Business rules also need room for exceptions. Oren points to what SAP calls a “parked document.” After a company event, a controller might need to allocate catering invoices across several budgets before they can move forward. If that controller is out of the office, an agent monitoring the process might interpret the stalled invoices as a serious delay. With broader business context, it can recognize that the person responsible is on vacation or parental leave and treat the delay as an exception rather than a process failure.
The four parts of an enterprise AI stack
Oren describes an enterprise AI architecture with four layers:
Model: Models that can interpret the relational and transactional data stored in enterprise systems.
Platform: Knowledge graphs, semantic layers, context and governance, along with capabilities for building and managing agents.
Agents: Agents that carry out work across applications and functions such as finance and supply chain, automating much of the transaction flow.
User experience: The interfaces through which people interact with agents, including text, voice and dynamic visualizations.
The platform is the critical layer for business understanding. When relationships, definitions, and process context live there rather than inside individual applications, they can be reused across agents. A finance agent and a supply chain agent don’t each have to reconstruct what a customer, supplier or transaction means; they can reason from the same underlying representation of the business. Governance belongs there too, making agents and their actions traceable as companies deploy more of them.
SAP maps its products onto those layers, from its tabular foundation models and BAIP to Joule Agents across functions including finance and supply chain. But Oren’s broader argument is that models and agents cannot understand a business on their own. They depend on business context, including knowledge graphs, semantics, and governance. Models need to understand the structure of business data. Agents need relationships, definitions, and process context; and the platform needs to enforce the rules and boundaries that determine how that context can be used.
“The context, the knowledge graph, and the semantics, across SAP data and beyond, are where our advantage comes from,” Oren says. “I believe every company that wants to build a promising enterprise application at scale needs them.”
Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.