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 that this 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, so an agent carries a short-lived, scoped token instead of your customer's password or stored credentials.

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.

Alhena's Order Management Agent already works this way. It shares no shipping address, line items or tracking details until the order number and a matching email are provided, a two-factor binding that holds whether the requester is a person or an agent. We cover the details in how Alhena verifies shoppers before sharing Shopify order data.

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 answer it can parse and 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, parseable, 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 a clean payload it can use without guessing. 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 clear, stable, machine-retrievable statements: return window, condition requirements, who pays return shipping, warranty duration and claim process, exchange rules. Centralize them in one canonical source that your help center, your own AI and any external agent all read from, so no surface paraphrases its own version. Some brands also publish an llms.txt file at the site root that points AI agents to those canonical pages. 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 autonomously 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 workload forecast, 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 arrive in bursty, correlated clusters, not the smooth arrival curve of human tickets, so workload planning, peak sizing and alert thresholds all 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), note which surface it came from, whether ChatGPT, Gemini, Copilot or Perplexity, then report agent contact volume, resolution rate, error rate, and escalation rate as their own line, separate from human contacts. Cluster those contacts by semantic intent and you will quickly see what agents actually ask for. 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 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 with bot-like behavior 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

What does an agent-ready support stack look like?

Most support systems were built around tickets and a person reading them. Agentic traffic needs a different mental model: treat the requesting agent as an API client, not a customer in a chat window. The building blocks for that already exist, and several of them are open source.

Screening: tell trusted agents from bots before they reach the helpdesk

Agent identification starts before a request ever reaches your helpdesk. In December 2025, Akamai and Visa announced a collaboration that plugs Visa's Trusted Agent Protocol into Akamai's edge-based behavioral intelligence and bot protection, so merchants can distinguish trusted AI agents from malicious bots before a request touches sensitive systems. [3] The timing was not accidental: Akamai's 2025 Digital Fraud and Abuse Report found AI-powered bot traffic grew 300% in a year, with the commerce sector alone seeing more than 25 billion AI bot requests in a two-month window. [4] In June 2026, Akamai extended the idea into an Agentic Security Framework that scores the trust and intent of browsers, bots and agents instead of making a binary block-or-allow call. Akamai CTO Patrick Sullivan summed up the stakes: agentic commerce "hinges on recognition." For support, the practical move is anomaly detection on every incoming request, so a burst of forty near-identical return questions gets flagged as one agent's workload before it becomes forty tickets.

Tools: expose a few scoped support tools over MCP

The Model Context Protocol (MCP) has become the default way for agents to use tools. Anthropic introduced it in November 2024, and on December 9, 2025 donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI. By then there were more than 10,000 active public MCP servers, and ChatGPT, Gemini and Microsoft Copilot had all adopted the protocol. [5] For support, that changes the math: an agent that calls tools directly never needs to email your inbox. It can call a get_order_status or check_return_eligibility tool and get a typed JSON payload back in milliseconds.

Under the hood this is plain function calling: the agent reads each tool's description, fills in the arguments, and your system runs it. That is how most agents work today, whether the model comes from OpenAI, Anthropic or Google, and building an endpoint is modest work with the official MCP SDK for your language. So keep the agent tools narrow. Three or four read-mostly actions cover most agent-originated contacts: order status, return eligibility, policy lookup, and a create-case action that passes the conversation to your team. Give each a strict schema (reuse your OpenAPI definitions if you already publish REST endpoints), and have the policy lookup return the canonical text rather than whatever a semantic search over a vector database happens to surface. When the answer isn't available, return a clear error code instead of a guess.

The usual concern is exposure, and the answer is the same discipline you would apply to any public API. Put the MCP endpoint behind your gateway so it inherits the same control plane: per-agent quotas, key rotation and a kill switch. The MCP specification has defined OAuth 2.1 authorization for remote connections since its March 2025 revision, so each tool execution can be gated on a scoped, audience-bound token rather than a shared API key or static credentials. Restrict tool use to reads unless the customer has explicitly approved an action, and make every write idempotent: if an agent repeats a return request after a timeout, an idempotency key guarantees you create one return, not three, which handles the state management most agents are bad at. If you want to go deeper on how MCP sits next to ACP and UCP, our protocol guide covers the mechanics.

Orchestration: decide who handles each agent request

Behind that, orchestration decides who handles each request. Deterministic workflows should own the easy, high-volume paths like status lookups and eligibility checks, with no model in the loop at all: they are cheaper, lower latency, and immune to injected instructions. Ambiguous requests go to an autonomous AI sub-agent, and anything involving a refund above your threshold, an address change, or a policy exception should trigger a human-in-the-loop (HITL) step that pauses execution until a person approves.

When the other side is coordinating a multi-merchant task, the A2A protocol gives agents a standard way to advertise their capabilities and exchange tasks over JSON-RPC. Google introduced A2A in April 2025 and moved the specification, SDKs and developer tools to the Linux Foundation that June. [6] Few support teams need A2A today, but when a shopping agent needs to orchestrate a return across three stores, it will expect to talk to your agent, not your inbox. It is worth knowing before your enterprise architecture team asks.

Observability: trace every agent interaction end to end

Finally, instrument everything. Emit OpenTelemetry traces for each agent request, from the screening decision to the tool call to the response, so you can debug a failed agent interaction the same way you would a failed API call. Evaluation platforms such as LangSmith or Arize can sit on the same telemetry to grade answer quality, while your security team watches it for misuse. At runtime, platforms like Palo Alto Networks' Prisma AIRS scan prompts and model responses for injection and flag agentic threats such as impersonation and tool misuse. [7] Add an immutable audit trail and you can answer the question every merchant will eventually face: what exactly did our system tell that agent, and why?

Alhena AI slots into this architecture at the tool and orchestration level. It runs two specialized sub-agents: an Order Management Agent for WISMO, returns and account questions, and a Product Expert Agent for pre-sale questions. Both answer only from verified store data, with every action recorded and a context-carrying transfer to your helpdesk when a person is needed.

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, an AI agent platform built for ecommerce support and sales, is designed 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 clear, 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. Stand up a small MCP endpoint for your top agent tools, test it in a sandbox, and keep the deployment read-only until your monitoring shows it behaves as expected. Fold inbound injection strings into your regression suite.

Frequently asked questions