I built a trap for Meta's Muse

Updated 24 September 2026. The experiment is closed. No Muse user ran it, so this post now reports what the trap did catch, and what changed while it was open.

Short version: Meta's Muse shops through its own browser, and nobody had published what that traffic looks like when it reaches a storefront. I built a store to capture it and asked Muse users to point their agent at it. For four days, none did. The trap still caught something useful: a side-by-side of an AI-driven browser and a real one doing the same task on the same laptop, and a stream of link scanners that claim to be Chrome and never run a line of JavaScript. And halfway through the week, Shopify changed the question.

The question, stated precisely

Not "is AI traffic growing" — that's been answered repeatedly and it isn't interesting anymore. The question is narrower and, as far as I can tell, still open:

When Meta's Muse visits an ordinary storefront, is that request distinguishable from a human's at the point it arrives?

There are only three possible answers and all of them are worth knowing.

It announces itself. There's a token in the user agent, or the traffic comes from an identifiable network. Then it's a registry entry, everyone can detect it tomorrow, and the story is a small useful one.

It's identifiable but not announced. No label, but a consistent tell — a missing header, a TLS fingerprint, an environment that doesn't add up. Then detection is possible but only for tools that look past the user agent.

It's genuinely indistinguishable. It's a real browser doing real browser things, and at the request layer it looks like a person on a Mac. Then every user-agent-list product on the market is structurally blind to it, and the only thing that can see it is something that scores behaviour rather than labels.

I still don't know which it is for Muse. What follows is what I can say.

Why I couldn't run it myself

Muse is US-only and I'm in India. I couldn't produce a single Muse data point personally, so the experiment had to be public: a honeypot anyone could point their own agent at, with the method published before the results.

What Muse actually is

Muse is Meta's personal agent, launched on 8 September 2026 and currently US-only. The part that matters to merchants isn't the chat interface — it's that Muse has its own browser, running in Meta's infrastructure, which it drives on a user's behalf. You ask it to find you a jacket; it opens pages, reads them, and comes back with an answer.

Ten days later, on 18 September, Meta opened Muse Connectors to developers: a structured integration through which a partner merchant can expose catalog, availability and checkout to the agent directly, without it having to read HTML at all.

Those two facts together are the whole story, and the second one is what makes people misread the first.

Why a store that isn't a partner still gets visited

The intuitive model is that agent traffic is something you opt into. You integrate, you show up; you don't, you're invisible. That model is wrong, and it's wrong in the direction that costs merchants money.

A connector is a fast path, not a gate. When an agent has a structured integration with a merchant it will use it, because structured data is cheaper and more reliable than parsing a storefront. When it doesn't — which is to say, for nearly every store on the internet — the agent still has a browser, and the user still asked a question that your product is the answer to. So it browses.

This is the same architecture every operator-class agent has converged on. OpenAI's Operator works this way. Anything that can both call an API and drive a browser works this way, because the alternative is telling the user "I can only shop at eleven stores."

The practical consequence: agent traffic is not a thing you opt into. It's a thing that is already happening to you, at whatever volume the agent's users generate. The only decision you actually get is whether you can see it.

What each kind of tool can and can't see

Merchants generally have three things pointed at their traffic, and it's worth being precise about which of them can register an agent-browser visit at all.

	Named crawler (GPTBot, PerplexityBot)	Agent browser (Muse, Operator)
Server logs / UA-list tools	Yes — it identifies itself	Only if it identifies itself
GA4 and similar	No — most crawlers don't run JS, and known bots are filtered	Depends entirely on whether it's classified as a bot
AEO / citation trackers	N/A — they query models, not your server	No — they never touch your store
Behavioral detection	Yes, when JS runs	Yes — it scores the session, not the label

Read the second column carefully. Every row except the last is conditional on the agent volunteering its identity. That's a design decision made by someone who isn't you, and it can change in either direction without notice.

This is not a claim that user-agent lists are useless — they're how you catch GPTBot, and GPTBot is most of the volume today. It's a claim about which tool answers this question. A user-agent list can only ever tell you about agents that have agreed to be counted.

What happened

The store recorded every request from 20 to 24 September 2026. No Muse user ran the task. Everything it did capture:

Visitor	Runs	What it was
A person doing the task by hand in Chrome	1	the baseline
An AI assistant's built-in browser, driven by the assistant	1 clean run	the closest stand-in for an agent browser I could run from India
Visitors to the example link printed in this post	13	link scanners: a Chrome user agent, no JavaScript, one page, rotating hosting networks in six countries

Two of those rows turned out to be worth writing up.

One comparison, on one laptop

The person and the AI-driven browser ran on the same laptop and the same home connection. That matters: it holds the hardware and the network constant, so anything that differs comes from the browser and the hand, not the machine.

Layer	AI-driven browser	Real Chrome
Client-hint headers (sec-ch-ua and friends)	absent	present
Browser brands the page can read	Chromium only	includes Google Chrome
accept-language	one language	a weighted list
Screen size the page can read	0 × 0	1536 × 864
Mouse movement per page	none	12 to 303 events
Keystrokes on the checkout form	none, and the form was submitted filled	68
Scrolling on product pages	0 to 1 events	7 to 54
Graphics card and canvas fingerprint	identical	identical
Tactical's verdict	agent, score 65	person, score 0

What that shows:

• Three request-layer tells survived a CDN. Cloudflare sat in front of the store and passed the client hints through for real Chrome. A browser that carries a Chrome user agent but no client hints and no Chrome brand is telling you it isn't Chrome.
• The strongest tells were behavioural. Clicks with no mouse movement before them, and a form that filled itself without a keystroke. A person can't click a mouse without moving it.
• Our own detector missed it at first. The first run scored 10, a person, because a single click switched off the "no mouse" signal. The more agent-like the session, the less it scored. That's fixed: the same session now scores 65 and the person still scores 0.
• The hardware tells were silent here, and that's the point. Same laptop, same graphics card, same fingerprint. A Muse browser running in Meta's datacenter would add network and graphics tells this pair couldn't show.

This is one comparison, not a study, and the AI-driven browser announced itself in its user agent. It is not a measurement of Muse. It is a measurement of what separates a driven browser from a person when everything else is equal.

The quiet finding: the scanners

Thirteen visits followed the example link printed in this post. Every one claimed to be Chrome, none ran JavaScript, each fetched a single page and left, and they came from hosting networks rather than homes.

A JavaScript tag never sees these visits. A user-agent list counts them as people. Only something sitting in the request path sees them for what they are. That's the whole measurement problem in miniature, produced for free by the act of publishing a URL.

What changed on 21 September

Halfway through the week, Shopify announced that every merchant's catalog is available to Muse and that Muse checks out through Shop Pay on Meta's side. For a Shopify store, a Muse purchase no longer needs the storefront at all: the order arrives in the admin attributed to Meta, and no pixel fires, because the page never loads.

So for most stores the question moved. It's less "what does Muse look like when it visits?" and more "what did agents buy, and would I have known?" That's an order question, and it's answerable from the order itself. Stores that aren't on Shopify, which is most of WooCommerce and every custom build, still get browsed, and the comparison above is the one that applies to them.

Why it's closed

The bottleneck was people, not code: it needed US users with Muse access willing to spend a minute on a stranger's experiment, and four days produced none. More time on the same channels wasn't going to change that, and leaving an open invitation that nothing records would be worse than closing it. The store is still up. If you have Muse access and want to run it, email [email protected] and I'll switch capture back on for your run.

What a merchant should actually do about this

Four things, in descending order of how much they matter and ascending order of how much work they are.

1. Stop assuming your analytics are complete. The single most expensive belief in this area is that a flat line in GA4 means nothing is happening. GA4's job is to measure humans and exclude everything else; it does that job well. It is the wrong instrument for this and it will never say so.

2. Get something into your request path. Everything downstream depends on this. If you only have a JavaScript tag, you can see agents that render pages and nothing else — and the non-rendering case is exactly the one that's growing. A plugin, a middleware, or a worker at your edge; it doesn't much matter which, and it doesn't have to be ours.

3. Make your pages answerable without a human. Complete, current schema.org Product data — price, availability, SKU — is what an agent reads when it can't use a connector. This is ordinary SEO hygiene that happens to have become agent hygiene. If your structured data says a product is in stock and it isn't, an agent will confidently recommend something you can't ship.

4. Judge integrations on evidence, not announcements. Connector programs are real and will matter. But "should I integrate with X" is a question about your own traffic, and you can't answer it from a press release. Measure first, then decide what a partnership is worth to you.

Methodology

Everything above comes from a public honeypot rather than from customer data, deliberately — the whole thing should be reproducible by someone who doesn't trust us.

The store. A storefront at tactical-app.work/demo: ten products with genuine prices, stock levels and structured data, a working cart, and a checkout that stops before any payment step. Nothing ships and no payment details are collected anywhere in the flow. It runs the same detection snippet our customers install, so its behavioral classification comes from the production pipeline rather than a special case.

What was captured. For every request: the complete header set and every value, the client IP and its network operator, the TLS version, cipher and JA3 hash of the connection, and — when JavaScript executed — the browser environment (navigator surface, screen and timezone, GPU renderer string, a canvas rendering hash, the automation flags a browser exposes about itself) plus a timing trace of navigation, clicks and scrolls. Two independent capture paths: the store's own server, which records a visit whether or not scripts run, and a client probe, which only sees visits where they do. The difference between those two sets is itself a measurement.

How runs were isolated. Each run carried a unique ?run= code in the task it was given. That's what makes a session attributable to a known run even when the request looks entirely ordinary — without it, a perfectly human-looking agent visit is indistinguishable from a human visit by construction, and no amount of analysis fixes that.

The baseline. A human session on the same store, captured identically, by a person doing the same task by hand. Every claim about what makes agent traffic distinctive is a claim about a difference from that baseline, not about an absolute value.

What we didn't keep. No typed text — the timing trace records that a key was pressed and when, never which character. No checkout details: the name, email and address submitted to the sandbox checkout are discarded, and only the shape of the submission is retained. Raw IP addresses are not published anywhere in this post. Captured rows are deleted 30 days after capture, and any run could be deleted on request, no questions asked.

Limitations, stated plainly. This is one comparison on a single store, over four days. A honeypot is also, unavoidably, a store with no purchase history and no reputation; an agent may treat it differently from an established merchant. Nothing here is a measurement of Muse's behaviour. It is a measurement of what a store can see, published because nobody else has published anything.

Reproduce this

Capture is closed, but the store is still up and the methodology above is complete enough to rebuild. If you run a store and want to check your own traffic for this, the coverage question is the only one that really matters: is anything you own sitting in your request path? If the answer is no, the honest state of your knowledge about agent traffic is that you don't have any.

Tactical does this as a product — first-party analytics on AI crawlers, agent sessions, the orders agents place and AI-referred revenue, with a free tier — and lets a store decide what agents may do once it can see them. But the measurement principle stands whether or not you use us, and we'd rather merchants measured this badly than not at all.