SAP says its Q2 2026 Customer Experience release introduces a model context protocol server for SAP Commerce Cloud. Approved AI agents can query product information, check inventory, manage shopping carts and complete transactions through conversational interfaces.
The important architectural change is not conversational shopping. It is that a model can now reach a transaction surface. Once an agent can alter a cart or complete a transaction, the control boundary moves from the text it generates to the tool call that SAP Commerce Cloud accepts.
An MCP server is a capability surface
MCP standardizes how an agent discovers and invokes tools. It does not decide which business actions should be available to a particular customer, channel or conversation. It also does not remove the need for SAP Commerce Cloud authorization, transaction rules, logging or recovery.
The practical design question is therefore precise: which capabilities can this agent invoke, for which identity, under which conditions, and what evidence must exist before and after execution?
Do not give every commerce action the same authority
Product lookup, cart modification and transaction completion have different consequences. Treating them as equivalent because they are exposed through the same protocol creates an oversized permission boundary.
- Read operations can return product descriptions, prices and inventory information. They can still expose restricted catalogs, customer-specific pricing or location data, so the query must run inside the correct customer and market context.
- Reversible mutations add, remove or change cart items. They alter business state but can normally be corrected before commitment. The agent should be limited to the active cart and should not be able to modify unrelated customer objects.
- Commitment operations complete a transaction or create an order. These actions can trigger inventory allocation, fulfillment, taxation, payment processes or customer communications. They need stronger confirmation, duplicate prevention and recovery controls.
A useful tool catalog makes these differences visible. A read-only shopping assistant should not receive checkout capability simply because the underlying MCP server supports it. Capability exposure should be the smallest set needed for the agent’s approved purpose.
Identity must survive the handoff from conversation to transaction
A shared technical user can make the integration work while destroying accountability. Commerce Cloud may see one service identity even though thousands of customers interact with the agent. The execution record must preserve both levels: the technical principal that invoked the tool and the customer or delegated business identity on whose behalf the action occurred.
The authorization context should be resolved at execution time. A customer authenticated earlier in a long conversation may have signed out, changed account, lost entitlement or switched channel. The agent’s memory of identity is not authorization evidence.
For every state-changing call, retain the customer or account identity, agent identity, tool name and version, granted scope, authorization decision and the conversation request that led to the action. Sensitive conversational data should not be copied into the audit record unless it is required for the decision.
Revalidate price, stock and cart state immediately before commitment
A model can describe a product accurately and still act on stale commercial facts. Inventory can change between the first query and checkout. Promotions can expire. Customer-specific pricing can be recalculated. Another browser session can alter the same cart.
The agent should therefore treat earlier tool responses as context, not as a final quote. Before a commitment operation, retrieve the current cart and recalculate the facts that matter: items, quantities, price, discounts, taxes, delivery terms and availability. If a material value differs from what the customer approved, stop and present the new state for confirmation.
This is where many conversational designs fail. They ask “Would you like me to place the order?” before the system has produced the final transaction state. The approval then attaches to a narrative summary, not to the cart that is actually submitted.
Bind approval to the exact cart version
A meaningful approval should identify the transaction object it authorizes. At minimum, bind it to the customer, cart identifier, cart version or equivalent state marker, final amount, currency and delivery choice. If any bound value changes, the approval is no longer valid.
Keep approval separate from execution. The system should record when the customer approved the final state and when the MCP tool submitted it. This makes it possible to distinguish an approved transaction that failed from an unapproved transaction that succeeded.
Retries must not create a second transaction
Conversational systems retry for many reasons. A model may repeat a tool call after a timeout. An orchestration layer may retry a failed request. A customer may say “try again” because the chat did not display the response. The first call may already have created the order even when the agent never received the confirmation.
Every commitment attempt needs a stable idempotency key or equivalent duplicate-control mechanism linked to the intended business action. A retry with the same key should return the original result or a definitive current status. It should not create another order.
The record should also distinguish transport retry, tool retry and customer-initiated retry. They may look identical at the API boundary, but they represent different intentions and may require different handling.
A transcript is not a sufficient audit trail
A chat transcript shows words. It may not show the exact tool schema, normalized input, authorization context or SAP transaction result. For a state-changing action, preserve a structured execution record containing:
- agent, model or orchestration identity and deployed version
- MCP server and tool name, version and permitted scope
- customer or delegated business identity
- normalized tool input or a protected hash when the input is sensitive
- cart identifier and pre-execution state marker
- policy and authorization result
- approval linked to the final transaction state
- idempotency key and attempt number
- Commerce Cloud response, transaction identifier and final status
- failure, compensation or recovery action when execution is incomplete
This record should be queryable independently from the conversation platform. If the chat history expires or a model provider changes, the transaction evidence must remain understandable.
“Rollback” means different things before and after checkout
Removing an item from a cart can be a direct inverse action. Reversing a completed transaction is rarely equivalent. An order may already have triggered fulfillment, tax determination, payment activity or customer communication. Recovery after commitment usually requires a business cancellation or compensation process with its own authorization and status.
The agent should know which actions are safely reversible, which require a separate business process and which cannot be reversed automatically. A generic rollback button is not a control model.
Test the failures that normal demos avoid
A successful product search and checkout demo proves only the happy path. Before enabling transactional use, test the cases that challenge authority and state:
- inventory changes after the agent recommends an item
- price or promotion changes before final approval
- the customer modifies the same cart in another session
- authorization expires between read and write operations
- the customer request is ambiguous about quantity or variant
- the order is created but the tool response times out
- the orchestration layer repeats the same commitment call
- a restricted catalog or customer-specific price is queried by the wrong identity
- cancellation is requested after downstream fulfillment has started
Each test should prove both business behavior and evidence quality. The system must prevent the wrong action, explain the decision to the customer when appropriate, and leave enough structured evidence for investigation.
The safe boundary is narrower than the protocol
SAP Commerce Cloud’s MCP server can make conversational commerce far more useful because agents can act instead of merely recommend. That same capability makes permission design, current-state validation, duplicate control and recovery part of the customer experience.
The secure design is not “give the agent access to Commerce Cloud.” It is to expose a deliberately limited set of tools, carry the correct identity into every call, revalidate the transaction at commitment time, bind approval to the exact state, and preserve execution evidence outside the chat transcript.
Source: SAP Customer Experience Q2 2026 release overview. The control recommendations in this article are architectural analysis, not SAP product configuration guidance.