Grok Bot, Meta Muse and OpenAI dots: is your website ready?
On October 6, 2026, we used Codex with Chrome browser controls to complete a small task on IsAgentReady: enter our own website URL, submit the free scan and inspect the returned report. The browser exposed a field named "Website URL" and a button named "Scan Now". After submission, we could verify the domain on the result page and open a dated scan snapshot.
That was one successful browser walkthrough. But a visit involving an expired login or a payment would need its own test. Agent readiness includes completing the task your visitor came for, with the permissions that visitor actually granted.
Grok Bot, Muse and dots bring website actions into the conversation
These products describe personal agents that can work through websites. Their documentation gives website owners concrete behavior to prepare for, although it does not establish identical browser interfaces or support for the same protocols.
Grok Bot uses a persistent cloud computer
The Grok Bot documentation describes a cloud computer with a browser and persistent sessions. Bots use connectors where available and computer use elsewhere. A website can block automation, expire a session or require a human step, which the Bot hands back to the user.
Meta Muse can fill forms and pause for approval
In Meta's Muse announcement , Meta describes a dedicated virtual machine with its own browser. Muse can fill forms and continue working after the app closes. Meta says it asks for approval before sensitive actions such as sending an email or making a purchase.
OpenAI dots has a separate browser session
OpenAI's dots sign-in guide explains that the cloud browser has separate sessions from the user's computer. A dot can request private sign-in or let the user take over. Some websites block cloud browsers or require additional verification.
For your website, a practical consequence is that a visitor's agent may arrive without the login already active on their laptop. Treat authentication as a part of the task, including a way to resume after the person signs in. An approval pause is also a legitimate part of completion.
Readiness includes the steps after the page loads
A product page may be readable while its booking form is difficult to use. A visitor's request to "find a suitable appointment" becomes a sequence of decisions about availability and which action they authorized. Each step needs enough information for the agent to proceed or ask the person a specific question.
Start with the ordinary interface. Give fields persistent labels and buttons names that describe their action. Make required inputs and validation errors visible in the page. If a field requires a particular date format, state it beside that field so the agent can correct a rejected value.
Our accessibility tree guide explains how semantic markup exposes controls to tools that use it. Browser agents can also use screenshots. The sources above do not prove that all three products use the same representation, so test the agent your visitors use.
After submission, show a clear result tied to the requested action. A booking confirmation should identify the appointment; a failed request should explain what the user can correct. If a timeout leaves the outcome uncertain, give the person a way to check the existing request before submitting again.
What our browser walkthrough showed
We started on the public English homepage with the task of scanning https://isagentready.com/en/. Codex used the observed field label to enter the URL and selected the "Scan Now" button inside the main content. That scope mattered because the header also had a button with the same name. The form button became disabled while the request was pending.
The browser then reached the report for isagentready.com. We checked the displayed domain and the scan history, which linked to the October 6 scan snapshot . Those observations let us verify the requested result instead of treating a click as success.
Measure a visitor task on your own website
Choose a task your customers actually perform and define the evidence of success before testing. For an appointment request, that might be a confirmation with the correct date and service. Use a test account and a sandbox when the flow would create a purchase or send a message.
- Record the exact request, agent product and date. Note the browser environment and whether the session starts signed in.
- Let the agent follow the website, with a clear boundary for actions requiring approval. Record where it asks for help.
- Verify the result in the system that owns it. A success message alone can miss an incorrect appointment or an incomplete request.
- Repeat after fixing an observed problem. Include a separate run with an expired session or a validation error, so you also check recovery.
Keep visits attributed to an agent separate from completed tasks. A browser visit does not establish a conversion, and a request in server logs may not identify the product reliably. Business impact needs a link to the actual outcome in your own system.
Use a scan to choose what to inspect first
IsAgentReady checks technical signals such as form labels and button names, plus published protocol information. A static score describes the evidence the scanner observed. The experimental visitor checks are separate from that score; a complete booking or checkout still needs a test of the real flow.
If you expose an API or tool, document its inputs and authorization requirements. Our guides to MCP and WebMCP in compatible browser sessions explain those options. Verify support in the product and environment you test before depending on either protocol.
Scan your website , then choose one important visitor task and follow it through to a verified result. Keep the exact request and confirmation as a baseline, so the next change to your form can be tested against the same task.