Skip to content
Artwork for Iris AI Digest
Iris AI Digest · October 25 · 7 min

AI Digest — October 25, 2026

Good day, here's your AI digest for October 25, 2026. SAP chief technology officer Philipp Herzig is challenging the idea that AI coding tools make enterprise software obsolete. His argument starts with the difference between generating an application and operating a business process. An expense app might be straightforward to create, but running it across forty countries means handling tax rules, permissions, reimbursements, and changing requirements. Herzig says the distance between a convincing prototype and a dependable production system still involves substantial human work. As agents take on more responsibilities, they need trusted data, business context, security, and governance. The interface may change dramatically while those obligations remain. His assessment puts application generation within a larger engineering problem: someone must maintain the dependencies, resolve exceptions, and own the behavior after the demonstration ends. SAP's Joule Work approaches enterprise software by letting people describe what they want to accomplish. Rather than navigating several applications and assembling information manually, users can ask Joule to bring together the relevant information and capabilities. A feature called Spaces can turn that request into a visual workspace containing charts, tables, or dashboards, then let the user refine it through further requests. SAP describes access through web, desktop, mobile, and voice. Herzig says he uses the system to gather engineering updates before meeting teams, helping him identify changes that deserve discussion or closer attention. The system collects the information behind those conversations, while he retains the judgment about where to intervene. That distinction makes the workflow more specific than a general purpose chat interface: the output can be an assembled workspace that the user continues shaping. Joule Studio addresses the development side of that approach. SAP describes it as a tool for building custom AI agents with enterprise context, including authentication, permissions, and compliance, already available as a starting point. Herzig expects developers to spend more of their effort on architecture, business correctness, and the systems that govern agent behavior. Generating an implementation becomes easier, but deciding what an agent should be allowed to do still requires explicit design. Edge cases, failures, and the consequences of an incorrect action remain engineering responsibilities. In his account, the developer's role expands beyond making an individual feature work to evaluating whether an automated workflow behaves correctly across the organization. Existing enterprise controls become part of the foundation on which those agents are built. SAP's Knowledge Graph tackles a different source of agent errors: misunderstanding what business data actually means. Access to files or database tables does not automatically explain the relationships between records, the rules behind transactions, or the fact that a supplier in procurement is the same organization represented in finance. SAP describes its graph as a machine readable map of business objects, relationships, and rules. Herzig says that context can improve accuracy, reduce incorrect API calls and retries, and help smaller models handle more tasks. He also separates understanding a rule from enforcing it. An agent that correctly interprets a transaction must still act within the user's permissions and the workflow's boundaries, including human approval when required. A fluent answer is only one part of a successful interaction; the resulting action must also satisfy the underlying process. SAP is also building Company Memory to preserve the reasoning behind business decisions. Herzig identifies approved exceptions as particularly valuable records: what happened, why someone allowed it, who had the authority, and what the outcome was. That gives the next person more to work with than a final status or an isolated document. But remembering an exception creates its own challenge. A decision that worked under particular circumstances can become misleading if an agent treats it as a standing policy. Herzig says a human process owner needs to review whether the original conditions still apply and whether the decision can safely be generalized. The proposed memory therefore captures decision context while leaving the authority to establish a broader rule with the responsible person. On operating costs, Herzig says SAP has learned to avoid sending every task to a large language model. An email summary and a complex, multistep business decision do not require the same capabilities. His approach routes work according to complexity, risk, and context, and avoids an LLM call when conventional software can solve the problem. He also points to excessive, low value context as a source of waste. Lower token prices do not guarantee lower total spending when usage spreads throughout a company. SAP says more than sixty thousand colleagues use Joule Work internally, giving it a substantial deployment on which to evaluate those tradeoffs. Herzig argues for keeping models replaceable as costs and quality change, while measuring the reliability of the whole workflow. A cheaper response can still be expensive if it repeatedly fails or needs correction. SAP's tabular AI work applies foundation models to structured business records rather than conversational text. Its SAP RPT models target problems such as payment delay prediction and cash flow forecasting. Herzig suggests beginning with historical invoices, including invoice dates, due dates, actual payment dates, customers, amounts, and relevant contextual attributes. He says a few thousand rows can be enough to begin predicting payment timing and flagging likely delays. SAP RPT 1.6 adds two explanation mechanisms. Explain by Feature identifies variables that influenced a prediction, while Explain by Example presents similar historical records as supporting evidence. Those explanations give a finance controller material to examine when deciding whether the pattern remains applicable. Herzig distinguishes that capability from causal reasoning, which remains a research direction. Predicting that a payment will arrive late does not establish whether changing the payment terms would make it arrive sooner. The current emphasis is on predictions that people can inspect against their own business experience. This has been your AI digest for October 25, 2026. Read more: SAP CTO on AI coding and operating enterprise software Joule Work and personalized Spaces Joule Studio and enterprise agent development SAP Knowledge Graph for business context SAP Company Memory and decision context SAP on model routing and AI operating costs SAP RPT 1.6 and explainable tabular predictions

0:00-7:05

transcript

No transcript — this publisher did not publish one.

show notes

Good day, here's your AI digest for October 25, 2026.

SAP chief technology officer Philipp Herzig is challenging the idea that AI coding tools make enterprise software obsolete. His argument starts with the difference between generating an application and operating a business process. An expense app might be straightforward to create, but running it across forty countries means handling tax rules, permissions, reimbursements, and changing requirements. Herzig says the distance between a convincing prototype and a dependable production system still involves substantial human work. As agents take on more responsibilities, they need trusted data, business context, security, and governance. The interface may change dramatically while those obligations remain. His assessment puts application generation within a larger engineering problem: someone must maintain the dependencies, resolve exceptions, and own the behavior after the demonstration ends.

SAP's Joule Work approaches enterprise software by letting people describe what they want to accomplish. Rather than navigating several applications and assembling information manually, users can ask Joule to bring together the relevant information and capabilities. A feature called Spaces can turn that request into a visual workspace containing charts, tables, or dashboards, then let the user refine it through further requests. SAP describes access through web, desktop, mobile, and voice. Herzig says he uses the system to gather engineering updates before meeting teams, helping him identify changes that deserve discussion or closer attention. The system collects the information behind those conversations, while he retains the judgment about where to intervene. That distinction makes the workflow more specific than a general purpose chat interface: the output can be an assembled workspace that the user continues shaping.

Joule Studio addresses the development side of that approach. SAP describes it as a tool for building custom AI agents with enterprise context, including authentication, permissions, and compliance, already available as a starting point. Herzig expects developers to spend more of their effort on architecture, business correctness, and the systems that govern agent behavior. Generating an implementation becomes easier, but deciding what an agent should be allowed to do still requires explicit design. Edge cases, failures, and the consequences of an incorrect action remain engineering responsibilities. In his account, the developer's role expands beyond making an individual feature work to evaluating whether an automated workflow behaves correctly across the organization. Existing enterprise controls become part of the foundation on which those agents are built.

SAP's Knowledge Graph tackles a different source of agent errors: misunderstanding what business data actually means. Access to files or database tables does not automatically explain the relationships between records, the rules behind transactions, or the fact that a supplier in procurement is the same organization represented in finance. SAP describes its graph as a machine readable map of business objects, relationships, and rules. Herzig says that context can improve accuracy, reduce incorrect API calls and retries, and help smaller models handle more tasks. He also separates understanding a rule from enforcing it. An agent that correctly interprets a transaction must still act within the user's permissions and the workflow's boundaries, including human approval when required. A fluent answer is only one part of a successful interaction; the resulting action must also satisfy the underlying process.

SAP is also building Company Memory to preserve the reasoning behind business decisions. Herzig identifies approved exceptions as particularly valuable records: what happened, why someone allowed it, who had the authority, and what the outcome was. That gives the next person more to work with than a final status or an isolated document. But remembering an exception creates its own challenge. A decision that worked under particular circumstances can become misleading if an agent treats it as a standing policy. Herzig says a human process owner needs to review whether the original conditions still apply and whether the decision can safely be generalized. The proposed memory therefore captures decision context while leaving the authority to establish a broader rule with the responsible person.

On operating costs, Herzig says SAP has learned to avoid sending every task to a large language model. An email summary and a complex, multistep business decision do not require the same capabilities. His approach routes work according to complexity, risk, and context, and avoids an LLM call when conventional software can solve the problem. He also points to excessive, low value context as a source of waste. Lower token prices do not guarantee lower total spending when usage spreads throughout a company. SAP says more than sixty thousand colleagues use Joule Work internally, giving it a substantial deployment on which to evaluate those tradeoffs. Herzig argues for keeping models replaceable as costs and quality change, while measuring the reliability of the whole workflow. A cheaper response can still be expensive if it repeatedly fails or needs correction.

SAP's tabular AI work applies foundation models to structured business records rather than conversational text. Its SAP RPT models target problems such as payment delay prediction and cash flow forecasting. Herzig suggests beginning with historical invoices, including invoice dates, due dates, actual payment dates, customers, amounts, and relevant contextual attributes. He says a few thousand rows can be enough to begin predicting payment timing and flagging likely delays. SAP RPT 1.6 adds two explanation mechanisms. Explain by Feature identifies variables that influenced a prediction, while Explain by Example presents similar historical records as supporting evidence. Those explanations give a finance controller material to examine when deciding whether the pattern remains applicable. Herzig distinguishes that capability from causal reasoning, which remains a research direction. Predicting that a payment will arrive late does not establish whether changing the payment terms would make it arrive sooner. The current emphasis is on predictions that people can inspect against their own business experience.

This has been your AI digest for October 25, 2026.

Read more:

links3

more episodes

All episodes