A shopper in Pune types into Gemini: “pressure cooker, 5 litres, induction-compatible, under ₹3,000, delivered before Saturday.” Gemini compares a few options, picks one, and completes the purchase on Flipkart. The shopper never opens a Flipkart product page. Google is testing that flow in India right now. TechCrunch reported on September 26 that direct Flipkart purchases inside Gemini and AI Mode are in testing, with a wider rollout planned for October, right before the festive season. That’s the moment agentic commerce stops being a conference slide and starts showing up in Indian order volumes.
Our view is simple. If an AI agent can go from “find me something” to “I bought it,” then the customer your store has to satisfy isn’t only a person scrolling a feed any more. It’s also a piece of software reading your data, calling your endpoints and deciding whether you’re worth trusting. Most commerce stacks we see weren’t built with that customer in mind.
Discovery was the easy part. Checkout is where it gets real
AI shopping assistants have been recommending products for a while. That was low stakes: if the model pulled a stale price or misread a spec, a human still clicked through, saw the real page and made the call. Moving checkout inside the assistant takes that safety net away. The agent’s reading of your product becomes the purchase decision.
Flipkart is big enough to negotiate a deep, custom integration with Google. The thousands of D2C brands, regional retailers and quick-commerce players in India aren’t. Once shoppers get used to buying through an assistant this Diwali, the question for everyone else is whether their store can be bought from the same way, whether through Google or through whichever protocol or partner program comes next. We’d expect Gulf retailers to face the same pressure once these flows go beyond India, since that market also runs mostly on mobile and is heavy on marketplaces.
What agentic commerce demands from your catalog
A human can put up with a messy product page. An agent mostly can’t. The failure modes we’d expect first:
- Attributes hiding in free text. “Works on induction” buried in a description paragraph isn’t the same as a structured
compatible_cooktopsfield. If the agent has to guess, it will sometimes guess wrong, or skip you for a competitor whose data is explicit. - Variants that aren’t really modelled. Size, colour and pack quantity stored as separate listings, or as one listing with a dropdown that only exists in the frontend, make it hard for an agent to resolve “the 5-litre steel one” to a single purchasable SKU.
- Prices and stock that drift between systems. If your listing feed, your app and your checkout service each have their own idea of price and availability, an agent will hit the gap. With a human that’s an annoyance. With an agent it’s a failed order, or worse, a completed order you can’t fulfil.
- Delivery promises that aren’t queryable. “Before Saturday” is a hard constraint in the prompt. If your serviceability and ETA logic only runs after the user enters a pincode on a web form, you can’t answer the question the agent is actually asking.
None of this is new. It’s the database design and data-hygiene debt that commerce teams have been putting off for years. Agentic checkout just makes it cost real money.
Checkout APIs and fraud rules built for a human thumb
Look at the backend of a typical Indian commerce app and you’ll often find the checkout “API” is really whatever the Flutter or React Native client happens to call, in the order the screens happen to appear. Session state lives on the client. Coupon logic is split between the app and the server. Error responses are written for a toast message, not for a program that has to decide what to do next.
That setup works when the only caller is your own app. It breaks when the caller is an agent working on someone’s behalf. A checkout that’s ready for agents needs a few things most stacks don’t have yet:
- A stable, versioned REST API for the whole purchase path. That means cart, pricing, serviceability, order creation and payment handoff, with idempotency keys so a retried request doesn’t create two orders.
- Machine-readable errors. “Out of stock at this pincode,” “price changed since quote” and “COD not available” need to be distinct, typed responses the agent can act on.
- Price quotes with an expiry. The agent should be able to lock a price and delivery window for a short time and then confirm it, rather than racing a cart that recalculates on every call.
Then there’s fraud. Most fraud and abuse controls in Indian e-commerce quietly assume a human: device fingerprints, typing and tap patterns, velocity checks tuned to how people browse, OTP steps designed around someone holding a phone. An agent looks like a bot because it is one. If your rules treat every automated caller as hostile, you’ll block legitimate agent orders. If you loosen them without thinking it through, you’ve opened a very convenient door for real bots.
The better model is to treat the agent as a delegated party. Record which agent placed the order and on whose behalf. Keep final authorisation, meaning payment confirmation and address changes, anchored to the actual customer. Log the agent’s request alongside the order so disputes can be reconstructed later. From a security point of view there’s another wrinkle: product titles, reviews and seller descriptions are now input to someone else’s LLM. Prompt injection through catalog content is a real AI security concern, and marketplaces with third-party sellers should start treating listing text as untrusted input.
Where we’d start before the festive rush
October is days away, so nobody is rebuilding their commerce platform before Diwali. Here’s what’s realistic in the next few weeks:
- Audit your product data for the ten attributes shoppers in your category actually filter on, and check whether each one is structured or buried in prose.
- Trace a single order end to end and write down every place price, stock or delivery ETA gets computed. If there’s more than one source of truth, that’s your first fix.
- Check that order creation is idempotent. This one matters even with no AI involved.
- Review your bot and fraud rules with a simple question: what happens today if a legitimate automated client places an order?
The bigger work of a clean public checkout API, an agent-aware fraud model and proper catalog modelling belongs after the festive season, once you’ve seen how much of your traffic actually arrives through assistants.
To be candid, we haven’t shipped an agent-facing marketplace checkout ourselves yet. What we do day to day is the groundwork underneath one: backend and API development, Flutter apps with native Swift and Kotlin where it matters, AI integration with security in mind, and code audits that find where the source of truth has quietly split in two. If you’re looking at your own stack and wondering how an AI buyer would get on with it, orithLabs is happy to take a look with you and tell you plainly what we find.