An AI shopping assistant can already turn a request such as “find a waterproof commuter jacket under $250 and deliver it by Friday” into a shortlist. Agentic commerce begins when the system can go further: select the right variant, confirm the final cost, obtain permission and complete the purchase.
That changes the transaction boundary. Your storefront is no longer serving only people who can interpret missing details, notice an outdated price or ask a support agent for help. It is also serving software that needs precise facts and enforceable rules. A polished interface alone is not enough. The underlying ecommerce platform and integrations must be readable, current and governable.
Agentic commerce is a systems-readiness test
Current protocols are converging on a common idea: an agent should be able to discover products, prove who it represents and transact within explicit authority. Shopify’s agentic commerce guidance already describes catalogue search that returns product titles, images and variant details for an agent to act on. Visa’s Trusted Agent Protocol separates product browsing from payment and gives merchants a way to verify trusted commerce intent.
For a merchant, readiness depends on six connected foundations. Weakness in any one of them can turn a convenient journey into the wrong recommendation, a failed order or an unauthorized transaction.
1. Make product information decision-grade
An agent can recommend only what your catalogue can state clearly. Every sellable item needs a stable identifier, a parent-product relationship, accurate attributes and an unambiguous variant. Size, colour, material, compatibility, delivery restrictions, warranty terms and return rules should be fields, not clues buried in prose or images.
Google’s product variant documentation requires unique identifiers for variants and product groups and provides structured relationships such as hasVariant and variesBy. That is a useful minimum mental model even when an agent reads an API instead of page markup.
Start with the attributes that determine suitability and eligibility. A strong catalogue for retail technology records where each fact came from, who owns it and when it was last validated. If the product information system, website and marketplace feed disagree, the agent needs one authoritative answer.
2. Treat price and inventory as live promises
Availability cannot be a nightly export if an agent is about to spend money. Expose current price, currency, promotion conditions, quantity, location, fulfilment method and delivery estimate through an authenticated API. Include a freshness timestamp and a clear outcome for unknown data.
The API should distinguish “in stock” from “available to promise.” Shopify’s store availability model, for example, separates quantity on hand from availability that may depend on transfers or overselling rules. Your checkout flow should also revalidate price and stock, then reserve inventory atomically so two agents cannot buy the same last unit.
3. Verify the agent and preserve customer intent
Ordinary bot controls are designed to block automation. Agentic commerce requires a more precise decision: allow a recognized shopping agent while rejecting scrapers, scalpers and attackers.
Use signed, time-limited credentials rather than a user-agent string or an IP allow-list. Validate the agent provider, intended merchant, request purpose, expiry and replay protection at the edge or API gateway. Then link that identity to evidence of what the customer authorized.
Google’s Agent Payments Protocol describes signed intent and cart mandates that preserve the path from a user’s request to the exact items and price approved. Whether you adopt that protocol or another, retain equivalent evidence in an audit trail.
4. Turn payment permission into policy
Giving an agent access to a saved card is not the same as authorizing a purchase. Permission should be narrow enough for software to enforce: maximum amount, currency, merchant, product category, quantity, time window, delivery address, recurrence and whether substitutions are allowed.
Use tokenized credentials so the agent never handles raw card details. Stripe’s Shared Payment Tokens are designed to carry a buyer’s permission without exposing the underlying credential, while allowing controls and risk checks to be applied during the payment.
Require fresh approval when the cart moves outside the mandate. A $20 price increase, a replacement product or a different delivery date is a new decision, not a harmless optimization.
5. Adapt fraud controls to authorized automation
A trusted agent is not automatically a safe transaction. Keep velocity limits, account-takeover detection, payment risk scoring and inventory-abuse controls, but add agent-specific signals: verified provider, signed intent, mandate match, request sequence and transaction history.
Log the agent, customer authority, catalogue version, quoted price, inventory response, payment token and outcome under one trace ID. That record supports fraud analysis, customer service and disputes. A focused cybersecurity assessment can expose gaps between the commerce API, identity layer and payment flow before attackers find them.
6. Design human escalation before the edge case
Automation should stop cleanly when confidence or authority runs out. Route a decision to a person when:
- the requested product is unavailable and a substitution changes a key attribute;
- the final price, tax, shipping charge or delivery date exceeds the approved range;
- identity or payment checks conflict;
- a regulated, age-restricted or high-value product needs review;
- risk signals cross a defined threshold; or
- the agent cannot explain why a recommendation satisfies the request.
The handoff should include the request, proposed cart, reason for escalation and actions already taken. OWASP’s guidance on excessive agency recommends least privilege and human approval before high-impact actions. In commerce, the approval screen is part of the control system, not an admission that automation failed.
A practical agentic commerce readiness test
Before allowing an agent to buy, confirm that your team can answer yes to these questions:
- Can an API return one authoritative record for every product and variant?
- Can the agent verify price, stock, fulfilment and delivery immediately before checkout?
- Can you distinguish a trusted agent from an ordinary or malicious bot?
- Can you prove what the customer asked for and approved?
- Can payment authority be limited and revoked without exposing card data?
- Can fraud systems evaluate agent context without weakening existing controls?
- Can a person review and resume an exception without restarting the journey?
Do not begin with autonomous purchasing across the entire catalogue. Choose one product family, one fulfilment path and one payment method. Build a test harness for stale inventory, altered prices, duplicate requests, invalid signatures, rejected payments and unavailable substitutions. Measure recommendation accuracy, checkout success, escalation rate, fraud outcomes and support effort.
A controlled pilot built with experienced AI development specialists will reveal whether the limiting factor is the model, the catalogue or the commerce architecture. In most businesses, the hard work is not making an agent sound helpful. It is making every action verifiable, bounded and recoverable.
Ready to assess your commerce stack and design a safe agent-assisted buying journey? Talk to 247 Labs.
