--- title: "When an AI agent fills in your form" description: "Chrome's Lighthouse now scores whether an AI agent can read and operate your pages. What the four checks ask for, and which of them are worth the work." url: https://torn.studio/en/insights/when-an-ai-agent-fills-in-your-form locale: en published: 2026-09-29 --- # When an AI agent fills in your form > **Short answer:** An agent reads a form through the accessibility tree, the same surface a screen reader uses. Give every field a real label, every action a real control, and hold the layout still while the page loads. Chrome's Lighthouse scores all three now, and asks for an llms.txt as well. Some of the visitors to a business website are now software working on somebody's behalf: a research agent comparing three suppliers, an assistant asked to book a call, a browser feature that fills in details its user already typed once. Those visitors reach the same contact form as everybody else, and every form they get stuck in becomes an enquiry that never arrives. Chrome publishes a score for this now, which turns a vague worry into something you can check on a Tuesday afternoon. ## What does the agentic browsing check measure? Lighthouse — the audit built into Chrome DevTools and the engine behind PageSpeed Insights — carries a category called Agentic Browsing. It looks at four things: whether the page registers WebMCP tools, whether the accessibility tree gives an agent the names and labels it needs to act, whether the layout holds still while the page loads, and whether the site publishes an llms.txt. Two details matter for how much weight to put on it. Google reports the result as a ratio of checks passed, so there is no single number to chase, and the documentation marks both the category and its WebMCP support as experimental and based on proposed standards. Running it at all requires Chrome 150 or later. So the score is a checklist that has been given a home, and the checklist is the useful part. ## Why does the accessibility tree decide whether an agent can act? Chrome's own guidance is blunt about the mechanism: agents review the accessibility tree to identify interactive elements. That is the same structure a screen reader walks — element roles, accessible names, labels, whether a control is visible and reachable — built from the semantics of the page. So the failures are the familiar ones. A field labeled only by placeholder text has no name once the text disappears. A submit control built as a styled div listening for clicks is invisible as a control. A step that only appears on hover is a step an agent never finds. In each case the agent stops exactly where a person using assistive technology stops, for exactly the same reason. That overlap is the good news in all of this. Labels, keyboard paths and a stable layout are what WCAG asks for, and what the European Accessibility Act has asked of the products and services it covers since 28 June 2025. They are also what makes a form survive a phone on a train. One budget line covers both audiences. The reading half of the question — which bots to allow and what robots.txt still governs — is covered in [how AI crawlers and agents read your site](https://torn.studio/en/insights/ai-crawlers-and-agents-on-your-site). This is the acting half. ## Should we register WebMCP tools yet? WebMCP is the one check of the four that asks for new code. It is a browser API that lets a page declare its own capabilities to an agent as callable tools — search the catalog, check availability, submit this enquiry — so the agent calls a named function with typed arguments and skips guessing at the DOM. It is also the least settled thing on the list. The specification is published as a Draft Community Group Report by the W3C Web Machine Learning Community Group, edited by engineers at Google and Microsoft, and the document says in its own status section that it is neither a W3C Standard nor on the W3C Standards Track. The draft on the page today is dated 17 September 2026. Torn Studio decided on 21 September 2026 to register no WebMCP tools on torn.studio, and to keep the agent surface at an llms.txt plus a markdown version of every page, served at the page's own URL with a .md suffix. What that costs is worth stating plainly: the site fails the WebMCP check, and an agent that wants to reach the studio drives the ordinary contact form like everybody else. The reason is that a tool contract is a promise. An agent that calls a named submit function expects it to keep working, and making that promise in nine languages against a draft that moved this month is a maintenance commitment running ahead of the demand for it. Two things reverse the decision, and both are written down: the API leaving draft, or agent traffic in a real funnel large enough to pay for the upkeep. ## What is an agent-submitted enquiry worth? An enquiry an agent filled in is a real enquiry: the agent did it for a person, and it is the person who wants an answer. The qualification is thinner than it looks, because the fields carry what the agent inferred from the page it was reading. Two things follow. Ask for facts an agent can carry accurately — company, country, what the work is — and leave the judgment calls to the reply. And separate the populations in analytics at the point of capture. An agent session counted as an ordinary one lifts the conversion rate on the dashboard while the quality of what lands in the inbox falls, and the two movements hide each other. ## Where should we start? The work splits into an afternoon, a sprint and a decision to postpone. - Run Lighthouse on the page carrying your enquiry form, in Chrome 150 or later, and read the agentic browsing row. - Complete that form yourself with the keyboard alone. Anything that stops you stops an agent. - Give every field a real label and every action a real button, and hold the layout still while the page loads. - Publish an llms.txt naming the pages you want an agent to use, and serve a markdown version of each of them. - Tag agent sessions separately in analytics before the comparison is needed. - Leave WebMCP for now, and write down the condition that would change your mind. None of the first five is speculative work. They are the same items an accessibility audit produces, aimed at a second audience that has started showing up. [The websites we build](https://torn.studio/en/services/websites) ship with the accessibility tree and the markdown mirrors in place from the first deploy, which is why the agentic browsing checklist mostly reads as already done. **Read next** - [How to structure a landing page that converts](https://torn.studio/en/insights/how-to-structure-a-landing-page-that-converts) - [Winning customers when AI answers first](https://torn.studio/en/insights/winning-customers-when-ai-answers-first) - [How to appear in AI-generated answers](https://torn.studio/en/insights/appearing-in-ai-generated-answers) ## Common questions ### How do we test whether an agent can use our site today? Run Lighthouse on the page that carries your enquiry form and read the agentic browsing row. Chrome's documentation says the category needs Chrome 150 or later. Then do it by hand: complete the whole form with the keyboard alone, and see whether every control announces what it is. ### Does an enquiry submitted by an agent count as a lead? It is a real enquiry, because an agent fills a form for a person who asked it to. The qualification is thinner: the fields carry what the agent inferred from the page it was reading. Treat it as a lead with the detail still to be confirmed, and tag the source at capture so the two populations stay separable. ### Do we need an llms.txt file? It is one of the four things the agentic browsing category checks, and it costs an afternoon: a markdown file at the root naming the pages you want an agent to use. The proposal has been public at llmstxt.org since September 2024, and Chrome's documentation files the check under discoverability: it looks for a machine-readable summary at the domain root. ### What is WebMCP? A browser API that lets a page declare its own capabilities to an agent as callable tools, so the agent invokes a named function with typed arguments. It is published as a Draft Community Group Report by the W3C Web Machine Learning Community Group, and the document states that it is neither a W3C Standard nor on the W3C Standards Track. ### Will building for agents make the site worse for people? No, it gets better. Three of the four checks have been WCAG requirements for years, and since 28 June 2025 the European Accessibility Act asks the same of the products and services it covers. Someone using a screen reader notices first, someone on a train notices second. The agent is the third to benefit, and the one paying for the work. ### Should we block agents from our forms? Blocking is a decision about spam and cost, and it is separate from whether the form works. Decide who is welcome first, then make the path work for whoever you let through. A form that defeats an agent defeats a keyboard user too. ## Sources - [Agentic browsing — Chrome for Developers](https://developer.chrome.com/docs/lighthouse/agentic-browsing) — Source for the category checking WebMCP integration, agent-centric accessibility, layout stability and llms.txt, and for llms.txt being checked as a machine-readable summary at the domain root. - [Lighthouse agentic browsing scoring — Chrome for Developers](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring) — Source for the score being reported as a ratio of checks passed, for the category and WebMCP support being marked experimental and based on proposed standards, and for the Chrome 150 requirement. - [Accessibility for agents — Chrome for Developers](https://developer.chrome.com/docs/lighthouse/agentic-browsing/accessibility-for-agents) — Source for agents reviewing the accessibility tree to identify interactive elements, and for missing labels blocking both agents and people using assistive technology. - [WebMCP — W3C Web Machine Learning Community Group](https://webmachinelearning.github.io/webmcp/) — Source for WebMCP being a Draft Community Group Report edited by engineers at Google and Microsoft, for its status outside the W3C Standards Track, and for the draft carried on 17 September 2026. - [The /llms.txt file — llmstxt.org](https://llmstxt.org/) — Source for the llms.txt proposal and for it being public since September 2024. - [Directive (EU) 2019/882 — the European Accessibility Act, EUR-Lex](https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng) — Source for the accessibility requirements applying to the products and services the directive covers from 28 June 2025.