Agentic Commerce Infrastructure: GPU Planning for AI Shopping Agents
Overview
Agentic commerce — AI agents that discover, compare and complete purchases on a shopper’s behalf — moves the inference load in retail from occasional chatbot sessions to sustained, machine-speed API traffic. For infrastructure teams the practical 2026 question is not whether to adopt protocols like the Agentic Commerce Protocol or Google’s Universal Commerce Protocol, but how much GPU serving capacity a merchant needs when both human sessions and third-party buying agents hit the same catalog, ranking and negotiation endpoints. A mid-size Indian retailer typically needs a dedicated small-LLM serving pool (7–13B class) alongside its existing ranking tier, not a frontier-model cluster.
Key takeaways
- Agent-driven interactions reportedly influenced roughly $67 billion in global Cyber Week sales — about a fifth of digital orders — and the share is expected to grow through 2026.
- Agent traffic is bursty, machine-paced and cache-hostile; capacity planning must key on sustained API concurrency, not human session counts.
- Merchant-side agent stacks run well on 7–13B instruction-tuned models with tool calling; frontier-scale models are rarely justified on-prem.
- ONDC and WhatsApp-based conversational buyers make India an early high-volume market for agent-mediated retail traffic.
- Structured, machine-readable catalog and delivery data decides whether agents select your store; GPU capacity is wasted without it.
What changes when the shopper is an agent
Human shoppers browse in bursts with think-time between clicks. Buying agents fire dense sequences of catalog queries, availability checks, comparison calls and checkout steps in seconds, around the clock. Analysts tracking the space, including MetaRouter, describe 2026 as the year agent-originated traffic becomes a measurable share of e-commerce requests rather than a novelty. Two infrastructure consequences follow: first, peak-to-average ratios flatten — agents shop at 3 a.m.; second, per-request compute rises, because answering an agent well means running retrieval, ranking and a language-model response rather than serving a cached page.
The merchant-side model stack
A typical 2026 merchant agent endpoint layers four components: a structured product feed (the non-negotiable foundation), a retrieval layer over catalog and policy documents, a tool-calling LLM in the 7–13B class that composes answers and executes checkout actions, and guardrail models for pricing and fraud. The LLM tier is the GPU consumer. Quantised to FP8/INT8 on an L40S or a single H100-class card, a 8–13B model sustains high concurrency at the 1–3 second response targets agents tolerate. The retrieval layer follows the same design rules as enterprise RAG — our RAG reference architecture for India applies directly.
Protocols and where compute actually lands
The Agentic Commerce Protocol (2025) standardised simple single-item checkout, and Google’s Universal Commerce Protocol (announced at NRF in January 2026) extends agent-to-merchant interaction across catalogs and payments. These protocols shift discovery compute toward the agent platforms — but merchants still pay for answering: eligibility logic, personalised pricing, stock and delivery-promise calls, and any conversational clarification. Expect the merchant share of inference to concentrate in short-context, high-frequency LLM calls, which favours throughput-optimised inference GPUs over large-memory training parts. The inference sizing checklist covers the concurrency arithmetic.
India: ONDC and WhatsApp-first buying
India’s ONDC network is structurally friendly to agentic commerce because it is already an open, machine-readable protocol rather than a walled marketplace. Conversational buyer apps — Gupshup shipped the first WhatsApp-based ONDC buyer experience — point at a future where a large share of Indian demand arrives as structured network calls mediated by language models. Sellers and seller-network participants that host their own catalog-answering and negotiation models in-country get lower latency to Indian agent platforms and cleaner DPDP Act posture for the purchase and behavioural data flowing through these endpoints; see DPDP-ready AI infrastructure planning.
Honest limits and open questions
Agentic commerce volumes are still forecast-heavy: protocol adoption, payment-rail trust and liability for agent mistakes remain unsettled, and reported figures vary widely between trackers. The prudent 2026 posture is capacity that serves today’s conversational-commerce traffic with 2–3× headroom, on hardware that also serves your existing search and recommendation load — not a speculative agent-only cluster.
Sizing frame for merchant agent endpoints
| Stage | Agent traffic share | Model tier | Typical hardware |
|---|---|---|---|
| Pilot (2026) | <5% of requests | 7–8B tool-calling LLM, shared retrieval | 1× L40S-class GPU alongside existing serving |
| Scaling (2026–27) | 5–20% | 8–13B LLM + guardrails | 2–4× L40S or 1–2× H100-class |
| Mainstream (2027+) | >20%, 24×7 flat load | Multiple specialised models, negotiation logic | 4–8× H100/H200-class pool, autoscaled |
| Deferred | Discovery outsourced to agent platforms | Feed + rules only | CPU-only; add GPUs when conversational volume justifies |
Frequently asked questions
Do merchants need their own LLM to participate in agentic commerce?
Not to be discoverable — structured feeds and protocol compliance handle that. A merchant-hosted LLM becomes worthwhile when conversational clarification, negotiation or personalised answering volume is high enough that per-call API pricing exceeds the cost of an owned inference node.
What GPU class suits a merchant agent endpoint?
Throughput-optimised inference parts — L40S-class, or H100-class where models pass 13B parameters or concurrency is high. Training-optimised, large-memory configurations are rarely justified for short-context commerce calls.
How is agent traffic different from bot traffic we already block?
Legitimate buying agents authenticate via commerce protocols and complete purchases, so they must be served, not blocked. The operational shift is distinguishing protocol-compliant agents from scrapers while meeting machine-speed response expectations.
Does ONDC require sellers to run AI infrastructure?
No. ONDC is a specification, not software. But conversational buyer apps on the network translate shopper intent into structured queries, and sellers with model-backed catalog answering respond to those queries more competitively than static feeds.
Is 2026 too early to invest in agent-serving capacity?
A dedicated cluster is premature for most. The low-regret move is one inference GPU tier that serves existing search, recommendations and a conversational endpoint together, with headroom to scale as agent share of traffic becomes measurable.
Ready to deploy?
Talk to an RDP architect about power, cooling and lead time.