Most merchants have never seen what an agent actually does on their site.
The dashboards they have show aggregates. Visits per day, conversion rate per channel, top landing pages. The aggregate view is useful for measurement. It’s almost useless for understanding what’s actually happening at the session level when an agent shops on behalf of a buyer.
This post walks through the typical pattern an agentic shopping session follows. The shape we describe is consistent with how the major AI assistants behave when handling product queries on behalf of a buyer. Specific session details vary by category, agent platform, and buyer constraints. The structural pattern is consistent. If you’ve never watched what happens between “buyer asks an agent” and “buyer either lands on your site or doesn’t,” this is the walkthrough.
The query
The buyer hands the agent a multi-constraint product request. Something like “I need a winter coat for skiing, budget around $400, prefer something that works for active use, runs cold.” The constraints stack quickly: use case, location implication, budget ceiling, form factor preference, personal temperature preference. Five constraints is unremarkable. Some agentic queries have many more.
The agent classifies this internally as a comparison-shaped product query with multiple constraints. It decides to do research, build a shortlist, evaluate against the constraints, and synthesize a recommendation.
The buyer never sees a SERP. They see a chat response that arrives some seconds later with two or three recommended products, each with a reason for the recommendation and a link.
The first hop: building the shortlist
The agent’s first action is typically a query against the open web for the category. It pulls back a mix of editorial roundups and brand pages. The agent doesn’t usually navigate to all of them. It extracts brand names and product candidates from snippets and builds a shortlist.
This is the step most merchants don’t see. The decision about which brands make the shortlist happens before the agent ever requests a page from your site. The signal the agent uses to populate the shortlist is the public mention pattern across editorial coverage, structured data, and llms.txt files it can find quickly.
Brands appear on the shortlist because they show up consistently in editorial coverage, their llms.txt declares the relevant product category clearly, and their structured data is discoverable in the agent’s first-pass crawl. Brands that don’t have these signals tend not to appear. Two brands with comparable products may have very different shortlist outcomes depending on whether the first-pass signals favor them.
The targeted fetches
Once the shortlist is built, the agent issues requests against each candidate brand’s site. Most platforms identify themselves in the User-Agent on these second-stage fetches, even if their first-stage browsing was anonymous.
The typical request sequence looks something like:
GET /collections/<category>for the category pageGET /products/<product-name>for the PDPGET /products/<product-name>.json(or equivalent) for the structured product feedGET /.well-known/acp/manifest.jsonfor the ACP manifest, where presentGET /agent/query?q=<specific-question>for the agent-specific endpoint, where present
The whole sequence is fast, often completed in a few seconds per candidate. The agent extracts what it needs and moves on.
What the agent extracts in this pattern: the product price, the JSON-LD AggregateRating, the relevant spec from a structured endpoint if available, the size or stock availability, and the policy block from llms.txt. What the agent does not request: the homepage, the about page, the customer photos gallery, the size-guide modal, or the customer-reviews-with-photos page. The agent doesn’t need any of those. It needs the structured truth and the policy disclosure. It gets what it needs in a handful of requests.
The comparison
The agent now has structured information for each shortlisted brand. It evaluates each one against the buyer’s constraints.
Where one brand returned a specific spec (a numerical temperature rating, a specific dimension, a clear warranty term), the agent has high confidence applying it to the constraint. Where another brand returned a vague qualitative description (“warm enough for most winter conditions”), the agent has lower confidence and either has to infer or discount the source.
Where one brand’s JSON-LD AggregateRating matches the visible review count on the page, the agent treats both as trustworthy. Where the structured data disagrees with the visible content, the agent flags the discrepancy and downweights the source.
Where one brand allowed the agent to fetch its content, the agent has full data. Where another brand blocked the agent crawler in robots.txt, the agent falls back to inferring everything from the cached editorial roundup it found in the first stage. The cached version may be out of date. The fallback recommendation may be for a previous-season product that’s no longer in stock.
The comparison stage is where catalog cleanliness, structured data fidelity, and crawler permissiveness all show up as competitive differences. The brand with the cleanest data tends to win. Not because the agent has a brand preference, but because the agent has more confidence in what it can cite.
The recommendation
The agent presents the buyer with two or three options. The reasoning the agent gives the buyer is built from the structured data and the agent-endpoint responses. The specifics in the recommendation (temperature ratings, review counts, return windows, sourcing notes) are things the agent could cite confidently because the merchant exposed them cleanly.
When the reasoning is specific, the buyer trusts the recommendation. When it’s vague, the buyer often goes back to refining the query, which is another opportunity for a different brand to appear in the next round.
The buyer makes a choice. They click the link.
What happens at the merchant site
The buyer lands on the PDP with a referer from the agent platform. The session looks like a regular Chrome browser referral in the merchant’s analytics, unless the merchant has wired UTM tagging or behavioral classification for agent referrals.
The buyer adds the product to cart. The buyer completes checkout, often quickly, because the meaningful evaluation has already happened. The conversion looks normal in the merchant’s daily reporting.
The merchant typically doesn’t see the session-level detail unless they’re using session-stitching attribution (such as Inception Trace) that threads the agent query, the agent visit, and the human conversion into a single record.
What this pattern shows
A few patterns worth pulling out of the typical agentic session shape:
The agent’s decision was already half-made before it visited the merchant’s site. The shortlist was built in the first stage, from editorial mentions and structured data the agent could discover quickly. By the time the agent visited the merchant site, it was looking for confirmation, not initial information.
The signals that mattered at the merchant site were structured and specific. Specific numerical ratings, real review counts, exact prices, exact return windows. The marketing copy, the brand storytelling, the lifestyle photos, the customer testimonials with names: none of this fired in the agent’s evaluation. The buyer saw the brand story when they landed on the PDP, but the agent had already decided to recommend by that point.
Honest disclosure was a winning move, not a defensive one. Sources that included specific honest framing (including limitations or boundary conditions) made stronger recommendations, not weaker ones, because the agent could match the framing to the buyer’s actual constraint.
Competitor mistakes determine as much of the outcome as the chosen brand’s quality. The brands that lose the shortlist do so because of structured data inconsistencies, blocked crawlers, or vague specs that the agent couldn’t apply to the buyer’s constraints. The winning brand often wins not because it’s dramatically better but because it’s dramatically less broken.
What to take from this
The session pattern above repeats across most agentic shopping sessions we’ve observed and that have been documented in agent-behavior research. The exact details differ by category. The general shape (early-stage shortlist from public signals, targeted fetches per candidate, extraction of structured data and policy disclosure, comparison against constraints, recommendation of the cleanest source) holds consistently.
If you run a store, the actionable read is to inspect your own site the way an agent does. Issue the request sequence above against your own PDP. Are the answers consistent across the page, the JSON-LD, the /agent/query endpoint, and the llms.txt? If they’re not, you’re failing the cleanliness test that determines the outcome of these sessions.
We’ll write more session-pattern posts as the category matures and as more merchants gain the tooling to observe their own agent traffic at the request level. The general shape, that the agent decides on cleanliness and disclosure, has been consistent across every session pattern we’ve examined.
The buyers are already sending agents. The agents are already reading structured truth and ignoring marketing copy. Worth knowing what your site looks like to them.