The Future of Ecommerce Has No Storefront: What AI Shopping Agents Taught Us While Building Sorted

In the future of ecommerce, a growing share of orders will be placed by AI shopping agents rather than by people tapping through an app. For merchants, the storefront stops being the point of sale: the order arrives as a tool call from software they have never met, on behalf of a customer they cannot see. AI agents in ecommerce work only when every order can prove, before it is accepted, that a real person authorised that exact purchase.

We did not arrive at that from a whiteboard. We arrived at it by building something small and watching where it broke.

Key takeaways

• When AI shopping agents place the order, merchants lose the storefront as a control point. Consent, scope and recourse have to move to the moment the order arrives.
• Per-app MCP whitelisting works for the first ten clients and breaks at the next thousand. The scalable replacement for "approve the app once" is "verify the order every time."
• In Sorted, each user gets an Abstraxn server wallet identity with no seed phrase, and a KYI mandate decides which carts are allowed to reach payment.
• Know Your Intent is not a checkout precheck for one app. It is the shared evidence layer that lets vendors, apps, payment providers and users trust the same order without trusting each other.

What changes for merchants when AI shopping agents place the order

Most writing on agentic commerce takes the buyer's side: the agent finds, compares, fills the cart, pays. The question that kept coming up in our standups was the other side of the counter. If AI agents become the traffic, what does a merchant actually receive?

Not a visitor with a browsing history and a device fingerprint. A structured request, from software, asking to place an order against a customer account. Every tool merchants built over twenty years of ecommerce assumes a person is looking at a screen: the product page, the "are you sure?" dialog, the CAPTCHA, the one-time password. An AI shopping agent sees none of it. It sees a list of tools and a JSON schema.

The easy part is exposure. Publishing an MCP server is a thin layer over endpoints a mobile app already calls: search, catalogue, cart, checkout, tracking. Several of India's largest food delivery and quick commerce platforms have already done it.

The hard part is everything the storefront did silently.

• Consent. In the app, the tap is the consent. With an agent in between, the only evidence of consent is whatever the agent says.
• Scope. A person does not accidentally order forty dinners. An agent working from an ambiguous instruction, or a prompt injection hidden in a restaurant description, can. The merchant cannot tell a normal order from a runaway one.
• Recourse. The first question in every dispute is "who authorised this?" A log line saying the order came from an authenticated session was enough when a session meant a person. It is not enough when a session means a model.

None of this is hypothetical. One public vendor MCP manifest warns plainly that the integration can place cash-on-delivery orders on the user's behalf and that placed orders cannot be cancelled. That is an honest warning, and a description of a system where the only thing between the agent and an irreversible order is the agent's own judgement.

Why we built Sorted, an MCP aggregator for commerce

We wanted to know what it would take for a merchant to trust an agent's order as much as a tap on its own app. The fastest way to find out was to build the agent side ourselves.

Sorted is an MCP aggregator: multiple vendors, one roof. We integrated the public MCP servers of some of the biggest names in Indian quick commerce and food delivery, and put them behind a single chat. You say what you want once, "a litre of milk" or "pizza under 300", and Sorted works out whether it is a grocery or food request, searches the vendors you have connected, builds the cart through each vendor's own MCP server, and hands it to checkout, where payment runs through that vendor's own UPI flow.

The older name for chat-first buying is conversational commerce, and the difference matters. In conversational commerce, a chatbot helps a person buy. In agentic commerce, the agent does the buying, which is why what it is allowed to buy stops being optional.

Sorted today sits deliberately between the two. The agent builds the cart; the user starts checkout; and a hard policy check sits between checkout and payment. We built it that way on purpose. It is the same check a fully autonomous agent would have to pass, tested while a human is still in the loop. The principle: humans set intent, agents execute inside it.

How an order moves through Sorted

1. The user signs in. An Abstraxn server wallet gives them a wallet identity in the background.
2. The user connects vendors from the Connectors screen, each through that vendor's own login.
3. The user sets limits in plain language, such as "max ₹500 per order" or "no alcohol", and confirms them as structured rules.
4. Sorted seals that confirmed set of rules into a signed mandate.
5. The user chats. Sorted searches the connected vendor MCP servers and builds a cart.
6. The user starts checkout. Before any payment starts, Sorted asks KYI whether this exact cart is inside the mandate.
7. KYI returns ALLOW or DENY, with a signed decision receipt either way.
8. On ALLOW, the vendor's UPI payment flow continues. On DENY, checkout stops, the user sees the reason in plain language, and the receipt is kept in their decision history.

How Sorted uses Abstraxn server wallets

If an agent acts for a user, every party downstream needs to know whose action it is, and nobody ordering groceries should have to learn about seed phrases to make that true.

So each Sorted user gets an Abstraxn server wallet: a wallet identity bound to their account, with keys handled server-side, never in the browser and never inside the model's context. In the demo its job is identity. Payments do not run through it: money moves through each vendor's own UPI flow.

Being precise about signing matters here. In Sorted today, the mandate is sealed by a sealer key on Sorted's server after the user confirms the rules, not by the user's own wallet. That is fine for a demo and it is not the end state. Evidence is strongest when the person granting the authority signs it with a key the app cannot use on its own, and a user-held wallet identity is the natural place for that signature to come from. Sorted does not do that yet.

The broader point about wallets for AI agents still holds. Their useful property is not that they hold money. It is that every party can tell which principal an action belongs to, and that the model can request an action without being able to forge the authority behind it.

How KYI mandates restrict what the agent can order

A mandate is the sealed, machine-readable version of what the user authorised. Building Sorted taught us that not every rule a shopper types belongs in it yet, so Sorted checks rules in two layers.

The split is itself a finding. Vendor carts rarely carry clean category tags, so a rule like "no alcohol" only works reliably when something also reads item names, and item-level rules are not yet part of the sealed mandate. Amount and vendor rules are, and the receipt below comes from that layer.

Velocity caps, such as a ceiling on orders per day, are in active development.

The mandate is enforced by Warrant, the module inside Abstraxn's KYI Framework. Before checkout proceeds, Sorted calls check() with the proposed cart, and Warrant evaluates it deterministically: the same cart against the same mandate always returns the same answer, any refusing rule wins over any number that permit, and an evaluation error denies rather than passes.

Two details mattered more than we expected.

The human confirms structure, not a sentence. A model turns "don't spend more than five hundred, and only use the two apps I trust" into draft rules. If the model's interpretation were what got sealed, we would have moved the trust problem from the shopping agent to the translating agent. So the user confirms the rules as rules, in a plain readback generated by fixed logic, and only the confirmed rules are sealed. The model drafts. It never decides.

Denials are the most useful output. In testing, a ₹845.25 cart went over a ₹500 per-order cap. The check refused it, the payment flow never started, and the user saw which rule had fired, with a signed receipt in their decision history. That receipt has the same shape, signature and storage as an approval, and in the demo the decision trail is anchored on a public testnet (Base Sepolia), so it can be checked without trusting our database. An approval shows something happened. A denial shows a control was operating, which is what every disputes team and auditor eventually asks for. (More on limit design in AI Agent Spending Limits: How to Build a Mandate That Can't Be Overspent.)

What a KYI denial receipt looks like

This is the receipt from that test, as Warrant issued it on 22 September 2026: a ₹845.25 food order against a mandate with a ₹500 per-order cap. We have removed the vendor, the item and the agent identifier, and shortened the signature. The signature covers the original, unredacted record, so this excerpt will not verify as shown.

{
  "action": {
    "action_type": "checkout",
    "domain": "food",
    "items": [{ "name": "[redacted]" }],
    "value": { "amount": 845.25, "currency": "INR" },
    "counterparty": { "id": "[redacted]", "type": "vendor" },
    "agent_id": "sorted_[redacted]",
    "timestamp": "2026-09-22T06:31:44.458Z"
  },
  "verdict": "DENY",
  "reasons": [
    {
      "code": "AMOUNT_MAX_PER_ACTION",
      "detail": {
        "got": 845.25,
        "max": 500,
        "currency": "INR",
        "mandate_id": "mnd_sha256:90c34982d32bd7bce1712668cb83f869"
      }
    }
  ],
  "matched_mandate_ids": ["mnd_sha256:90c34982d32bd7bce1712668cb83f869"],
  "decision_id": "dec_6c150326-576b-4c77-954a-b7f3805be976",
  "evaluated_at": "2026-09-22T06:31:44.458Z",
  "inputs_digest": "7696f7beb52a9de9962603c42af7445d094e428b54fc310e19580a970476e84c",
  "signature": {
    "alg": "Ed25519",
    "key_id": "kyi-prod-001",
    "sig": "0334336cfb188507...e72ee908"
  },
  "onchain": {
    "status": "confirmed",
    "batchId": "34",
    "root": "0xd1cb07fd083efebc60e5ef48d178e21578bab10c7960f24969fc1832615fd792",
    "txHash": "0x9828c2df650e75026e9ff5cef4abd541687669e471ab01d2a30559f2346d7981"
  }
}

Five fields do the work:

• reasons says why in a form both a machine and a person can use: which rule fired (AMOUNT_MAX_PER_ACTION), the value it saw (845.25) and the limit it held (500). The agent gets a reason it can act on, and the user gets a sentence they can read.
• mandate_id identifies the exact sealed mandate the cart was checked against. It is derived from the agent, the domain, the principal, a hash of the rules, the sealing time and the seal's signature, so it points to one specific approval event. Change any rule and you get a new mandate with a new id; nobody can later swap in a different version and claim it was the one in force.
• inputs_digest is a hash of everything the decision was made on. Re-run the same inputs against the same mandate and you get the same verdict, because evaluation is deterministic.
• signature is Ed25519 over the whole record. Anyone holding the published public key can check it offline, without calling us.
• onchain anchors the decision on Base Sepolia, a public testnet. Transaction 0x9828c2df...d7981 was mined in block 47,145,210, about four seconds after the decision. The Merkle root in the receipt appears in that transaction's calldata. This batch held a single decision, so the root is the decision's own leaf hash.

The user's decision log in Sorted. Three denials across two days, each with a receipt and an on-chain transaction. Vendor names are blurred.

MCP OAuth and whitelisting: can it scale?

Building across vendors taught us three things, each checkable against public vendor documentation. Every vendor MCP server is an island, with no shared carts, orders or sessions, so any rule that spans vendors has to live above all of them. Every vendor authenticates differently, and each connection proves the user logged in without proving what the user allowed. And no vendor interface we used accepts, or could check, the mandate an order was placed under. The vendor trusts the app. The app trusts itself.

Access is where this becomes structural. MCP authorization is built on OAuth, so a vendor's lever for deciding who gets in is the redirect URI. Today those are allowlisted for a short list of known clients: the major AI assistants, a couple of developer tools, localhost for testing. Anyone else is asked to get in touch. In April 2026, one of India's largest food delivery platforms formalised this into an invite-led builder programme, and its documentation states that production access is invite-based today.

That is a responsible way to open a commerce system to AI agents. It is not a way to run one at scale.

The arithmetic does not close. Every new app needs approval from every vendor it wants to reach. Ten apps and ten vendors is a hundred reviews. A thousand apps and fifty vendors is fifty thousand, and the long tail of agentic commerce is exactly those thousand small apps: the nutrition planner that orders groceries, the office assistant that books lunch. Public issue trackers on vendor MCP manifests already show builders with working, transacting integrations waiting on a redirect URI approval.

It checks the wrong thing. Whitelisting evaluates the app once, at onboarding. An approved app with a badly behaved agent is still approved. The whitelist asks "do we know this app?" The vendor's real risk question is "did the customer authorise this order?"

It concentrates the market. If access depends on review bandwidth, the apps that get through are the ones big enough to be worth reviewing, which quietly turns an open protocol back into bilateral deals.

Whitelisting will survive as a gate for high-risk capabilities and fade as the main control, the way websites stopped approving browsers and started checking requests.

Why every vendor will need an open MCP server

Vendors cannot simply keep the door shut. If purchase intent increasingly starts in an AI assistant, a vendor the customer's agent cannot reach is, for that customer, not in the market. In the agent economy, the equivalent of being indexed is being callable.

That is the bind: open broadly and accept orders from software you never evaluated, or stay narrow and cede the traffic to whoever opens first. The way out is to stop making vendors choose. Let any app call the tools, require every order to carry proof of what the customer authorised, and check that proof at the vendor's edge.

How merchants and marketplaces can prepare for agentic commerce

Building Sorted left us with a short list. None of it is novel alone; all of it has to be present at once.

1. Agent-readable catalogues. Search, availability, pricing and checkout exposed as tools, not scraped from pages.
2. A principal behind every agent. A signing identity per user that the model can use but never extract. Server wallets make this possible with no key management.
3. A signed mandate. What the person allowed, as an artifact independent of the agent and the app.
4. A check before execution. Allow or deny before the order exists, not reconciliation after it ships.
5. Structured denials. A reason the agent can act on ("over your per-order limit, ask the user"), not a silent failure it retries.
6. Receipts any party can verify. Approvals and refusals, signed, checkable without calling the issuer.
7. An evidence path for disputes. When a customer says "I never ordered this," the mandate version in force and the decision made against it.

Items 1 and 2 are being built across the industry; we covered that side in Agentic Commerce Infrastructure: The Rails Decide Who Wins. Items 3 to 7 are where agentic commerce compliance lives, and where most of the work still is.

Why KYI belongs to the ecosystem, not to one app's checkout

In Sorted, KYI looks like a checkout precheck. That is the least interesting thing it does. Four parties need the answer to "was this order authorised?":

• The vendor, to accept an order from an app it never reviewed, and to defend a chargeback afterwards.
• The app, to prove its agent stayed inside the user's instructions, a credential that should matter more than a whitelist entry.
• The payment provider, to know the consent behind an agent-initiated payment is real, not just asserted.
• The user, to see what their agent was allowed to do and what it was stopped from doing.

If each runs its own check, there are four records of the same order, each written by a party with a stake in the outcome, and they will disagree exactly when it matters. In Sorted today, the check runs inside our own checkout and the mandate is sealed with our own key. Vendors do not verify the mandate themselves. That is fine for a demo and wrong as an end state: an app checking its own agent is auditing itself.

A mandate the user signed, a decision made against it before execution, and a receipt all four can verify offline gives them the same answer without trusting each other. This is how agentic AI payments prevent fraud in a way a whitelist cannot. The vendor does not need to have approved the app. It needs to verify the order. We explain the category in full in Know Your Intent (KYI): AI Agents Have an Identity Layer. They Have No Intent Layer.

What we do not know yet

• Whether vendors will accept a third-party receipt. The model only works if vendors check mandates at their own edge. That is their product decision, not our technical one.
• Who carries liability when the mandate was right and the outcome was wrong. No shipped protocol answers this yet.
• What Sorted does not do yet. The user's own wallet does not sign the mandate; Sorted's server seals it. Item-level rules are checked by Sorted rather than sealed into the mandate. Checkout is started by the user, not the agent.
• What KYI does not do yet. Velocity caps and a kill switch are in active development. Mandate expiry is stored but not yet enforced at evaluation time. There is no delegation model, so an agent handing work to another agent is not covered today.

The future of ecommerce, seen from the counter

For twenty years ecommerce assumed a person was looking at the screen. AI shopping agents remove the screen, and with it the silent layer of consent every merchant relied on without naming it.

The vendors publishing MCP servers are right to open up and right to be careful. The mistake would be treating careful as permanent and running an agent economy through a review queue. The storefront used to be where a merchant knew a real customer wanted something. In agentic commerce, that knowledge has to travel with the order.

Sorted will stay a demo. The layer it needed is the part we are building.

Frequently asked questions

Related reading

• Know Your Intent (KYI): AI Agents Have an Identity Layer. They Have No Intent Layer.
• Agentic Commerce Compliance: Why the Boring Layer Is the One That Unlocks the Money
• Agentic Commerce Infrastructure: The Rails Decide Who Wins
• AI Agent Spending Limits: How to Build a Mandate That Can't Be Overspent
• The AI Agent Security Questionnaire: 12 Questions Enterprise Buyers Ask
• Who Is Liable When an AI Agent Is Right?