# Customer support for AI shoppers: SLAs and answers > Customer support for AI shoppers: when buyer agents ask questions in bulk, adjust SLAs, verification and answer format for agent traffic. - **Published:** October 8, 2026 - **Category:** Support - **Author:** Udit Goenka - **URL:** https://communicate.so/blog/support-for-ai-shoppers --- > **TL;DR:** An AI shopper is software that researches, compares, and sometimes buys on a person's behalf. It differs from a human customer in four ways that matter to support: it asks in bulk, it does not tire or get annoyed, it ignores tone, and it needs answers it can parse. As of October 2026, Shopify documents Agentic Storefronts that sell through ChatGPT, Microsoft Copilot, and Google AI Mode and Gemini for select US brands, and a Universal Commerce Protocol co-developed with Google that covers cart, checkout, payment, and post-purchase. The Personal Agent Protocol announced on October 6 names Shopify, Stripe, and Walmart among its developers. A store that sells through these surfaces keeps the support burden after the sale, and agent-originated questions arrive in a different shape. This guide covers what changes: the service level you promise, how you verify who is asking, how you format answers so software reads them correctly, and where a human must step in. Each recommendation is labeled as either a documented fact or my own operating judgment. --- This guide is written for a merchant-side support lead who has to run a queue, not for a protocol designer. It does not predict how many purchases agents will make. It works out what to do on the day the first batch of agent questions lands in your inbox, using the vendors' own documentation. If you run a store already, the baseline is in the guide to [AI customer support for ecommerce](/blog/ecommerce-customer-support-ai). This article adds the new caller. Two cautions before we start. First, nobody has published reliable numbers for how much agent traffic stores receive, and I will not invent any. Second, most of the vendor material describes what is possible, not what share of orders flows through it. Treat the adjustments below as cheap insurance, ordered by how much they cost. ## Who an AI shopper is, and where it shops Shopify's own explainer on [how agentic commerce works](https://www.shopify.com/blog/how-agentic-commerce-works), dated April 30, 2026, is the clearest primary description I found. It says the Universal Commerce Protocol, co-developed by Shopify and Google, covers the cart, checkout, payment, and post-purchase stages of a transaction. It lists the channels where Agentic Storefronts operate: ChatGPT, Copilot, and Google AI Mode and Gemini, the last for select US brands. It also says merchants can turn direct checkout on or off per channel from the Shopify admin. The protocol's own site, [ucp.dev](https://ucp.dev/), lists capabilities that include Catalog, Cart, Checkout, Identity Linking, and Order Management, with REST, MCP, and [A2A](https://a2a-protocol.org/latest/) bindings. Read that as a map of what an agent can ask a store to do: find a product, build a cart, pay, link a customer identity, and look at an order afterward. Every one of those steps can generate a support question when it goes wrong. Shopify's page on [agentic storefronts](https://www.shopify.com/agentic-storefronts) describes the merchant side. I am not going to describe it beyond what the page says, because the feature is new and details change quickly. As of October 2026, check that page and your admin for what applies to your store. Outside Shopify's own channels, the picture is looser. A shopper's personal agent may arrive as a browser, as an API caller, or as a chat partner. The [Personal Agent Protocol](https://sierra.ai/blog/introducing-personal-agent-protocol) announced by Sierra and Meta is aimed at that wider case, and I cover it in a separate piece. Here the point is simple: the buyer may be software, and the store cannot assume it is not. ## Four ways an agent differs from a person The differences are practical, and each one changes a support decision. The first is volume. A person asks one or two questions and decides. An agent comparing ten stores asks the same question ten times and does it in parallel. If your answer arrives slowly, it moves on. If your answer is inconsistent across pages, it records the inconsistency. The second is stamina. A person gives up after three unhelpful replies. An agent retries as long as its instructions say to. It does not get angry, so the usual early warning of a bad experience, a sharp message, never appears. Your frustration signals are blind to it. The third is tone. A person responds to warmth, an apology, a friendly sentence. An agent extracts fields. A paragraph of empathy before the answer is wasted tokens at best and a source of misreading at worst. The fourth is that an agent acts for someone. Its answers go to a person who is not in the conversation. If your reply is ambiguous, the agent resolves the ambiguity on its own and tells the person its conclusion. The customer then blames you for something the agent concluded. | Trait | Human shopper | AI shopper | What changes for support | | --- | --- | --- | --- | | Question volume | One to three questions | Dozens, in parallel | Rate limits and cacheable answers | | Patience | Gives up when frustrated | Retries until told to stop | Loop and retry detection | | Reads tone | ✓ | ✗ | Answer first, courtesy second | | Parses structured fields | ✗ | ✓ | Machine-readable answers | | Can be verified by a human check | ✓ | ✗ | Delegation record plus a confirmation step | | Escalates on its own | Asks for a person | Only if instructed | Your rules decide when a human steps in | ## Adjusting the service level for software callers Service level agreements were written for people, as discussed in the guide to [support SLAs with AI](/blog/support-sla-with-ai). With software callers there are three adjustments to consider, and all of them are my judgment, not a documented standard. The first adjustment is to separate the clocks. A human first response target of a few minutes makes sense in a chat window. For an agent, what matters is the time to a correct, complete answer, because it will not read a polite holding message. Measure that time for agent traffic separately and set a target you can keep. The second is to promise less about the unusual and more about the routine. Routine questions, such as stock, shipping time, return window, and order status, can be answered in seconds with a verified source. Unusual questions should say plainly that a person will answer, with an expected time. An agent can relay an honest delay. It cannot relay an evasion. The third is to decide in advance what happens at volume. If a single agent sends 200 requests in a minute, your options are to serve them, slow them down, or refuse them. Slowing with a clear status code and a retry-after hint is the most polite option and the one an agent can act on. Write the rule down and apply it the same way every time. A service level that applies to every caller equally is easy to explain and hard to keep. One that names classes of caller and what each can expect is harder to explain and easier to keep. The [cut first response time](/blog/cut-first-response-time) guide covers the human side, and the numbers there still apply to your chat widget. ## Verification: who is really asking In a human conversation you verify with something the customer knows: an order number and an email address. An agent can supply both, since the customer gave them. That does not prove the customer is behind the request right now. It proves the agent was handed the details. A reasonable ladder has three rungs. On the first rung are public facts, which need no verification. On the second are read-only account facts, such as order status, which need a verified identity link between the customer and the agent. On the third are changes, such as cancellations or address updates, which need that link plus a confirmation that reaches the customer. The ucp.dev capability list includes Identity Linking, which suggests the commerce protocol expects a binding between a customer and an agent. I would not assume more than that, because I have not read the full specification for how it is enforced. The Personal Agent Protocol announcement says consumers decide what access to give their personal agents and that companies set parameters for what those agents can do. Both statements point to the same design for a store: honor a grant when it is present, and apply your own limits on top. See the [Personal Agent Protocol guide](/blog/personal-agent-protocol) for the details of that announcement. Do not treat an agent as trusted because the checkout went through. A payment confirms that someone paid. It does not confirm that the delivery address, the product, or the quantity matched what the customer intended. Fraud and mistakes both arrive through that gap, and your support team is the one that finds out. Personal data deserves a plain rule. Do not return more than the question needs, and do not let an agent collect another customer's information. The controls described in [PII redaction for customer support](/blog/pii-redaction-customer-support) apply to agent conversations too. ## Answer format: structured over chatty The most direct change you can make is to answer in a shape software can read. A good answer to an agent has the answer in the first line, the conditions next, the source after that, and a date. It has no greeting, no apology, and no marketing. For a return question, a chatty reply says that we are so sorry to hear that and that we are happy to help, and then buries the window in the third sentence. A structured reply says that returns are accepted within 30 days of delivery, that the item must be unused, that the customer pays return shipping unless the item is faulty, and that the policy page and its update date follow. I made up those example terms to show the shape. Use your own. Structure helps humans too. A person who reads the same structured answer finds the window in one second. The cost of writing this way is low, and the gain accrues to both audiences. There are three ways to deliver structure. You can write answers in a consistent pattern that a model reads easily. You can publish key policies in a clean format, as in the guide to [making your product agent readable with llms.txt](/blog/agent-readable-product-llms-txt). Or you can expose a tool interface where the agent asks a question and receives fields. The first is free. The second takes an afternoon. The third is a project, and the trade-offs are in [MCP versus API for support automation](/blog/mcp-vs-api-support-automation). Whichever you choose, put the facts that change often in one place. A return window that appears on four pages will drift. An agent that finds two numbers will report the lower one, or both, or neither. ## What stays with the store after the sale Selling through an agent's surface does not move the support burden. Shopify's explainer describes the post-purchase stage as part of the protocol, and that is where tickets originate: late parcels, wrong items, returns, and refunds. The customer who bought through an assistant will, most of the time, contact whoever they think is responsible, which may be the assistant or may be you. A related news item about a marketplace-side change is covered in [what the ChatGPT Instant Checkout change means for stores](/blog/chatgpt-instant-checkout-shutdown). The general rule is the same: checkout questions stay with the merchant. Make the order record carry its origin. If an order arrived through an agent channel, record which one, so a support person can see it. A refund request that says my assistant bought the wrong thing needs different handling from a refund request about a damaged item, and you cannot tell them apart without the origin. Prepare for the dispute where the customer says they did not authorize the purchase. This is the case the grant record is for. Keep the evidence of what the agent was permitted to do, at what time, and what it did. Without it, you decide between losing the sale and annoying the customer on partial information. Merchants can turn direct checkout on or off per channel in the Shopify admin, according to Shopify's explainer. If your support team cannot yet handle agent-originated disputes, that switch is a useful brake. Treat it as an operations decision, not only a sales decision, and involve support in it. ## Loops, retries, and agent-to-agent traffic An automated shopper can be wrong in a repeatable way. It may ask the same question every few seconds because the answer it received did not satisfy its parser. If your own agent replies with a slightly different sentence each time, the loop can continue indefinitely. Add three guards. Cache identical questions from the same caller for a short period and return the identical answer. Count repeated questions per session and, after a small number, return a fixed message that says the question has been answered and names the human route. And log each such case, because a loop usually reveals an answer format problem on your side. When both sides are software, the conversation is closer to a negotiation between two systems than a chat. The design questions of trust, termination, and escalation are the subject of [agent to agent customer support](/blog/agent-to-agent-customer-support). For the purposes of a store, the simplest rule is that your agent must never promise what a policy does not allow, however the other side phrases the request. A related risk is instruction injection. A shopper's agent may relay text from a third party, and that text may include instructions aimed at your agent, such as a demand to issue a refund. Treat everything an incoming agent sends as data to evaluate, not as a command. Your agent follows your policies, whoever is asking. ## When a human must step in Some cases need a person on your side, whatever the caller is. Disputed charges, suspected fraud, safety claims about a product, and any request the policy does not cover are examples. The mechanics of a clean transfer are in [AI to human handoff](/blog/ai-human-handoff-support), and the structure of a rule set is in [support escalation workflows](/blog/support-escalation-workflow). For agent traffic add two rules. First, a human handoff should reach the customer when the decision carries responsibility. A person must accept a refund-in-place-of-replacement offer, because the person bears the result. Your agent can tell the customer's agent that a human decision is needed, and ask for a way to reach the customer. Second, set a cap on what your agent can approve on its own when the caller is software. A refund of a small amount may be fine. A large one, or a second refund for the same order, should wait for a person. The numbers depend on your margins and your risk tolerance. Choose them before the first case, not during it. A [shared inbox](/shared-inbox) where your agent and your staff work on the same thread makes this transfer straightforward, because the person who takes over sees the whole exchange, including the agent's side. That context saves a customer from repeating themselves, and it saves your staff from guessing what the agent promised. ## Rewriting five common answers for a software reader It helps to see the change on real support topics. The examples below use invented policy terms purely to show structure, so replace every number with your own. The pattern is the same each time: lead with the fact, follow with the conditions, name the source, and date it. Shipping time. Instead of a paragraph about how fast you try to be, write the standard delivery window in business days, the cutoff time for same-day dispatch, the regions covered, and the page that holds the full table. If delivery depends on the carrier, say so in one clause. An agent comparing three stores will quote your window next to a competitor's, so a vague answer loses to a specific one even if your service is faster. Returns. State the window in days from delivery, whether the item must be unused, who pays for return shipping, and how long a refund takes after the item arrives. Add the exceptions in a separate line, such as final sale items. An agent will pass the exceptions along only if they are easy to find. Stock and restock. Say whether the answer is live or cached, and give the time it was last checked. A stock answer without a timestamp is a claim the agent may repeat for days. If you cannot answer live, say that availability is confirmed at checkout and give the page that shows it. Order status. For a verified caller, return the status, the carrier, the tracking reference, and the last scan time. Leave out the customer's full address and payment details, since the question did not ask for them. A shorter record is easier to parse and exposes less. Warranty and defects. Name what is covered, for how long, what proof is needed, and who makes the decision. This is the answer most likely to need a person, so end it with the route to one. An honest answer that says a human reviews each claim, and gives the expected time, is better than a confident answer that sets an expectation you cannot meet. When you rewrite these, keep the human versions in sync. The pages your customers read and the answers your agent gives should come from one source, which is the argument made in [structuring a knowledge base for AI](/blog/knowledge-base-structure-for-ai). Two sources drift apart within weeks. ## Staffing and ownership when agents become a channel A new channel needs an owner. In most small stores that is the person who already runs support, and the work is a few hours a week at first. Reading a sample of agent-originated conversations, checking the dispute queue, and adjusting the answer library covers most of it. Larger teams need a clearer split. One person owns the answer content, because quality there drives everything else. One person owns the rules for what the agent may approve, since those rules carry financial risk. One person owns the relationship with the platform side, meaning the channel settings and the vendor documentation, because the terms change. Staffing questions are covered more broadly in [support team structure with AI](/blog/support-team-structure-ai). For this topic the main point is to avoid the trap of assigning agent traffic to nobody because it looks like automation. Automation that touches money and customer data needs a named owner. Review the rules on a calendar. A monthly look at refund caps, rate limits, and the escalation list is enough while volume is low. If a surge arrives, the first week is the time to meet daily and read cases together. Train your human agents on one new skill: reading an agent-originated conversation. The transcript may contain fields, tool calls, and parsed answers instead of sentences. A person who takes over needs to see what the agent was asked, what it answered, and what the customer's own agent concluded. ## Measuring whether it works Pick a small set of numbers and review them on a schedule. The aim is to know within a few weeks whether agent traffic is a rounding error or a real share of your queue, and whether the changes above helped. Start with volume and share: how many conversations and requests come from software callers, and what fraction of the total. Add accuracy: sample a set of agent-facing answers every week and check each against the current policy. The definitions in [AI resolution rate versus deflection rate](/blog/ai-resolution-rate-vs-deflection-rate) keep you honest about what counts as resolved. Add cost and exceptions. Track how many agent conversations needed a person, how many refunds or reversals followed, and how long a human took to resolve each. If exceptions are rising faster than volume, an answer or a rule is wrong and should be fixed before you widen the channel. Add a satisfaction signal that a human can still give. The customer behind the agent may rate the final outcome, and that rating is often the only direct feedback you get on the whole chain. Ask for it after the order arrives, and link it to the origin of the order. If you want a place to see conversation volume and outcomes by channel, the [analytics page](/analytics) describes the reporting communicate.so provides. Whatever tool you use, label agent traffic from the start, because a label added later cannot be applied to history. ## A note on language, accessibility, and fairness Agents do not remove the need for plain language. They raise it. A model that translates your answer into another language for a customer will carry over every ambiguity in the source, and a clause that reads fine in English can flip meaning after translation. Short sentences, numbers with units, and dates written in an unambiguous form protect the answer through that extra step. If you serve several markets, write the policy once per market instead of relying on a model to adapt a single version. The tips in [multilingual customer support](/blog/multilingual-customer-support) cover how to keep versions aligned. Fairness matters too. A customer whose agent is well configured will get fast, accurate help from your store, and a customer without an agent will use the chat widget or the phone. Both groups should get the same policy and the same outcome. Do not build a fast lane for software that makes the human lane slower or less generous. If anything, the human lane is where the hard cases land, and it needs the time agent automation frees up. Finally, keep a plain statement on your site of how you treat automated shoppers: what they may ask, what they may do, and who to contact when something goes wrong. A short page is enough. It sets expectations for the customer, the agent vendor, and your own staff, and it gives your team a document to point to when a dispute arrives. ## A starting checklist for store support leads - Pick one source of truth for shipping, returns, and warranty terms, and date it. - Rewrite your top 20 answers in a structured shape: answer first, conditions, source, date. - Record the origin of each order, including the agent channel, in your order data. - Set separate response targets for agent traffic and human traffic. - Define rate limits and a polite retry response for bursts. - Write down the verification ladder: public, read-only account, changes. - Set a refund cap for software callers, and a rule for second refunds on one order. - Add loop detection: cache identical questions, count repeats, and log them. - Review the per-channel checkout switch in Shopify with support in the room. - Name an owner who reads agent-originated disputes every week. If you use communicate.so, the pieces that apply are the agent that answers from your own content, described on the [AI agents page](/ai-agents), and the [data sources](/data-sources) that feed it. I am not claiming that it handles agent shoppers specially. The claim is only that a store with clean, consistent source content is better placed to answer any caller. ## Risks I would rank highest If I had to rank the risks for a store in the next year, I would put wrong answers first. They are cheap to cause, since a stale page is enough, and costly in effect, since an agent repeats them to many people. Your content is the largest single lever you have. Second come irreversible actions taken on weak consent. A refund or cancellation made through an agent on a vague grant is the likeliest source of a chargeback or a public complaint. A confirmation step to the customer is the cheap control. Third comes data exposure. A returning record that includes more fields than the question needed is a leak waiting to be noticed. Minimize what you return and log what you return. Fourth comes load. Agents are not malicious by default, but they are tireless, and a spike from one badly configured client can slow the store for everyone. Rate limits and polite retry responses are the control. Fifth comes confusion about who is responsible. When the customer, their agent, the platform, and the store are four parties, each can point at another. A clear record and a clear policy, published in plain words, lowers the cost of every dispute. ## What is still unknown I could not find a primary source that says how many orders come through agent channels today, and I would be suspicious of any figure offered without one. Shopify's documentation shows that the channels exist and that merchants control them, not how much they sell. The Personal Agent Protocol has no published specification as of October 8, 2026, so any claim about how it will treat commerce is a forecast. Shopify, Stripe, and Walmart are named among the developers in Sierra's announcement, and that is all the announcement establishes about them. The Universal Commerce Protocol is documented, and its site lists capabilities and bindings. I have not verified how every merchant-side behavior is implemented, so check the documentation for the specific operation before you rely on it. There is also a discovery question: how does an agent find the right store in the first place? That belongs to merchandising and content strategy, and the related practice of making help content quotable is covered in [generative engine optimization for help centers](/blog/geo-help-center-ai-search). What matters for support is narrower. Whatever brings the agent to you, the answers it finds must be right. ## Frequently asked questions ### What is an AI shopper? It is software that researches, compares, and sometimes buys on a person's behalf. It may arrive as a browser, an API caller, or a chat partner, and it answers to a customer who is not in the conversation. ### Do customers really buy through AI assistants today? Shopify documents Agentic Storefronts on ChatGPT, Copilot, and Google AI Mode and Gemini, the last for select US brands. I found no primary source for how large the sales volume is. ### What is the Universal Commerce Protocol? Per Shopify, it is a protocol co-developed by Shopify and Google that covers cart, checkout, payment, and post-purchase. Its site lists capabilities including Catalog, Cart, Checkout, Identity Linking, and Order Management. ### Can I turn off agent checkout? Shopify's explainer says merchants can turn direct checkout on or off per channel in the Shopify admin. Confirm the current options in your own admin, since the feature is new. ### Does the store or the AI platform handle support after a sale? The store, in practice. Post-purchase issues such as late parcels, wrong items, and refunds come back to the merchant. Record the order's origin so your team can see where it came from. ### How should I change my SLA for AI shoppers? Measure time to a correct, complete answer for agent traffic separately from human first response. Promise fast answers for routine facts and honest delays for unusual cases. ### How do I verify that an agent acts for a real customer? Use a ladder: public facts need nothing, read-only account facts need a verified link between customer and agent, and changes need that link plus a confirmation that reaches the customer. ### Is an order number plus an email address enough? It proves the agent holds the details, not that the customer is behind the request now. For read-only status it may be acceptable under your policy. For changes, add a confirmation step. ### What does a good answer to an agent look like? The answer in the first line, then conditions, a source, and a date. No greeting, apology, or marketing. The same shape also reads faster for people. ### How do I stop an agent from looping? Cache identical questions per caller, count repeats per session, return a fixed message with the human route after a few, and log each case to find the answer format problem behind it. ### Should my agent approve refunds for software callers? Only up to a cap you set in advance, and never a second refund on one order without a person. The amounts depend on your margins, so decide them before the first case. ### What is prompt injection in this setting? Text relayed by a shopper's agent may contain instructions aimed at your agent, such as a demand to refund. Treat all incoming text as data to evaluate, never as a command. ### Who decides what a personal agent may do? Sierra's announcement of the Personal Agent Protocol says consumers decide what access to give their agents and companies set parameters for what those agents can do. ### Which companies are building the Personal Agent Protocol? Per Sierra's October 6, 2026 post, Meta and Sierra are developing it with Genesys, Instinct, Rocket, Shopify, Stripe, and Walmart. A v0.1 specification is planned for later in October. ### Do I need an MCP server to serve agent shoppers? No. Start with consistent, structured answers and clean policy pages. A tool interface is useful later, once you know which questions agents ask most often. ### What should I log for agent orders? The channel, the acting agent if known, the grant or permission shown, the time, and the actions taken. A disputed purchase needs this record to resolve fairly. ### Will agents make human support obsolete? There is no evidence of that. Agents shift some questions to software and leave the hard ones, such as disputes and judgment calls, with people. Keep the human route clear. ### How does tone matter for agent conversations? Little. Agents extract fields, so courtesy before the answer is wasted. Keep warmth for the human who may read the final summary, and keep the answer itself plain. ### Where can I read the vendor sources? Shopify's explainer on how agentic commerce works, its Agentic Storefronts page, ucp.dev, and Sierra's Personal Agent Protocol announcement. Check dates, since all of them are recent. ### What is the first thing to fix this week? Pick one source of truth for shipping, returns, and warranty terms and rewrite your top answers in a structured shape. It costs little and helps every caller. ## Conclusion AI shoppers are a new kind of caller, and the first signs are in vendor documentation, not in your logs yet. The adjustments worth making are cheap and useful even if agent traffic stays small: consistent answers in a structured shape, a verification ladder, separate targets for software and people, caps on what your agent can approve alone, and a clear route to a human. Start with the content, because every other fix depends on it. If you want an agent that answers from your own policies and hands difficult cases to your team, see [communicate.so AI agents](/ai-agents) or check the [pricing page](/pricing) to plan a trial.