A shopper asks an AI assistant: “Find me black ankle boots in size 8, under $150.”
Your brand has exactly the right product. The price is competitive. The photography is excellent. Your mobile checkout has been tuned for years.
None of that guarantees the assistant can find the right variant, confirm it will ship, explain the return policy, and prepare a checkout without guessing.
Your website was built for a person. Increasingly, a second visitor arrives on that person's behalf: a shopping agent. How well your store serves that visitor is its agentic experience, and it needs to be tested as deliberately as your user experience.
UCP testing is how you find out whether your brand is ready for it.
User experience and agentic experience are different jobs
User experience (UX) asks: is it easy and persuasive for a person to buy here?
Agentic experience (AX) asks: can software acting for a person find the right product, verify the offer, and hand off a purchase without guessing?
The two overlap, but they reward different things:
| User experience | Agentic experience | |
|---|---|---|
| Who reads it | A person scanning pages | An agent reading structured responses |
| What wins | Design, photography, persuasion, speed | Complete, consistent, explicit facts |
| Ambiguity | A person infers, asks support, or forgives a brand they like | An agent qualifies its answer, asks the user, or picks a merchant it can verify |
| Price | Shown on the page | Item price, estimate and confirmed total kept apart; unknown stays unknown |
| Policies | A readable page | Terms an agent can extract and compare: window, fee, exclusions |
| Failure looks like | Abandonment you can see in analytics | A recommendation that never happens, which you never see |
| Measured by | Conversion rate, bounce, time to checkout | Task completion, steps to handoff, agreement between channels |
A brand can have excellent UX and poor AX. A holiday return banner persuades a person; an agent reading a policy page that does not mention it cannot use it. A delivery promise that appears after you type a ZIP code reassures a person; an agent that never sees a shipping method cannot quote a delivered price.
AX is not a replacement for UX. It is a second journey through the same store, and it fails in different places.
A protocol endpoint is not an agentic experience
The Universal Commerce Protocol (UCP) gives commerce systems a shared way to describe capabilities and exchange shopping information. A merchant can expose product discovery, carts and checkout through a machine-readable interface, so an agent does not have to interpret every button, banner and page layout to help someone shop.
But publishing a UCP endpoint only shows that an interface exists. It does not show that an agent can complete a useful shopping task through it.
The distinction is familiar. A checkout page can load and still lose customers. An API can respond successfully and still return incomplete or misleading information.
“UCP enabled” is an implementation milestone. “An agent can confidently shop here” is a business outcome. Testing is what connects the two.
Why this matters most for D2C brands
Every merchant will face agent-assisted shopping. D2C brands have the most exposed position:
- You are the only source of truth. A marketplace normalizes product data, shipping and returns into fields it controls. A D2C brand's catalog, delivery promise and policies come straight from its own systems, so every gap reaches the agent unfiltered.
- Your advantages live in the details agents check. Free returns, a longer holiday window, two-day delivery: these are reasons to choose you over a reseller. If an agent cannot verify them, they stop counting.
- Brand affinity does not transfer automatically. A loyal customer forgives a clumsy search. An agent comparing three merchants for the same boots ranks on what it can confirm, not on how the site feels.
- The loss is invisible. When an agent passes over your store, nothing shows up in your funnel. There is no bounce, no abandoned cart, no session recording. Testing is the only way to see it.
- Fixing it now is cheaper. The gaps are mostly data and consistency problems. They are easier to fix before agent traffic is a meaningful share of revenue than after.
Two routes to the same purchase: what we tested
We tested Steve Madden through two paths, its UCP interface and its regular storefront, with the same brief: women's black ankle boots, US size 8, under $150, delivering to ZIP 10001.
Read the full Steve Madden UCP test report for the step-by-step results and evidence.
The question was not whether an agent could buy without permission. It was whether it could identify the right product, prepare a cart and reach the point where the customer takes over. We entered no personal or payment details and placed no order.
Path 1: shopping through UCP, without a browser
The protocol route used direct requests rather than clicking through pages:
- Discover the merchant's capabilities. We requested the UCP manifest on both the apex and www domains. Both returned the same protocol version and a declared MCP service endpoint.
- Inspect the tools and negotiate capabilities. Our first agent profile declared cart and checkout capabilities but not catalog, and a catalog search returned “Tool not found.” A profile that declared catalog support fixed it.
- Search from the brief. A query for “women black ankle boots,” filtered to available products at $150 or less, returned ten results. We chose KIMMENS BLACK because its description identified it as an ankle boot.
- Verify the exact variant. A product lookup with black and size 8 selected confirmed the variant ID, a $71.97 price and availability.
- Create a one-item cart. The cart held the selected variant at the expected price. It returned policy links but no fulfillment methods.
- Create a checkout and stop at handoff. The checkout returned
requires_escalation, asking for a contact method, an extension interaction and a delivery address, with a continuation URL for the shopper.
Result: the UCP path reached checkout handoff, but shipping cost, delivery timing and the final delivered total were still unresolved.
The profile issue matters for anyone running these tests: not every failed request is a merchant defect. Some failures come from what the agent declares it supports. A good readiness test identifies the cause instead of counting every error against the store.
Path 2: shopping through the regular website
The browser route approached the storefront as a shopper would:
- Search for the product. Searching for “kimmens black” did not surface the product in the results we saw, so we opened the product URL directly. That kept the test moving, but it means the site's own search did not complete the discovery step.
- Select size 8 and add to cart. The product page showed the same $71.97 price and allowed size 8. No login wall, CAPTCHA or consent popup blocked the path.
- Inspect the cart. The browser session already held an item, so after adding the product the cart had two identical size 8 lines at a $143.94 subtotal. One line showed a back-order notice with an expected shipment date that had already passed; the other did not.
- Check delivery for ZIP 10001. The delivery widget accepted the ZIP but showed no shipping cost or tax. It advertised “Get it by Tue, Nov 10” with “Choose Two Day at Checkout,” which is a promise, not a confirmed shipping method.
- Read the return terms. The product page showed a holiday return window alongside standard 30-day language and a $6.95 return fee.
- Proceed to checkout and stop. Checkout asked for contact and delivery details. The ZIP entered in the delivery widget did not carry over, and shipping methods still needed a full address.
Result: the website reached checkout, but only with a direct-URL fallback and a cart that already held an item. Its two-item subtotal cannot be compared directly with the one-item UCP total.
Why the comparison matters more than either path
UCP made product selection and cart creation machine-readable. The website showed more merchandising, delivery and return-policy text. Neither gave everything needed to confirm the delivered offer.
Testing both shows not only whether an agent can move forward, but whether it gets the same account of what the customer is buying.
What the test revealed
Reaching checkout is a real success. It also showed why reaching checkout is not the whole story.
1. “Available” does not always mean ready to ship
UCP reported the size 8 variant as available. In the browser cart, one size 8 line showed a back-order notice with a shipment date already in the past.
One caveat: the session held a pre-existing item, and we could not tell which of the two identical lines was the new one. This warrants a closer look, not a conclusion about current inventory.
It still raises the question every brand should be able to answer: does every channel make the same fulfillment promise? A product that can be bought is not necessarily a product that will arrive in time, and agents need that difference, especially when the shopper has a deadline.
2. Product price is not the delivered price
The UCP checkout showed a $71.97 total, zero tax and no fulfillment methods. The website would not show shipping options without a full address either.
Neither gave a confirmed delivered total, and a ZIP code alone was not enough to get one.
That matters when an assistant compares products against a budget. It has to keep the item price, an estimate and a confirmed total apart. Missing shipping data should stay “unknown,” never turn into “free.”
3. Return policies can tell different stories
The product page showed a holiday return window next to standard 30-day language. The refund policy page linked from UCP described a 30-day window with no holiday extension.
UCP supplied the link, but no structured return window in the responses we inspected.
An agent choosing between similar products may need to compare return fees, deadlines and final-sale exclusions. If that means reconciling pages that disagree, the brand has added doubt at exactly the moment the customer wants reassurance.
Why this matters commercially
These are not just integration bugs. They shape what an assistant can say when it recommends a product.
A person may browse further, contact support, or overlook ambiguity because they like the brand. An agent comparing several merchants is more likely to ask for clarification, hedge its recommendation, or choose an alternative whose offer is easier to verify.
That is a plausible commercial risk, not a measured result. We did not measure sales or abandonment. What the test showed is that the information gaps exist, and that they sit on the path to an agent-assisted purchase.
Product quality and brand affinity still matter. The ability to state a reliable, verifiable offer is now part of competing for the sale.
Make agentic experience part of release testing
Start with a handful of realistic briefs: a bestseller, a constrained size or color, a sale item, and a delivery-sensitive purchase.
Track how often the agent reaches handoff, how many steps it takes, where it needs help, and whether the protocol agrees with the storefront. Repeat after inventory, promotion, policy and checkout changes, the same way you rerun UX checks after a redesign.
Fix the gaps that could make a recommendation wrong before polishing minor friction.
The goal is not to let agents spend money without permission. It is to let them do the useful work before the customer makes the final decision.
Your user experience tells a story about your products. Your agentic experience has to make that story verifiable.
Test your own store
We ran this test with a Pulsar skill. It follows the same shopping brief through your UCP interface and your storefront, stops before any personal or payment details, and writes up what an agent could and could not verify, with the evidence.
Want to see how AI agents experience your store? Email us at [email protected] and we will run it with you.
Evidence base: Steve Madden UCP test report, run on 06/11/2026. This was a bounded, single-product test. It does not establish merchant-wide reliability, sales impact, or readiness across all agent implementations. The browser test used a direct product URL after search failed and started with an item already in the cart, so its discovery result and back-order observation carry those qualifications.
