An AI answer engine may recommend the right product. An agent that acts for the shopper may then ask a merchant system to reserve it or place an order. Those are different capabilities. Product pages can be readable by many systems; purchase actions require current stock, the customer's explicit choice, a valid payment boundary and a durable order record.
Separate discovery from commitment
The discovery layer answers questions about fit, specifications, availability and terms. It should cite current product data and distinguish a general claim from a live offer. The transaction layer changes state: it may reserve stock, create a basket, apply a promotion, charge a customer or submit an order. Give each action its own permission and confirmation requirement rather than one broad “shop on my behalf” switch.
Methodfield's AI search guide covers the product truth needed for accurate recommendation. The next boundary is whether that truth remains current when an order is placed. A cached answer can be useful for research; it is a poor authority for stock or final price.
Verify the final offer
Before commitment, check SKU and variant, country availability, quantity, current price, tax and delivery terms, address eligibility, promotion validity and any age or other product restriction relevant to the store. Show the customer the final item and total, including material conditions, and obtain confirmation through an authorised interface. Do not infer consent from the earlier request to compare products.
The order action should run through the merchant's normal API. Keep payment credentials and authorisation inside the approved checkout or payment service, outside the model's context. Use a stable idempotency key so an interrupted agent can query status before retrying. Store the returned order ID and receipt. If the API fails after a possible partial completion, do not ask the model whether the order “probably went through”; ask the order system.
A worked boundary
A shopper asks an agent to find a compact coffee machine under a budget. The agent compares products using readable catalogue data. When the shopper selects a particular colour, the merchant system reports that this variant is out of stock in the delivery country. The agent can suggest another variant; it cannot substitute one silently. If the price changes before checkout, show the new total and ask again. The scenario illustrates the decision path, not a live commerce integration.
Test failure and recovery
Include stock changing between recommendation and checkout, duplicate order submission, an expired promotion, a wrong address, a payment rejection and a cancellation request. For each, define what the customer sees, what state the merchant retains, whether inventory is released and who owns the correction. A human service path should receive the product, price, order state, actions attempted and reason for transfer.
Measure verified orders, wrong variants, corrected orders, cancellations, payment failures, customer disputes and the time needed to resolve them. An increase in agent-initiated baskets is not yet an increase in completed, satisfactory purchases.
Launch by authority level
Begin with read-only product lookup. Next permit a draft basket that the shopper reviews. Enable stock reservation or order submission only after the merchant has tested identity, confirmation, idempotency, policy and recovery on representative cases. Payment authority deserves its own decision and approval path.
This is a continuation of Methodfield's AI Search for European Ecommerce, which ends by identifying agent-mediated transactions as a separate next step. The agent-authority guide supplies the general permission model used here.
Working artifact: the order-state record
Make each change of merchant state visible to the customer and to support staff.
| State | Evidence and permitted next action |
|---|---|
| Recommendation | Product source and time; read-only comparison |
| Live quote | SKU, variant, stock, price, delivery terms and expiry |
| Customer approval | Final basket and total shown; explicit authorised confirmation |
| Execution | Scoped order request, idempotency key and payment-service result |
| Reconciliation | Returned order ID, receipt, inventory state and correction owner |
An unknown execution result is its own state. Query the merchant and payment systems before retrying or telling the shopper that the order failed. When price or variant changes, return to customer approval instead of continuing with an earlier consent.
Sources and scope
Payment, consumer, data-protection and platform requirements must be checked for the actual merchant and market before implementation.