A customer may have a governed purchase order data product and ask whether it can be used to build an agent. My answer would be to look first at what the agent is expected to do. Imagine an agent helping a procurement team with delayed orders. A user asks why an order is late and what should happen next.
Figure: The five readiness checks for a purchase order data product.
Five checks before the agent uses it
First, define the business meaning. Does late refer to the original delivery date or the latest confirmed date? Is a partially delivered item late? Which status is authoritative? These questions sound basic until an agent has to explain an exception without a buyer beside it.
Second, map the context. The answer may depend on the supplier, contract, goods receipt and current delivery commitment. If that commitment is in an inaccessible email, the agent should say its information is incomplete.
Third, check trust. When were the records updated? Are the fields complete? Can we trace the figures to their source? An unposted goods receipt can make the order look late even when the goods have arrived.
Fourth, test access end to end. A buyer may see only orders within a purchasing organization. The agent’s data access and every tool call must respect the relevant scope. SAP Datasphere data access controls can help restrict rows in protected objects, but the complete path still needs to be tested.
Fifth, define the action. Explaining a delay, recommending a supplier call, creating a task and changing a purchase order have different consequences. The right to read an order is not the right to change it.
A useful starting outcome
I would start with an agent that explains the exception, shows its evidence and points out missing information. Procurement users can then assess whether the result is dependable. Once that works, the business can define which follow-up actions are appropriate and where approval belongs.
The architecture question is not simply whether a data product exists. It is whether the data product and its surrounding context are fit for the exact decision and level of autonomy we expect.
For the purchase order pilot, I would ask the buyer to walk through two real exceptions. One should have complete records; the other should include a missing or conflicting commitment. Those cases show whether the agent can explain uncertainty rather than turn an incomplete picture into a confident instruction.
The same review should include the user experience. If an agent lacks the contract, it should tell the buyer what it checked and suggest who can confirm the commitment. That response is still useful. It respects the limit of the available information and helps the person complete the work.
Agent Ready Data Series01 From AI Ready Data to Agent Ready Data02 Is a Data Product Ready for an AI AgentA customer may have a governed purchase order data product and ask whether it can be used to build an agent. My answer would be to look first at what the agent is expected to do. Imagine an agent helping a procurement team with delayed orders. A user asks why an order is late and what should happen next. Figure: The five readiness checks for a purchase order data product.Five checks before the agent uses itFirst, define the business meaning. Does late refer to the original delivery date or the latest confirmed date? Is a partially delivered item late? Which status is authoritative? These questions sound basic until an agent has to explain an exception without a buyer beside it.Second, map the context. The answer may depend on the supplier, contract, goods receipt and current delivery commitment. If that commitment is in an inaccessible email, the agent should say its information is incomplete.Third, check trust. When were the records updated? Are the fields complete? Can we trace the figures to their source? An unposted goods receipt can make the order look late even when the goods have arrived.Fourth, test access end to end. A buyer may see only orders within a purchasing organization. The agent’s data access and every tool call must respect the relevant scope. SAP Datasphere data access controls can help restrict rows in protected objects, but the complete path still needs to be tested.Fifth, define the action. Explaining a delay, recommending a supplier call, creating a task and changing a purchase order have different consequences. The right to read an order is not the right to change it.A useful starting outcomeI would start with an agent that explains the exception, shows its evidence and points out missing information. Procurement users can then assess whether the result is dependable. Once that works, the business can define which follow-up actions are appropriate and where approval belongs.The architecture question is not simply whether a data product exists. It is whether the data product and its surrounding context are fit for the exact decision and level of autonomy we expect.For the purchase order pilot, I would ask the buyer to walk through two real exceptions. One should have complete records; the other should include a missing or conflicting commitment. Those cases show whether the agent can explain uncertainty rather than turn an incomplete picture into a confident instruction.The same review should include the user experience. If an agent lacks the contract, it should tell the buyer what it checked and suggest who can confirm the commitment. That response is still useful. It respects the limit of the available information and helps the person complete the work.Further reading: SAP Help, Working with Data Products • SAP Help, Securing Data with Data Access Controls • SAP Architecture Center, AI-native North Star architectureWhat to read nextTopicWhy read itLink to readBDC data productsLearn how governed products are found and used in SAP BDC.Open resourceData access controlsReview row-level protection for SAP Datasphere consumers.Open resourceSAP architecture visionSee SAP’s target direction and its stated scope as a vision.Open resource Read More Technology Blog Posts by SAP articles
