- On 4 August 2026 the Ninth Circuit vacated the injunction that had kept Perplexity's Comet agent off Amazon, holding that the user, not the agent vendor, is the one accessing the site.
- The reasoning matters more than the parties: if the shopper is the accessor, a computer fraud claim is a weak lever for keeping agents off a storefront.
- The same week, Hark previewed a browser agent that works on sites with no API at all, which is what most independent shops are.
- An agent forgives nothing a human forgives. Vague sizing, a price rendered only in an image, a checkout that needs a phone confirmation, each of those is an abandoned cart.
- You do not have to join a commerce protocol to be legible to agents. The product markup Google already asks for covers most of it.
- Under the agentic checkout specification the merchant still owns tax, risk scoring and the decision to accept the order, so agent sales are not a channel you hand off.
A federal appeals court spent the first week of August deciding something that sounds abstract and is not: when an AI agent logs into a shopping site with your password and buys you a pair of shoes, who is the visitor. The answer changes what a shop owner can do about it.
On 4 August 2026 the Ninth Circuit Court of Appeals in San Francisco threw out the injunction Amazon had won in March against Perplexity's Comet browser. Engadget reported the opinion and its central move: because the browser needs a person to direct it, the panel treated Comet users rather than Perplexity as the parties accessing Amazon's servers. Under the Computer Fraud and Abuse Act, Amazon had to show that Perplexity itself intentionally accessed a computer without authorisation and caused measurable loss. The panel found that showing had not been made, and said an injunction against conduct that probably does not violate the statute would not serve the public interest.
The Decoder noted that this is the first federal appeals ruling on whether an AI agent may act on a platform, and that it settles nothing permanently. The injunction is gone. The underlying suit continues in San Francisco. Amazon says it is evaluating next steps, which can mean a rehearing petition or a run at the Supreme Court. For a merchant, the durable part is not the score line. It is the theory of access, because that theory applies to your storefront exactly as it applies to a marketplace with a legal department.
What did the court actually decide, and what did it leave open?
It decided one narrow thing: that a preliminary injunction resting on a computer fraud theory could not stand where the credentials, the intent and the click all trace back to a human customer. It did not decide that agents are welcome, that a site cannot set terms, or that Amazon loses the case.
The original order came from a California federal court in March, where Judge Maxine Chesney found strong evidence of unauthorised access to password protected accounts. Amazon's argument has been about transparency and about using published interfaces rather than driving a logged in session, and it points at its own agent tooling as the sanctioned route. Perplexity's chief executive called the suit bullying and argued that an agent working on a person's behalf should inherit that person's rights. Both positions survive the ruling. Only the injunction did not.
Nothing here is legal advice, and none of it is settled. What follows is about the operational consequence: agents will keep arriving on ordinary storefronts while the courts work, and a shop that is unreadable to them loses the sale silently.
Who is actually building the agents that will show up?
Two different kinds of software are converging on the same checkout button, and they behave nothing alike. Both of them also have to get past your fraud scoring, which historically read fast automated checkout as a threat, and that mismatch is now a live source of false declines on legitimate orders.
The first kind sits inside an assistant and talks to you through a merchant integration. That is the world of product feeds and sanctioned endpoints, and it is the one where the shop consents. We covered the advertising side of it when ads moved into the AI shopping assistant, which is worth reading alongside this, because the same surface is now both an ad unit and a purchase path.
The second kind is a browser that drives your site the way a person would. TechCrunch previewed Hark Handoff, from a company that raised a 700 million dollar Series A in May 2026. The pitch is precisely the part that matters to an independent shop: it is built for sites with no official API, and the examples given were Target, Walmart, OpenTable and LinkedIn. Instead of predicting the next word, the model predicts the next action, a click or a keystroke at a specific place on the page. A waitlist is open and the company is aiming to ship by the end of summer 2026.
Read those two stories together and the picture is unambiguous. The legal barrier to the second kind just got lower, and the tooling for it just got funded. A shop with no API, no feed and no integration is not exempt from agent traffic. It is the default target, and not only for buying: an assistant sent to book a gym class ended up cancelling another member's reservation because one endpoint never checked who was asking.
What does an agent need from a product page that a person does not?
A person is a forgiving reader. They infer the size from the photo, guess that the price in the banner image is current, and email you when the variant picker misbehaves. An agent does none of that. It reads fields. When the field is missing it either guesses or gives up, and both outcomes cost you the order.
Here is the practical difference, assembled from what the agent specifications ask merchants to expose and what a browser agent has to infer when nobody exposed anything.
| Element on the page | What a human buyer does with it | What an agent needs instead | What fails if it is missing |
|---|---|---|---|
| Price | Reads it anywhere, including inside an image or a banner | A machine readable price with its currency, matching the price at checkout | The agent quotes one number and the cart shows another, so the purchase stops |
| Availability | Interprets "usually ships in a week" without help | An availability value that resolves to in stock or out of stock | The agent adds an item you cannot ship, then the order is cancelled |
| Variants | Clicks through colours until something looks right | An explicit parent and child relationship, with the attribute that varies named | The wrong size is ordered, and the return is yours to pay for |
| Shipping and returns | Scrolls to the footer, or gives up and buys anyway | Shipping cost and return window as structured values on the offer | The agent cannot compare you to anyone, so it picks a shop that can be compared |
| Checkout | Solves a captcha, waits for an SMS code, tries again | A path that completes without a human interrupt in the middle | Silent abandonment, with no email and no recovery sequence |
The last row is the one merchants underestimate. A human who hits a friction step complains. An agent that hits a friction step simply stops, and you will never learn it was there. The only trace is a session in your analytics that looks like a bounce.
Is a commerce protocol required, or is ordinary markup enough?
For most shops, ordinary markup is enough to start, and it is work you probably owe your search traffic anyway. Adobe's 2026 retail analysis argues the same point from the other end, finding that product pages score worst of any page type for machine readability even as visitors arriving from assistants convert best.
Google's own product structured data documentation splits the world into product snippets, meant for pages where nobody can buy, and merchant listings, meant for pages where they can. Merchant listing markup is where sizing, shipping detail and return policy live. Google says outright that supplying both the on page structured data and a Merchant Center feed maximises eligibility and helps it verify your data. Every one of those fields is also what an agent reads. You are not doing two jobs.
The protocol route is a bigger commitment. OpenAI's agentic commerce key concepts describe a product feed in CSV or JSON carrying identifiers, descriptions, pricing, inventory, media and fulfilment options, submitted as a sample for validation and then refreshed daily. On the checkout side the assistant collects buyer and payment detail and calls merchant endpoints, while the checkout state and the payment processing stay on the merchant's systems.
Read the merchant obligations in that document slowly, because they are the part the marketing skips. The merchant validates the cart. The merchant works out fulfilment options. The merchant calculates and charges sales tax. The merchant runs its own payment and risk signals, charges through its own processor, then accepts or declines the order and reports status back. OpenAI states it is not the merchant of record. Translated: an agent channel is not a marketplace that handles the messy parts for you. It is a new front door onto the same back office you already run, with a stricter contract about response times and correctness.
Can a small shop still block agents if it wants to?
Technically yes, and it got harder to justify. The Ninth Circuit's theory is that the customer is the one accessing the site. Blocking the agent therefore means blocking a customer who chose a tool, which is a different conversation from blocking a scraper.
There is also an asymmetry worth naming. Amazon can afford to litigate a boundary for two years. An independent shop cannot, and the practical options left to it are the blunt ones: bot detection that also catches real buyers on unusual browsers, or checkout steps that break automation and irritate humans in the same motion. Both trade a known conversion loss for an unmeasured protection. If your fear is fraud rather than agents as such, the controls that actually help are the ones around credentials and permissions, which is a separate discipline we walked through in the piece on the AI tool keys nobody is watching.
Does blocking help with chargebacks?
Not by itself. An agent purchase authorised by the account holder is an authorised purchase. The dispute risk that comes with agent traffic is mostly the mundane sort: wrong variant, wrong shipping estimate, price mismatch between what the agent read and what the cart charged. Every one of those is a data quality problem on your side, and fixing the data is cheaper than fighting the transaction afterwards.
What should a shop do this month?
Nothing on this list requires a protocol, a platform migration or a developer retainer. It is the order I would work in.
- Put merchant listing markup on every product page. Price with currency, availability, condition, shipping cost and the return window. If your storefront generates it already, validate a real page rather than assuming.
- Make the markup agree with the cart. A price that is right in the markup and stale at checkout is worse than no markup, because it produces a confident wrong quote.
- Name the variant relationship. Say which attribute varies and which items are children of the same parent, so an agent can pick a size instead of guessing one. A generated app that never modelled variants has nowhere to put that, which is the gap between a general app builder and a commerce one.
- Walk your own checkout without a phone. If a step needs an SMS code, a captcha or a native app, an agent stops there. Guest checkout that survives automation is the single highest value fix on this list.
- Log the unusual sessions. You cannot manage a channel you cannot see. Even a crude tally of user agents that read the markup and never load the hero image tells you whether this is theoretical for you yet.
- Leave the feed until the traffic exists. Daily feed refreshes and custom endpoints are real engineering. Earn the evidence first.
How is this different from search engine optimisation?
It overlaps more than it differs, which is the good news. Both reward the same thing: unambiguous facts on the page in a form a machine can lift. The difference is the consequence of being wrong. A search engine that misreads your price shows a bad snippet. An agent that misreads your price builds a cart, gets refused, and moves to a competitor within the same minute. We looked at a related question when we asked whether llms.txt does anything measurable, and the answer there generalises here: machines follow the formats that already have adoption, not the ones with the best story.
Does any of this matter if you sell services rather than products?
Yes, and sooner. The Hark examples were reservations and returns as much as shopping. A booking page with the availability buried in a JavaScript widget is exactly the kind of page a browser agent has to reverse engineer, and exactly the kind it gets wrong. If your calendar is the product, the calendar needs to be readable.
The part nobody is saying out loud
Agent traffic will be small for most independent shops this year, which matches what the marketplaces report: Etsy put agentic experiences at under 1% of its own traffic in August 2026. It will also be measured badly. There is no clean referral string, no agreed identifier, and no obligation on the agent to say what it is. You will see the effect before you see the cause: a rise in sessions that read one page deeply and leave, a modest lift in orders with unusually clean data, and an occasional cart that fails at a step you thought was harmless.
What the last week changed is the direction of travel. A funded vendor is shipping an agent for sites without APIs, and the strongest legal tool a big platform had for keeping such agents out just failed at the appellate level on a theory that applies to everyone. The reasonable response is not a protocol integration. It is making sure the facts on your product pages are true, complete and machine readable, which is the same work that helps every other channel you already have. If you are rebuilding a storefront anyway, this is the moment to make it structured from the start rather than retrofitting markup onto a template that was designed to be looked at. That is the case for an AI ecommerce store builder that owns its own code rather than a themed rental you cannot change at the field level.
If you take one measurement away from this, make it the checkout walk. Everything else on the list is a data field you can fix in an afternoon, and the checkout is the only step where a customer disappears without leaving you anything to follow up on.
One more thing about timing. Hark said end of summer. The appeals opinion is dated 4 August 2026. The agentic checkout specification is public and being implemented now. None of those are distant. A shop that spends a weekend on markup, variant relationships and a checkout that does not require a phone will be ready before the traffic arrives, and will get better search results in the meantime whether or not a single agent ever visits. That is an unusually cheap bet, and it is the reason this story belongs on a merchant's desk rather than a lawyer's.