Blog · Agents and commerce

Can an agent book, buy or fill in your form

Published 21 August 2026 · Updated 8 October 2026 · 7 min read

Can an agent book, buy or fill in your form
Photograph: Jonathan Cosens Photography / unsplash

The short answer: Sometimes, and rarely in the way you picture it. Two different things are going on. A browsing agent drives your live page with a simulated keyboard and mouse, and it stalls on roughly what a distracted human stalls on. A commerce agent never loads your page at all. It reads a product feed and calls checkout endpoints that somebody at your company had to build on purpose.

Conflating the two is why most "are we agent ready" conversations go nowhere. One is a front-end problem. The other is an engineering decision with a contract behind it.

Two routes in, and only one of them involves your HTML

Route one is the browser. An assistant opens a session, renders your page, clicks things, types into fields and reads what comes back. Your markup, your JavaScript, your validation messages and your bot rules are all in play. What is new is that the thing holding the mouse cannot see colour contrast, cannot phone your sales team, and gives up quietly.

Route two is the protocol. The agent asks a structured question and gets a structured answer, then performs a transaction through an interface designed for it. OpenAI's agentic checkout specification, stamped with API version 2025-09-12, asks a merchant to stand up five REST endpoints: create a checkout session, update it, complete it, cancel it, and fetch its current state. The payment arrives tokenised, and the merchant runs it through the payment service provider they already use. That last detail matters commercially. The money path does not change. The surface where the buyer makes the decision does.

Which route applies to you is not a preference. If you sell physical goods with a catalogue, the protocol route is coming for you whether or not you opt in, and what an agent needs from your catalogue is the version of this problem with prices in it. If you sell a service booked through a form, nobody is building you an endpoint, and the browser is the only door.

What actually stops a browsing agent

We keep a short list from sessions where we watched an agent try and fail on client sites. The pattern is consistent enough to be useful.

Fields that exist only in the eye. A date picker built from div elements with no input behind it, a custom select that never emits a change event, a required field whose label sits in a tooltip. A human infers the widget from its shape. An agent reads the accessibility tree, and if your component is invisible there, the field does not exist.

Validation that fires after the fact. The agent fills eight fields, submits, and gets one red line near the top that scrolls out of view. It has no idea which field was wrong. Humans scan for red. Agents read in order and frequently retry the same wrong value twice before abandoning.

Steps that need a second device or a second person. One-time passcodes to a phone, an email confirmation link, a CAPTCHA, a consent modal from a third-party script. Consumer agents are built to stop at these and ask the person to take over. If your booking flow has two of them, the handover happens twice, and the completion rate in the real world is whatever survives a user being interrupted twice.

Hostile edge infrastructure. A rule written years ago against scrapers now blocks the software your prospect delegated the task to. That is a specific and expensive mistake, and it is why agent traffic is not bot traffic is worth settling with whoever owns your WAF before anyone redesigns a form.

How often does any of this work end to end? Less often than the demos suggest. The Online-Mind2Web benchmark, published on arXiv in April 2025 and revised through October that year, assembled 300 realistic tasks across 136 live websites specifically because earlier evaluations had flattered the field. The authors titled the paper around an illusion of progress. Treat a single successful screen recording as evidence of nothing.

Feeds, because the agent is reading a row, not a page

For the protocol route, the unit of truth is a row. The feed specification lists nine required fields per item: a stable item identifier, a title capped at 150 characters, a description capped at 5,000, a public product URL, brand, seller name, an image URL, an availability value from a fixed set, and a price written in major currency units.

Two of those are where companies quietly lose money. Availability is an enumerated value, not a sentence, and the specification is explicit that a pre-order or backorder status does not schedule any future stock change for you. You update the row or the row lies. Price is the same. There is no mandated refresh interval, which means the staleness of your feed is entirely a function of your own pipeline, and an agent that quotes a price you will not honour costs you a sale and a complaint on the same day.

A useful discipline: diff your feed against your live product pages nightly and count the rows that disagree. That count is a real operational metric, it is yours, and publishing what you learn from it is a cheap way to be cited, which is the argument in original data is the cheapest citation you can buy.

Who authorised this purchase, and can you prove it

The hard problem in agentic transactions is not clicking. It is accountability. If an agent buys the wrong thing, the merchant, the issuer and the user all need to establish what the human actually agreed to.

Two efforts are converging on an answer. Google published the Agent Payments Protocol in September 2025, now at version 0.2 and moving through FIDO Alliance working groups. It wraps the transaction in verifiable digital credentials it calls mandates: one covering the cart or checkout, one covering the payment instrument, cryptographically signed and chained so there is an auditable trail from the user's intent to the charge.

Alongside that sits identity for the request itself. Web Bot Auth signs outbound HTTP requests with an asymmetric key, using HTTP Message Signatures as defined in RFC 9421, carrying Signature-Input, Signature and Signature-Agent headers with Ed25519 keys and a published key directory. The architecture draft from June 2025 is candid about a gap that matters to you: it identifies which automated service made a request, not why, and it does not yet meaningfully separate an agent shopping on behalf of a named human from a crawler collecting training data. Your allow-or-block decision still needs a policy you wrote.

A test you can run this week

Pick your three highest-value conversion paths. For each one, open the flow in an agent with browsing enabled, give it a plain instruction a customer would give, and record four things: did it reach the final step, where did it hand control back, how many steps took more than one attempt, and what did it say about your page when it got stuck. Keep the transcript. Run it again on a different engine.

Then fix in this order: anything invisible to the accessibility tree, anything that blocks the request at the edge, anything requiring a second channel, anything cosmetic. The self-check has the manual version of several of these steps if you want to start without any tooling at all. If you would rather have the comparison done across engines with the evidence attached, how to buy an AEO audit without being sold a dashboard covers what to insist on and what to refuse.

What we cannot tell you yet

Three honest gaps. We do not know what share of real booking attempts come from an agent, because most of these sessions arrive looking like an ordinary browser and send no usable referrer. We cannot predict which protocol wins, and building for all of them is a poor use of an engineering quarter. And agent behaviour shifts with every model release, so a flow that completed in March can stall in June for reasons nobody publishes.

FAQ

Will an agent complete a checkout on my normal website? Sometimes, on a short flow with standard form controls and no second-channel verification. Add a one-time passcode or a CAPTCHA and the agent is designed to hand control back to the person, so completion then depends on whether that person is still paying attention.

Do I need to implement a commerce protocol? Only if you sell a catalogue of goods and the volume justifies the engineering. The work is a product feed plus a set of checkout endpoints and ongoing inventory accuracy. For a services business booked through a form, the browser route is the whole job.

Should I block agents from my forms? Blocking removes the attempt and the signal with it. A better position is to identify signed agent requests, allow the ones you want, rate limit the rest, and log all of it so you can see what is being attempted before you decide.

Does structured data help an agent fill a form? Not directly. Schema markup helps an engine understand what you sell and recommend you. Getting the form completed is a question of accessible form controls, inline validation and how many verification steps stand between intent and confirmation.

Sources

Related reading

Agentic commerce: what an agent needs from your catalogueAgent traffic is not bot trafficOriginal data gives an engine something only you haveHow to buy an AEO audit without being sold a dashboardShopping inside ChatGPT, and what it readsStock, availability and answers that go stale