Why Responsibility for Business Decisions Belongs in the Sourcing Conversation
Enterprises should not buy an agentic SAP system as an upgrade to an unchanged service contract. When AI agents draft requests for supplier bids or update purchasing records, the enterprise is authorizing software to perform defined business tasks. Business owners must set the limits of that authority and agree with their service providers who will intervene when information conflicts or an action produces an incorrect result. The enterprise retains ownership of the business policy.
A provider can meet its application service levels while an automated procurement process produces a poor result. The data may be available, the interfaces working and the software behaving as configured. But if nobody has agreed who checks the supplier information or handles a conflicting instruction, the enterprise still has to resolve it and the consequences for the sourcing decision. Buying more AI capability does not settle that division of work.
This is why the next phase of SAP transformation is a sourcing and management issue. SAP's Q3 2026 releases expanded its role-aware, context-driven AI orchestrators Joule Assistants and specialized agents, with Joule Work becoming available in phases. In October, SAP also announced general availability of inbound Agent2Agent interoperability through its Agent Gateway. Approved external clients can now invoke supported SAP agents. These are useful advances, but connecting the systems leaves the enterprise and its partners with decisions about how the resulting service will run.
The evidence suggests enterprises recognize the distinction. ISG research on agentic AI services finds that technical capabilities are advancing faster than companies are delegating responsibility. ISG finds that 79% of organizations report spending increases across enterprise AI. Asked what they would change in light of experience, companies put governance first. This means companies want to expand AI but need greater confidence in what they are handing over.
The Business Decision Needs an Owner
Consider a hypothetical sourcing process built around SAP Ariba. An expiring contract prompts an agent to prepare a sourcing event using spend history, supplier records and external risk information. The draft is ready quickly. But one supplier record conflicts with the risk feed, and the buyer needs to know whether the event can proceed.
The business must set the rule. It might require the process to pause until a procurement specialist resolves the discrepancy. The provider must then implement that rule, route the exception to someone who can act and retain the information needed to reconstruct the decision. If the process restarts, the approval and the evidence behind it must remain available. An escalation sent to an unattended queue is not a resolved exception.
Decision operations is a concept that describes the discipline of running AI-assisted business decisions across the enterprise and its providers. Its scope is the governed decision loop, from the triggering event and supporting evidence through authorized action and exception handling to the verified business result. It brings business ownership into the same operating model as the software, data and ongoing service, drawing on AI governance and application management.
A clean SAP core remains important: keeping SAP extensions controlled and upgradeable avoids rebuilding yesterday's complexity. It does not, however, tell a procurement director which supplier information is good enough to act on. That judgment has to come from the business and be reflected in the system. A technically sound implementation cannot supply a missing business policy.
The Contract Must Cover the Exception
Before commissioning the Ariba use case, for example, the buyer and provider should agree on a decision contract. This should include a working specification that carries through into service governance and commercial terms, not necessarily a separate legal agreement. It should define the intended outcome, permitted evidence and limits of authority, assign responsibility for exceptions and reversals, and set measures of value and performance. The economics belong there, too: who pays for investigation and rework, and how will the parties establish whether the process is improving?
For the procurement example, this means agreeing when a sourcing event needs human approval, which conflicting records must stop it and who can authorize a restart. The specification also needs to distinguish actions that can be reversed from commitments that cannot simply be undone. These rules must be revisited when a model, data source or business policy changes. Otherwise, a use case approved in a pilot can quietly become a different operating proposition.
This has consequences for sourcing. Prospective providers should work through the same business scenario, including the exception, before comparing their offers. A standard SAP capability, a provider accelerator and a proven production service are different things. Buyers should know which one they are evaluating and what remains their responsibility. An attractive demonstration is a useful starting point; it says little about who will handle a disputed decision six months after go-live.
Measures must follow the same logic. Availability and incident response still matter. Alongside them, an organization should measure elapsed time to an accepted business result, the effort spent resolving exceptions and the cost-per-successfully-completed case. Faster preparation of sourcing events is a poor bargain if procurement subsequently spends more time checking or correcting them. Rewarding automation volume alone would give the provider an incentive to increase activity while leaving the buyer with the consequences.
SAP Partners Need to Carry their Advice into Operations
For service providers, this creates an opportunity to earn a more valuable role. Helping a client decide what it can safely delegate requires process knowledge and the confidence to challenge an unsuitable use case. Operating that decision well requires the implementation team to remain connected to the people who support it. A handover that transfers code but loses the reasoning behind the business rules is inadequate.
The skill mix therefore extends well beyond SAP configuration. Procurement knowledge must be available alongside data engineering and security expertise, with operational staff involved early enough to influence the design. Calling this an integrated team is easy. A stronger proposal shows who resolves a disagreement about supplier data, how that person works with the business owner and how the resulting change is tested.
Responsibility also has to be fair. A provider should not be asked to guarantee outcomes determined by client policies it cannot change or data it does not control. Equally, those dependencies should not become a blanket exclusion from accountability. Making them explicit allows both parties to price the work properly and agree what the provider will actually operate.
The 2026 ISG Provider Lens SAP Ecosystem report for Germany shows why this matters in practice. German buyers are seeking closer links between transformation and operations, with clearer responsibilities and audit evidence. Their sovereignty requirements extend beyond where systems are hosted. Applied to an agentic process, a buyer needs to be able to inspect the decision record, change its policy and retain the evidence when a provider relationship ends. A right to exit has limited practical value if the business cannot continue the process afterward.
Delegate Authority as the Evidence Improves
None of this requires a company to redesign every SAP contract before trying an agent. Orgnaizations should choose a decision that matters enough to improve and has boundaries and exceptions that can be understood. Start with recommendations for people to review. Allow bounded execution once results show that the process is reliable and that someone can intervene effectively. Coordination across several agents can follow where it offers a demonstrable business benefit.
Human approval should not be dismissed as a temporary imperfection on the road to autonomy. For a consequential or unusual decision, retaining it may be the right permanent design. The commercial test is whether the complete process works better, after accounting for supervision and recovery as well as the time saved by automation.
For the next SAP sourcing discussion, enterprises should put a business owner and the prospective provider in front of one specific business decision and ask them to agree how it will be run. Use the answer to shape the scope, the price and the allocation of responsibility.
Agentic ERP will not eliminate accountability. It will reveal whether accountability was designed.
ISG's role is to connect these enterprise requirements with a realistic view of provider capabilities. Our research and sourcing advisory give buyers a basis for testing what is being offered and give providers a clearer understanding of what they need to demonstrate. Using the same decision scenario makes the comparison useful: both parties can see where product functionality ends, where service responsibility begins and what the enterprise must retain. Contact us to find out how we can help you.
About the author
