The pages an agent reads best are often the ones built for people who never see the page. That isn’t luck, and your company has been through a version of it before.
A user arrived whose way of perceiving a page differed from the one designers had in mind. A screen reader can’t use a layout. It needs to be told what each element is: a button has to say it’s a button, a field needs a label, a heading has to mark where a section starts.
That forced sites to declare structure they had only ever implied. A styled div looked like a button, and a sighted person never needed to be told.
Browser agents have the same need. Some of the tooling that drives them, Playwright’s MCP server among it, reads the page through its accessibility tree: a text outline of roles and names, acted on instead of pixels. A control with no declared role is hard for that agent to describe and easy to miss.
Two kinds of company came out of the first wave.
Some treated accessibility as compliance. Audit, fix what was cited, file the report. Same architecture, plus a certificate.
Others treated it as a property of how things are built. Every later change, from mobile layouts to search to automated testing, had better material to work with.
The fork is open again, and the mechanism is the same: stating out loud what used to be left to the user’s judgment. A person could tell which of three lookalike buttons was the real one. An agent has only what was declared.
I’m not saying an agent is an assistive-technology user, or that the needs match one for one. The claim is narrower. The work that made a page understandable to one unexpected kind of user ended up paying for others.
A test you can run this week: take the most important flow on your site and complete it with a keyboard and a screen reader. Wherever you get lost is a good place to start looking for what an agent will miss.