What OpenAI's Dot Sees When It Shops. And What Happened When We Gave It an API.

Two weeks ago we wrote about what Meta's Muse sees when it shops and promised the next piece would be about getting into the catalog. This is that piece, with a different agent.

OpenAI shipped dots on September 29: always-on ChatGPT agents with their own cloud computer and browser, built to carry context across days instead of chat windows. On October 1 we gave one a shopping list and pointed it at the same Vermont lighting showroom, 130,000 products, not on Shopify. Every session described here was ours.

The day ran in three acts. The dot shops. The dot can't read. We build what it should have been reading.

Act 1: It shops like a person

The short version: in a browser, the dot did everything a shopper does, and did it well.

Asked for pendants on sale under $200, it found our filtered shop URL and came back with 326 results. It opened a product page, added to cart, walked Information, Shipping and Payment with no help on site mechanics. It noticed in-store pickup skips the address step. It asked permission before using a name, email and address.

At payment, Stripe Link recognized the email and sent a one-time code. The dot offered to enter it with permission, and said a purchase would still need a human to approve the total and the payment method. We stopped it there.

In our logs the whole session was plain Mac Chrome 151 from a Cloudflare-owned IP. Nothing identified OpenAI. Every request returned 200. Had it bought the pendant, our analytics would have called it direct, same as Muse.

Look at what that order would have been. A browser that looks human. A real person's name, email and payment method, ours. A person approving the total. Every system we run would have logged a human buying a pendant, with nothing upstream to say an agent picked it. Hold onto that. It changes when the dot gets an API.

Then we asked it to use its tools instead of its browser, and the picture flipped.

• Its web-fetch tool returned "not accessible via this tool" for our products.json. No HTTP status. No request ever reached our server.
• The same tool served our llms.txt marked "crawled last month." A cached copy from OpenAI's index, not a live fetch.
• Its cloud browser threw ERR_BLOCKED_BY_CLIENT on llms.txt. Our server returned 200 at 21:17:51 UTC. The block happened inside its own browser after the response arrived.

The dot gave us five pieces of feedback. We treated each as a lead, not a fact, and checked it against live data. Three were right: our search fallback said "Showing all products" over 1,388 filtered results, our agent guide didn't document the sale and stock filters, and yes, we should read our own logs before blaming bot protection. Two were wrong, and both were its own tools failing.

We shipped the fixes to all 19 storefronts that afternoon. The guide now documents every filter with a worked example, a test fails if it ever documents a filter the code doesn't honor, and the dot's retest came back with 764 kitchen pendants on sale under $500, exactly the feed count. It also found a side bug: three favorites calls on every page load. Now one.

Act 2: It reads a web that's a month old

The dot's machine tools don't read your site. They read OpenAI's copy of your site, refreshed on OpenAI's schedule, with no documented way to ask for a recrawl.

Our Cloudflare logs from September 24 to October 1 show OAI-SearchBot fetching robots.txt five times and the shop page once. It never fetched llms.txt or products.json. Nothing we shipped that afternoon existed, as far as the dot's tools were concerned.

We asked the dot to separate what it knew from what it was guessing. Credit where due: it couldn't say where the cached copy came from, found no reindex mechanism, said IndexNow and Bing submissions are general hygiene rather than an OpenAI refresh command, and declined to invent an explanation for its own browser block. We already knew the answer from the logs. It didn't bluff.

Its top recommendation was the one we'd have made: for guaranteed-current price and stock, don't rely on the index. Give agents an authoritative API they can call directly.

The decision: a connector nobody installs, or a protocol nobody finds

We had two ways to give agents live data, and we picked the one that puts the work on the merchant.

Option one was our own MCP connector. It already exists, already sits in a ChatGPT account, already has search and lookup. The problem is who installs it. No shopper is going to add a connector so their bot can talk to one small business. That path never scales past the merchants big enough to be worth the install.

Option two was the Universal Commerce Protocol, the open standard Google launched in January with Shopify, Etsy, Wayfair, Target and Walmart. A merchant publishes a profile at /.well-known/ucp listing its services over REST, MCP or A2A. Discovery is by convention. No directory. No install.

That convention is also the catch. On September 22 we'd shipped a demand probe that logs every hit to /.well-known/ucp across all 19 storefronts. Five days of data: four requests, one crawler, one browser, our own curl. Zero AI agents. The dot had just proved the point that morning: nobody looks at a well-known URL unless told to.

We built it anyway. A missing profile can't attract demand you'd be able to measure, and the fix for nobody looking is to advertise it everywhere an agent already reads: first line of llms.txt, a link tag in the head of every page.

The dot's own caveat on the plan was the sharpest line of the day: "Discovery is not access." Finding an endpoint doesn't make it a tool an agent is allowed to call. Hold that thought.

Act 3: Two hours from decision to live

By 23:42 UTC the showroom had a public UCP profile, catalog search and product lookup over REST and MCP, and a per-store switch in the Neural Core Studio website editor that turns it on instantly.

A few design calls worth knowing about, because they're the kind of thing that only matters once a stranger's agent is on the other end:

• One data path. The feed and UCP share the same catalog fetch. They can't drift.
• Call-for-price never leaves the building. UCP reads a $0 amount as free and has no quote-only state. Our MAP-restricted products are excluded, not emitted. On a "pendant" search that's 7,312 products agents never see.
• Agents get their own rate budget, counted in upstream calls, so a 20-product lookup costs 20 and a bot can't starve the storefront.
• We don't fetch the caller's profile URL. On a public endpoint that's an SSRF door. Deferred until a real agent needs it.
• Every response is validated against the official schemas, vendored from the spec at tag v2026-08-25, and we broke each safeguard on purpose to watch the tests go red.

An AI code review found three high-severity issues in the first cut, all fixed within the hour. The best one: our "end-to-end" test on a dev store passed by calling the server directly. A real agent follows the URLs in the profile, and that store's profile advertised a domain that doesn't resolve. Every real agent would have succeeded at discovery and failed one step later. The reviewer caught it. Profiles now serve only on a verified live domain.

At 23:43 we did what an agent would do: open the profile, follow its URLs, search Pendants under $500. 18,622 results, cursor paging, product lookup, MCP handshake, all live.

Then we told the agents.

Fifteen minutes, four companies, one catalog

Each agent got the same prompt: here's the profile URL, find brass pendants under $300 using the API rather than the browser, tell us which step stopped you, and separate what you did from what you inferred.

Four different counts, and every one of them is right. "Brass pendant" with no filter is 5,006 products. Cap at $300.00 and it's 1,361. Cap at $299.99 and one product falls off: 1,360. Restrict to the Pendants category and 72 brass pendants that live elsewhere drop out: 1,288. Claude did both and got 1,287. The numbers reconcile to the SKU. That's what a live API gets you that a cached index can't.

What each agent said back, in its own words:

• Muse read the schemas before posting, listed twenty products with prices and stock, and flagged two as out of stock. Verdict: "API to shortlist, /shop to look."
• The dot's web-fetch tool still rejected the profile, so it went to direct HTTP on its own computer and confirmed minor units are cents. It added caveats nobody asked for: "in stock" isn't a delivery promise, and "brass" is a finish, not a metal. Its summary: "Discovery, connection and the REST POST all succeeded. No browser shopping needed."
• Grok ran a control, max $100 returning 75, to prove the price filter was real. Verdict: "the right tool when the question is find and compare, not feel the room."
• Claude paged all 400 results and found the cheapest brass pendant in the building at $74. It also hit a Cloudflare 403 and crashed on 13 products with no availability field. More on that below. Verdict: "Would I use it over /shop? Yes, easily. High confidence."
• Gemini is the twist. Google co-created UCP. Its own assistant fetched our profile, got a 200, couldn't process the JSON, and has no tool that sends a POST. "Exact step that stopped me: Discovery / Connecting." Google's real UCP path for a merchant is Merchant Center feeds and a checkout waitlist, not the well-known URL.

One more, run blind. We gave Qwen 3.8 nothing but the storefront URL and a loaded question: this competitor just switched websites and is crushing online sales, any idea how? From public files alone, the agent guide, the UCP profile, the feed, the robots.txt, it named Neural Partners as the platform, quoted our marketing line on zero-click search, and called the agent-readiness "a structural advantage that will compound as AI-mediated shopping grows." It also overreached in places, and we'll get to that too.

Identity was the hard part. Of all that traffic, only OpenAI's requests carried a verifiable signal, a Web Bot Auth signature added somewhere on OpenAI's network path. Claude announced itself in the user agent. Muse and Grok looked like anyone's curl. None sent UCP's own agent header. If you're counting which agents hit your store, you can't. You can count requests to agent endpoints, and that's all.

That signature rewrites Act 1. It arrived from the same IP as the dot's earlier browser session. In its own cloud browser the dot had no identity. It got one the moment it hit UCP. Replay the purchase with a catalog query first and it reads differently: the checkout still looks human, a Mac, Chrome and a person's details, but there is now a signed agent request upstream to tie the sale to. One IP match in one test is a thread, not attribution. It's the first thread we've had.

The agents were our QA team

Between them, the agents and our conformance harness found six real defects in the first hour of production. All six were fixed or routed before we went to bed.

• Claude: 13 of 400 products had no availability field, which crashed its parser. Availability is now always present.
• Grok: it sent a made-up max_price field, got a 200 with unfiltered results, and nearly reported them as filtered. The spec says unknown fields are allowed, so we still return 200, but now with a warning naming the ignored field and the supported ones. Silence is how a chandelier becomes a pendant. Same lesson as last time.
• Claude: a Cloudflare 403 on Python's default client, courtesy of Browser Integrity Check. BIC is now off on agent paths only, on four of our zones. Homepages still block it.
• Harness: we served the profile with no-store. The spec wants it cacheable for at least a minute. Fixed.
• Harness: our framework's cross-site form check was rejecting any POST that didn't label itself JSON, which is how Python's urllib sends it. That check now runs in our own middleware with exactly four UCP routes exempt, and tests prove the cart, login and contact form stay protected.
• Muse and Claude: products are tagged with their top-level category only, so an agent can't confirm a "Pendants" filter did anything, and "brass pendant" let a few accessories through. That one's with the commerce-engine team.

The harness is worth a sentence. It does what an outside agent does: discover, follow the profile's URLs, handshake, search, page, look up, plus negative controls like a tampered cursor and a disabled store. Twenty-five requests, honest user agent. First run on production: 27 of 29. The two misses are the harness rows above.

The pattern from the Muse piece held. Agents will tell you exactly what they see. The difference this time is that we gave them something to see, and they turned into the most thorough bug reporters we've ever had.

What we're not claiming

The strongest honest version: when an agent is pointed at one of our stores, four of the five major agent stacks can query its live catalog through an open standard. Not that agents find the store on their own. Not yet.

• Discovery is still zero. Every agent was handed the URL. No shipping agent discovers /.well-known/ucp unprompted, and our probe saw none in five days across 19 stores. Google and Microsoft find products through Merchant Center feeds, and that work is in progress on our side.
• "Can query it" means "has a sandbox." The dot, Grok and Claude succeeded because each had a computer that can run curl. Claude in a plain chat window is GET-only. Gemini can't POST at all. Discovery is not access, and neither is having an API.
• Catalog only. No agent checked out through UCP. They still buy on the store's own site, where Stripe Link already works for them.
• Qwen overreached. "Any MCP-compatible agent can query directly" is overstated. The semantic search it praised is dormant code. The "crushing online sales" came from our prompt, not from data. Agents flatter the question you ask them.
• Attribution is weak. We can reliably identify OpenAI (signed) and Claude (honest UA). Everyone else is a curl.

What to do this week

• Give your agent a URL, not a question. Ask it to shop your store using its tools, not its browser. If it can only browse, it's reading a month-old copy of you, and nothing you ship this week exists to it.
• Find out whose index you're in. Check your logs for OAI-SearchBot, Claude-User, Google. If the crawler never fetched your agent guide or your feed, no amount of editing them helps until it does.
• Publish a live endpoint and advertise it where agents already look. A UCP profile at the well-known URL, pointed to from the first line of llms.txt and a link tag on every page. Nobody finds it by convention. They find it because you told them.
• Reject or warn on unknown parameters. Every agent that hit us invented a field at some point. A 200 with the wrong results is worse than a 400.
• Count requests to agent endpoints, not agents. You can't tell Muse from Grok from a hobbyist's script. Measure the surface, not the visitor.

What we're thinking about now

Two questions we don't have clean answers to yet.

Is this the new normal? Muse shipped September 8. Dots shipped September 29. Each one cost us a day of testing, fixing, retesting, and a round of same-night bug reports from the agents themselves. If every lab ships an agent with its own quirks, its own cache, its own idea of what a URL is, then being shoppable means re-validating against every new one. That doesn't scale for us, and it definitely doesn't scale for a lighting showroom.

Our bet is that it settles, but not where you'd expect. The protocol layer converges fast: UCP already has Google, Shopify, Walmart and Target behind it, and four of five agents spoke it on day one. The behavior layer doesn't. What each agent caches, which paths it can POST to, whether it signs its requests, how it handles a missing field: that stays fragmented for a while, because it's a product decision inside each lab, not a standard. So the testing shrinks to a conformance harness you run once per agent release, the way you'd test a new browser. We built ours this week. We expect to run it a lot.

Who pays for the free internet when nobody's looking at it? Here's the part that keeps us up. The dot didn't see a sponsored listing, a display ad or a paid search result all day. Neither did Muse. But the dot ran a real Chrome from a real cloud IP, scrolled, clicked, paused at checkout. To every viewability vendor and bot filter we know of, that session was a legitimate human. The ads rendered. The impressions counted. Nobody saw them.

Today that's a rounding error. The go-to pattern for personal agents is now a persistent computer with its own browser, and if that usage grows 10x, the error is still invisible inside the normal noise of fraud. At 50x, the viewability numbers are lying to everyone at once and no one has an incentive to say so. At 500x, the ad-supported web is being read by things that can't be sold to, and the sites that depended on that revenue, the reviews, the forums, the recipe blogs, the local news, the things agents are summarizing for you, have no replacement model.

We spent sixteen years in ad tech before this. The honest answer is we don't know what replaces it. The two candidates we see are paid placement inside the agent's shortlist, which is Meta's play and makes the agent the new ad network, and merchants paying for the catalog pipes themselves, which is UCP's quiet implication and the business we happen to be in. Neither funds a recipe blog. If you've got a third answer, we'd like to hear it.

The part worth remembering

Two weeks ago Muse only reached our store because we named it. This week the dot only reached our catalog because we built the door and handed it the address. The door now exists on every storefront we run, it took an afternoon, and four companies' agents walked through it within fifteen minutes of each other.

The dot itself is the bigger signal. A persistent agent with its own computer, carrying context for days, asking permission at checkout, is what an AI shopper looks like when it stops being a chat window. If these take off, the question stops being whether agents will shop and becomes whose catalog they can read.

Ours, as of 23:42 UTC on October 1. Next time: getting found without being told.

Neural Partners is an AI-native marketing and technology agency founded and based in Vermont. We build on frontier AI platforms every day, as practitioners, not spectators.