Agentic commerce

I sent an AI agent shopping at 50 Indian D2C stores. 88% wouldn't let it buy.

Essay · ARI launch report · 7 min read
Project notes This piece belongs to the Agent Readiness Index build — see the whole project →

There’s a version of online shopping arriving faster than most storefronts realise. You won’t browse the store — your assistant will. You’ll say “find me a sulphate-free shampoo under ₹600 and order it,” and something will go do that: open a browser, search, compare, add to cart, check out.

The plumbing for that future is being laid right now. In the past year OpenAI shipped a protocol for agents to check out inside ChatGPT, Google shipped one for agent payments, Visa shipped one for verifying trusted agents. And NPCI is reportedly building agent authorisation directly into UPI. The money side of agentic commerce is close to solved.

So I went looking for the other side of the problem. When an AI agent actually walks into an Indian D2C store and tries to buy something — not in a demo, on the real live site — what happens?

I built a benchmark to find out, and gave every store a single 0–100 number for it: its Agent Readiness Index, or ARI. High ARI, an agent can buy from you. Low ARI, it can’t get through. Most stores score a D or an F.

The ARI journey funnel: 43 ranked stores entering six checkpoints, narrowing to just 5 that reach a payment screen

The setup

One AI agent — an open-weight model driving a real Chromium browser, with no store-specific code, no hardcoded shortcuts, seeing each page the way a person would. Each store got a mission that fit what it sells — “buy an organic face serum under ₹1,200” at Juicy Chemistry, “a pack of muesli under ₹600” at Yogabar, “a memory-foam pillow under ₹1,500” at Wakefit — and the agent ran it at least three times.

Then I set one hard rule: it stops the instant it reaches a payment screen. It never pays, never enters card details, never solves a CAPTCHA, never tries to sneak past a bot-block. The question isn’t “can a bot brute-force a checkout” — it’s “does an honest agent, behaving well, even get the chance to buy?”

Every journey is scored across six checkpoints: find the product → open the product page → add to cart → reach checkout → fill the delivery form → arrive at payment.

The result: a cliff

Of 43 ranked stores, here’s how far the agent got:

  • Found the product: 36
  • Opened the product page: 30
  • Added to cart: 17
  • Reached checkout: 9
  • Filled the delivery form: 6
  • Reached a payment screen: 5

Five. 11.6%. For the other 88%, a buyer with money and clear intent simply… leaves.

The top of the ARI leaderboard: the five green stores that let an agent through, and XYXX's red OTP wall at #7

You can see the whole ranking on the site, and I’d rather you explore it than take my word for it — pick a brand you shop from and see how it did. But two findings are worth pulling out here, because they surprised me and they’re the opposite of the common advice.

Surprise 1: the wall is the cart, not the checkout

Everyone assumes agents die at the OTP-guarded checkout. They mostly don’t get that far. The single biggest drop was product page → cart: of 30 stores whose product page the agent could reach, only 17 survived “add it to the cart.” Variant pickers that look like dropdowns but aren’t real inputs. Add-to-cart buttons that flash and do nothing. Carts that throw errors. The least glamorous part of your funnel is quietly the most hostile to a machine.

Surprise 2: perfect “AI-ready” markup predicts almost nothing

There’s a small industry telling stores to get “AI-ready” by adding structured data — JSON-LD, schema.org, llms.txt. Indian D2C is already good at this; most Shopify stores score a perfect 100 on machine-readability.

So I scored every store twice: once on that structured data, once by actually sending the agent. The correlation between the two was r² = 0.027 — under 3%.

The cleanest illustration is a store called XYXX:

XYXX's scorecard: a perfect 100/100 static machine-readability score beside a journey that dies at checkout on an OTP wall

Flawless 100/100 on structured data. The agent finds the product, picks a size, builds a cart — and then dies at checkout, blocked by a phone OTP it has no way to receive. Perfectly readable. Completely unusable. Meanwhile two stores that a crawler can barely parse (structured-data scores of 40 and 20) let the agent walk untouched all the way to payment.

Markup tells an agent what you sell. It cannot pick a size, close your popup, or get past your OTP form. The only way to know if an agent can buy from your store is to send one. That’s why the live journey is 70% of the score and the markup is only 30%.

The walls are choices

OTP-only checkout was the most common wall — and in a manual walk of ten stores, not one offered guest checkout. That’s not a bug; it’s a decision. Same with forced logins, aggressive bot-blocking, popups that never close. Every one of them is a policy a store chose, which is the good news: policies can be un-chosen. The stores that let the agent through didn’t share a platform or a checkout stack — they shared working search, product options that are real form controls, a cart that behaves, and nothing between cart and payment that demands a phone-bound human.

If you run a store, in order of leverage

  1. Walk your own funnel like a machine. Kill JavaScript animations, ignore hover states; if a step needs a mouse-hover, a pixel-perfect click, or an SMS code, an agent dies there.
  2. Un-wall the cart. Real <select>/radio variant inputs, an add-to-cart that visibly confirms, a cart page that loads. This is the biggest killer in the data.
  3. Offer guest checkout. OTP-only entry is the #1 wall — and agents (and plenty of humans) can’t receive your SMS.
  4. Keep your structured data — it’s still how agents find and trust products — but stop believing it’s the whole job.
  5. Test before the rails arrive. ACP, AP2, TAP, UAP all standardise payment. Every one of them assumes the agent already reached checkout. That last mile is yours. (More on why this holds even as stores go “agent-native”: ari.niratpatel.com/why-now.)

One thing about the method

I’m not selling anything, and I don’t think my agent is a genius. In fact 60% of its runs were failures on its side — it got confused, misclicked, gave up — and every one of those was thrown out and never counted against a store. Publishing your own failure rate is the cheapest honesty there is, and a benchmark that hides it isn’t a benchmark. Findings are only published when at least two of three runs reproduce them; seven stores where nothing conclusive happened are left unranked rather than guessed at. The whole thing ran on open-weight models for under ₹800 in total compute — cheap enough that I’ll happily re-run any store that thinks I got it wrong, in public.

How it’s built

For the builders who want the machinery. The agent is an open-weight model driving real Chromium through Playwright — no store-specific code. Each live page is distilled from the DOM into a compact text view the model can act on, so it sees a size selector the way you’d describe it over the phone, not as a thousand lines of markup.

A few engineering decisions did most of the work:

  • Two models, split by job. A larger driver model makes the journey decisions; a small, cheap classifier tags each failure — rules first, keywords second, LLM only as the last resort. Most classifications never touch a model at all, and when they do, the classifier costs about a cent per run.
  • Determinism where it matters. The stop-before-payment rule is enforced in code as a DOM check, not by asking the model nicely. Same for politeness: at most 3 runs per store, at least 60 seconds apart, public pages only.
  • A frozen, versioned rubric. The 0–100 scoring rubric was calibrated against a 10-store manual ground-truth walk, then frozen as v1. Any future change to a weight or deduction bumps the version, so scores stay comparable over time.

The whole benchmark cost $9.31. Not per store — total. 183 recorded agent journeys across 50 stores, every re-run, requeue and validation run included: roughly five cents a journey, against a $300 budget that never came close to mattering. Cost telemetry on every single LLM call is what makes that number knowable at all — and it’s the part I’d underline for anyone building evals. When a full re-audit costs less than lunch, you can afford to re-run any store that disputes its score, in public, and honesty stops being expensive.

Two things the data taught me beyond the headline:

Indian D2C is more concentrated than it looks. Before the agent ever ran, a static crawl fingerprinted every store: 36 of the 50 are on Shopify, and a single checkout enabler — GoKwik — fronts 25 of them. That concentration cuts both ways. Today it means the same walls repeat across half the market; tomorrow it means a handful of platform and checkout vendors could move most of Indian D2C’s agent-readiness in a single release cycle.

Benchmarks earn trust in boring places. The original store list pointed at boult.com — which turned out to belong to a UK law firm, not the audio brand. The audit caught it, the entry was corrected to the brand’s real domain and re-run from scratch, and the wasted runs were archived rather than counted. None of that shows up on the leaderboard, which is exactly the point: the invisible corrections are what make the visible numbers worth quoting.

There are 1,025 tests behind the pipeline, and the leaderboard itself is a static site — no backend to drift while the data stands still.

Look up any store’s ARI — its full scorecard, the exact point the agent stopped, the evidence, and its two highest-leverage fixes.

Explore the full index → ari.niratpatel.com

I’m Nirat — I build at the intersection of AI and product. This is one of the things I make; more at niratpatel.com. If a store looks mis-scored, tell me — I’ll re-run it, and corrections are public.