When Ecommerce Platforms Start Blocking Buyer Agents

Your buyer agent ran clean for six weeks. Then a Tuesday run came back with a page that rendered fine and a click that landed on a promo banner instead of the checkout button. Nothing threw. The run reported success, and the order never existed.

Blocks rarely announce themselves with a 403. What you get is a page that's almost right and a task that fails somewhere downstream where nobody was watching. If you're running agents against retail sites, you're probably already budgeting for that failure. The part worth working out now is what the block costs the platform that installed it, because that number decides how long the block stays up.

The agent side stopped being the expensive part

Jev Ultrafast, a browser agent built by Browser Use and TypeSafe, is a useful reference for where per-step cost has landed. It rebuilds an element table on every observation:

[1] button    Change ticket type · Round trip
[2] combobox  Where from?        · San Francisco
[3] combobox  Where to?          · empty

The policy picks one operation and one target from that table. The operations are CLICK, TYPE_TEXT, SELECT, SCROLL_UP, SCROLL_DOWN, WAIT, DONE, and BLOCKED, and only the ones that apply get offered. The operation decision and the target decision come back in a single network round trip, and only the target matching the chosen operation can execute. Text generation is separate and fires only when the operation is TYPE_TEXT.

A one-way search from Zürich to London on Google Flights took 7.1 seconds, with the generated text and the page loads included. There's a hosted version on a waitlist, so this is heading toward something a team can rent rather than clone.

The detail that matters if you're thinking about blocking: there are no site-specific action scripts in that policy and no prepared field strings. The agent doesn't know it's on Google Flights. It reads what the page shows and numbers it.

A block has to hold still to work

Detection rests on two assumptions. You can tell agent traffic from human traffic, and the signal you're using stays put. The second one is where the cost sits.

An agent that re-observes the page each step takes its footprint from the page. Relabel a button and it renumbers. Change the checkout flow and the element table updates on the next observation. Anything built on static fingerprints has a maintenance problem, which is part of why bot management tools keep adding behavioral scoring.

There's an asymmetry in who pays for the arms race. A block has to run on every request that arrives. The agent's per-step cost is one round trip for the decision and, on most steps, no text generation at all. Making the block harder raises the platform's bill before it raises the agent's.

BLOCKED as a first-class outcome

BLOCKED sits in that operation list as an outcome the agent can choose, which is the piece I'd copy even without running the code. It turns a stall into a reason.

Most buyer-agent stacks have a timeout instead. A timeout can't tell you whether the page changed or the site decided you're a robot, and those need different fixes. You'll spend a week guessing which one you've got.

If you run the store

Before the block ships, route the sessions that fail your bot checks into a separate log and leave them running for two weeks. Look at what those sessions bought and which endpoints they hit hardest. A user-agent filter has a known bypass and a real false-positive rate against privacy browsers, corporate proxies, and anything with an odd TLS fingerprint. Support tickets from those users look like agent traffic until somebody reads them.

If you do decide to block, make the refusal legible. A CAPTCHA tells an agent nothing and tells a person little more. A response that says the request was declined, with a reason code, gives a well-behaved agent something to act on and gives your support team something to quote. It also means the agents that ignore it are the ones you can justify blocking.

Measuring first matters because blocking destroys the baseline. Once the block is live, the traffic you turned away is traffic you can't count, and that count is what you'd need to decide whether to keep the block.

If you're the one buying

Instrument the blocked path before you add another site. The run loop in that library yields a state per step with an elapsed time and a status, which is the least you need to tell a page change apart from a bad decision. Keep the goal in natural language and out of your selectors. A task encoded in CSS paths turns every platform deploy into an outage.

Decide ahead of time what a blocked step does. Handing the task to a person or parking it and telling the requester both work. Retrying into a wall is how a rate limit turns into a ban.

What would change my mind

If platforms shipped a machine-readable way for agents to identify themselves, along with terms an agent can read and follow, detection stops being the default. I haven't seen that adopted at any scale, and nothing in this project speaks to it.

I'd also want a number from the platform side: how much load agent traffic adds, set against the revenue it brings. Without that, a block is a bet placed on the pitch from whichever bot-management vendor is already in the stack. In a category with thin margins and high return rates, blocking can be the right call. In another it hands the sale to whoever leaves the lane open.

The block is a config change. The two weeks of traffic data you'd need to know whether it worked aren't recoverable.