Can an AI agent actually use your product?
By Lindsey J
Agents are already browsing on your users' behalf
In January 2025, OpenAI launched Operator, an agent that browsed the web with its own browser. It worked by taking screenshots to see a page and using mouse and keyboard actions to interact with it. No site needed a custom integration for Operator to use it.
By July 2025, OpenAI had folded that capability into ChatGPT itself, as ChatGPT agent. In the same post, OpenAI announced the standalone Operator product would sunset in the coming weeks. The product name did not last a year. The capability moved into the assistant people already had open.
OpenAI folding Operator into ChatGPT agent within six months shows the pattern to plan for. Agent-driven browsing will not stay a niche integration a team opts into once. It can show up inside your product before your team has built anything for it.
The same structure a screen reader needs is what an agent needs
Accessibility work already answers a version of this question. The accessible name of an interactive element has to come from something real: visible text, an aria-label attribute, or an associated label element. It cannot come from a CSS class or a background image alone. The W3C's Web Accessibility Initiative documents exactly how that name gets computed, in its guidance on names and descriptions.
A screen reader reads an element's accessible name aloud, along with its role and its current state if it has one. A browsing agent is asking a close version of the same questions, whether it is working from a screenshot, the page's accessibility tree, or both: what is this, and what does it do.
Picture a travel booking site where "add to cart" is a square icon with no visible text and no accessible name, styled only through a background image. A sighted visitor reads the icon. A screen reader announces "button" and nothing else. An agent clicking through the same flow is left with the same gap: no name to reason from, only a guess from the surrounding pixels.
Picture a B2B analytics dashboard where the date range filter only works through a custom drag selector, with no keyboard equivalent and no exposed role. A mouse user barely notices. A screen reader user and a browsing agent both cannot select a range at all.
This is not the same job as answer-engine optimization
Answer-engine optimization is about being cited correctly when a model summarizes an answer for someone who never visits the page. This is a different problem. It is about what happens after an agent does land on the page and has to do something there: fill a field, choose an option, complete a flow. Both are forms of agent readiness. A product can pass one and fail the other.
A test for whether an AI agent can use your product
Run this before building anything agent-specific
- Tab through your core conversion flow using only the keyboard. Note the first place you get stuck.
- Check every button and icon-only control for a non-empty accessible name, not just a visual label.
- Check whether custom components such as a date picker, a multi-select, or a modal expose their role and current state through ARIA, rather than only through a CSS class.
- Ask whether anyone on the team already knows if an AI agent has completed your signup or checkout flow, or whether nobody has checked.
If the keyboard-only walkthrough fails before an agent would even need to try, fix that first. It is the same underlying structure a screen reader, a keyboard user, and a browsing agent all depend on. One fix serves all three. An agent-specific patch helps only the one agent it was built for.
FAQ
Is this just accessibility compliance with a new name
It depends on the same structure: a name, a role, and a state. The accessibility work your team already tracks covers much of this ground. It is still worth tracking separately, because the trigger is different. A legal or policy deadline usually drives compliance work. Agent readiness is driven by whether a channel your team did not choose, agent-mediated browsing, can complete a transaction at all.
Do we need a dedicated API for agents instead
Sometimes, for a high-value checkout flow, a dedicated interface is worth building. For most of a product, fixing the interface a human already uses is cheaper. It also serves every assistive technology and every agent at once, instead of one integration at a time.
How do we know if an agent has actually completed our flow
Instrument it the way you would any new channel. Where it is available, watch for a distinguishable user agent or referrer. Separately, run whichever agentic browsing tool you already use through your own core flow by hand. Log the result like a test. Treat that result as a baseline to recheck, not a one-time check, since the tools themselves have already changed once since Operator's launch.
If nobody on your team can answer the checklist above today, that gap is the project, not a side effect of one. Get in touch and we will show you exactly where your core flow breaks first.
Sources
- OpenAI, "Introducing Operator" (January 23, 2025, updated July 17, 2025): https://openai.com/blog/introducing-operator
- W3C Web Accessibility Initiative, "Names and Descriptions," WAI-ARIA Authoring Practices Guide: https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions
