How to Prepare Your Support Stack for Agentic Traffic

Agentic traffic is AI agents contacting support for shoppers. Learn to verify, route, and measure agent-originated tickets across your stack.

Published September 2026

The inbound contact that isn't a person

Agentic traffic in support is inbound contact created by an AI agent acting on a shopper's behalf, rather than by the shopper directly. A ChatGPT agent emails about a delayed order, a Perplexity assistant fires off a return-eligibility question, a Gemini agent asks your bot to confirm warranty terms before it buys. The requester is software with a task, a deadline, and a willingness to retry - and it is arriving whether you planned for it or not. Per Gartner's 2025 CEO Survey, 50% of CEOs believe machine customers and AI agents will be part of the commercial process by 2026, and Gartner named machine customers a Top Strategic Technology Trend for 2024. Your support stack, meanwhile, was built for humans who get tired, get embarrassed, and give up. Machines do none of those things.

Most ecommerce teams have spent the last two years preparing the storefront for AI shopping agents - structured product data, feeds for ChatGPT and Gemini, agentic checkout. That work matters, and we cover it in depth in our guide to preparing your ecommerce store for AI shopping agents. But the support side is a different problem with a different owner. When the agent finishes buying and something goes wrong, it does not disappear. It shows up in your inbox. This post is about that side of the line: what happens to your helpdesk, your routing, your policies, and your team when the party on the other end of a support conversation is a machine.

Why this is happening now, fast

The traffic moved faster than the org charts. Adobe's Quarterly AI Traffic Report, released April 16, 2026 and based on more than one trillion visits to U.S. retail sites, found AI-driven retail traffic rose 693% year over year over November–December 2025 (November +769%, December +673%) and another 393% year over year in Q1 2026, with March 2026 alone up 269%. The economics flipped, too: by March 2026 AI traffic converted 42% better and drove roughly 37% higher revenue per visit - a reversal from March 2025, when AI referrals converted about 38% worse and non-AI traffic was worth 128% more. Our own study of LLM traffic across 310 online stores found LLM-referred traffic grew 6.5x in twelve months.

Discovery and checkout traffic is the leading edge. Support contact is the wave right behind it, and Gartner has put hard numbers on the trajectory. In a March 2023 press release, Gartner analyst Uma Challa forecast that "by 2026, 20% of inbound customer service contact volume will come from machine customers" - nonhuman economic actors that obtain goods or services in exchange for payment. [1] Gartner's later research pushes the horizon further: 50% of all service requests will be initiated by machine customers powered by agentic AI systems by 2030. On the revenue side, Gartner's CEO surveys found executives expect 15–21% of company revenue to come from machine customers by 2030, with those customers influencing an estimated $30 trillion in purchases.

Here is the awkward part. When we looked at what the major helpdesk vendors have published about receiving contacts from external consumer agents - not their own AI deflecting tickets, but a shopper's ChatGPT or Perplexity agent showing up in the queue - we found almost nothing specific. Zendesk, Gorgias, Intercom, and Salesforce frame their 2025–2026 AI messaging around their own agents resolving tickets, or around internal agent-to-agent orchestration inside their platforms. The inbound-consumer-agent problem is largely unclaimed. That gap is exactly why this belongs on your roadmap now, not after the vendors write the playbook for you.

Seven things that change when the requester is a machine

1. Identity and authorization: is this agent really acting for your customer?

When a human emails "where's my order," you authenticate the person. When an agent contacts you, you have two questions, not one: is this a legitimate agent, and is it authorized by the specific customer whose order data it wants? A convincing agent request is trivial to fake. The entire Amazon–Perplexity fight in late 2025 turned on Perplexity's Comet agent representing itself as a Chrome browser user rather than a bot; Amazon sued in November 2025, accusing Perplexity of "computer fraud by failing to disclose when Comet is shopping on a real person's behalf." That ambiguity is precisely what you cannot afford when the request is "show me this person's address and order history."

The infrastructure to resolve it now exists, and it firmed up fast in late 2025:

• Cloudflare Web Bot Auth, first proposed in May 2025, lets an agent cryptographically sign its requests using HTTP Message Signatures (RFC 9421) with an Ed25519 key published at a /.well-known/http-message-signatures-directory. You verify identity instead of trusting a spoofable user-agent string.
• Visa Trusted Agent Protocol (TAP), unveiled October 14, 2025, is built directly on that standard. As Visa put it, TAP "enables merchants and agents to establish trust using existing web infrastructure - with minimal user experience changes required." Chief Product and Strategy Officer Jack Forestell framed the merchant's dilemma exactly: "Merchants shouldn't have to choose between blocking bots and serving real customers - Trusted Agent Protocol helps solve that."
• Mastercard Agent Pay, announced April 29, 2025, added an Acceptance Framework in October 2025 that "requires agent registration and verification before any transactions can take place across the Mastercard network." Both networks host their own directories of registered agents, and both use a header tag indicating whether the agent is browsing or paying.

A parallel discipline, "Know Your Agent" (KYA), extends KYC logic to non-human actors: bind the agent to a responsible human or business, confirm its delegated authority actually covers the requested action, and log the decision. [2] The emerging IETF work on agent auth leans on OAuth 2.0 as the delegation framework.

You do not need to ship the full cryptographic stack this quarter. You do need a policy: define what an unverified agent may see (public policy; order status when the customer already handed the agent an order number) versus what requires a verified, authorized identity (full order history, address changes, refunds to a stored method). This is the same scoped-permissions discipline we apply to your own action-taking agents in our guardrails guide - now pointed at inbound traffic instead of outbound.

2. Tone and format: write for a parser, not a reader

A machine does not need the warm opener, the apology paragraph, or the upsell. It needs a clean, unambiguous, structured answer it can act on. When the other side is an agent, marketing filler is not neutral - it is noise that raises the chance the agent misparses your reply, then retries or escalates.

The practical shift is to give your support AI a mode for agent-originated conversations that returns explicit, self-contained statements: "Return window: 30 days from delivery. This order delivered 2026-09-02. Eligible until 2026-10-02. Restocking fee: none." A human reads the same facts wrapped in a sentence; an agent gets them as near-data. Our State of Agentic CX report found that of 15 live AI agents tested, all 15 could answer but only 4 could complete an action. The gap between explaining and doing is the whole game - and a clean, machine-legible answer is what lets the agent on the other side actually finish the job instead of stalling on your prose.

3. Policy exposure: publish rules an agent can read before it buys

Product-page schema tells an agent your price and availability. It does not tell the agent your return, shipping, and warranty rules in a form it can consume before it commits its human to a purchase. If those policies live only in a PDF or a prose help-center article, the agent either guesses or contacts you to ask - turning a policy question into a support ticket, and a wrong guess into a post-purchase dispute.

The move is to expose policy as clearly structured, stable, machine-retrievable statements: return window, condition requirements, who pays return shipping, warranty duration and claim process, exchange rules. This is distinct from product schema, which we deliberately do not re-cover here - see our protocol comparison of ACP, UCP, and MCP for that layer. Think of it as making your support knowledge as agent-legible as your catalog already is. The payoff is fewer pre-purchase contacts and fewer post-purchase disputes, because the agent set the customer's expectations correctly at checkout.

4. Routing and classification: one agent can open forty tickets

Human volume is self-limiting. A frustrated shopper opens one ticket, maybe two. An agent running a comparison task can fire forty parallel return-eligibility queries across forty SKUs in a few seconds, then follow up on none of them. If your routing treats each as a distinct, human-urgency ticket, you will flood the queue and distort every SLA and staffing model you have.

Three concrete adjustments:

• Tag agent-originated contacts at ingestion so they are visible as a class, not smeared across your human volume.
• Set separate SLAs. An agent polling for order status does not need a two-hour human response; it needs an accurate answer in one second, or a clear "not yet available, retry after X."
• Model the volume differently. Agent contacts are bursty and correlated, not the smooth arrival curve of human tickets, so peak sizing and alert thresholds both change.

None of the standard agentic-readiness checklists address parallel agent inquiries. This is genuinely new operational territory.

5. Post-purchase ownership: who owns the WISMO ticket for an order placed inside ChatGPT?

This is the merchant-of-record question, operationalized. Under the Agentic Commerce Protocol (OpenAI and Stripe, released September 2025) and Google's Universal Commerce Protocol, the merchant stays the merchant of record and keeps post-purchase support, returns, and disputes even when an agent placed the order inside a chat interface. As one ACP technical guide puts it bluntly: "Post-purchase, returns, support. Those remain your responsibility." The protocol's job ends the moment the order is confirmed; yours is just beginning.

So when a "where is my order" question arrives for an order created inside ChatGPT Instant Checkout, your order stack has to recognize and resolve it even though the sale never touched your storefront session. WISMO already accounts for 20–40% of ecommerce support tickets; agentic orders add a class of them where the buyer - and possibly the buyer's agent - expects an answer grounded in live order data your generic helpdesk AI cannot reach. That is precisely the line between helpdesk AI and commerce-native AI we draw in our comparison of the two: most native helpdesk AI answers from knowledge-base articles, and roughly 30–40% of ecommerce tickets are WISMO queries that need live order data it can't see.

6. Measurement: instrument which contacts came via an agent

Your traffic analytics measure storefront referrals. They do not tell you which support contacts originated from an agent. If you cannot see it, you cannot staff for it, price for it, or catch it going wrong. Add an "agent-originated" dimension to your support instrumentation: flag it at ingestion (from signed-agent headers where present, from behavioral signals otherwise), then report agent contact volume, resolution rate, and escalation rate as their own line, separate from human contacts. This is the support-side analogue of the revenue attribution most brands only run on the storefront - and it is the single cheapest thing on this list to start this week.

7. Rate limiting and abuse: tell a legitimate agent apart from a scraper

An inbound support channel that answers agents is also a channel that answers bad agents. Two distinct threats live here: scrapers hammering your endpoint to harvest policy or pricing, and prompt-injection attempts against your support bot itself. OWASP ranks prompt injection as the number-one LLM risk (LLM01:2025); its canonical example is "a customer support chatbot" tricked into ignoring its guidelines, querying private data stores, and sending emails, "leading to unauthorized access and privilege escalation." Your support inbox is untrusted input - every ticket comment, email, and message the bot reads could be trying to give it orders.

Signed-agent verification (see area 1) is your best tool for the legitimate-versus-scraper distinction: a Web Bot Auth signature from a payment-network-registered agent is a strong allow signal, and Cloudflare can auto-validate it at the edge, while unsigned high-frequency traffic gets rate-limited. For injection, keep the discipline our guardrails post applies to your outbound agent - scoped permissions, no privileged action without confirmation, full audit logs - and extend it to inbound. The fact that a request arrived from a plausible agent does not mean its embedded instructions should be obeyed.

Human shopper vs. agent-originated contact

Where Alhena fits

Handling agentic traffic well needs a support layer that is order-aware, commerce-native, and able to act - not a ticket-deflection bot bolted onto a knowledge base. Alhena AI is built for exactly that. Its Order Management Agent connects to live order, shipping, and returns data, so a WISMO question about a ChatGPT-placed order resolves against real order status rather than an FAQ article. Its guardrails enforce scoped permissions, tiered confirmation, and complete audit logging on every action - the same controls that keep inbound instructions from turning into unauthorized ones. And when a contact does need a person, Alhena passes identity, intent, constraints, and attempted steps into your existing helpdesk - Zendesk, Gorgias, Freshdesk, Intercom, or Kustomer - so nothing is re-asked. We built for the clean, context-carrying handoff precisely because escalating empty-handed is worse than not escalating at all.

Alhena also sits across every channel a contact can arrive on - web chat, email, WhatsApp, Instagram, and voice - on one knowledge base, which is what lets you enforce a single, consistent agent-traffic policy no matter where the agent knocks. Book a demo to see how Alhena resolves agent-originated and human contacts in the same order-aware workflow.

The staged move

Skip the twelve-month roadmap. Here is what to do, in order, and the signals that should pull each stage forward.

• Now (this quarter): Add an "agent-originated" tag at ingestion and start measuring the volume - you cannot manage what you cannot see. Define your data-exposure policy: what an unverified requester sees versus what requires verified authorization.
• Next (one to two quarters): Give your support AI a machine-readable answer mode, and publish your return/shipping/warranty policies as structured, stable statements. Set separate SLAs and routing rules for agent contacts. Confirm your post-purchase stack resolves WISMO for orders placed inside AI surfaces.
• Then (as the standards mature): Adopt signed-agent verification (Web Bot Auth / Visa TAP / Mastercard Agent Pay) as both an allow signal and a rate-limiting boundary. Fold inbound prompt-injection strings into your regression suite.

Frequently asked questions