How to test whether an AI agent can complete your demo-request form

1. Write the task contract before testing

A vague prompt produces a vague result. Write the user goal, allowed actions, required facts, and acceptance criteria in a short test contract. Keep it independent of your implementation so the test reflects what a customer wants.

Goal: Request a product demo for the fictional Team plan.

Allowed: Read public pricing, fill the form with the supplied test contact, and prepare a submission.

Not allowed: Submit or send a message until the test operator confirms.

Done: The form is correctly prepared, or the operator explicitly approves submission and the sandbox records exactly one request.

Include the facts the agent must report: plan name, billing condition, required integration, and any setup requirement. If the agent can complete the form while misunderstanding the offer, the journey has still failed.

Do not grade style. Grade observable outcomes: correct fields, correct values, permitted actions, and a verifiable result. Record the browser, agent, date, locale, viewport, and login state so another person can repeat the run.

2. Build a safe test fixture

Never use a production form to discover whether an agent might click twice or misunderstand a consent field. Point the test at a staging or sandbox endpoint with fake contact data, an isolated inbox, and a database you can inspect.

Use a fixture that resembles the real experience:

• Keep the same field names, labels, validation rules, consent copy, and confirmation page where possible.
• Return realistic delays and server errors under controlled switches.
• Give each run a unique test identifier so a duplicate is easy to find.
• Log request ID, account or test user, timestamp, response status, and stored record ID.
• Make reset and cleanup an explicit operation rather than relying on an agent to undo a write.

Use fake names, addresses, and emails that cannot reach a real person. If a vendor or CRM is connected, use its test mode or a sink endpoint. The test should demonstrate behavior without creating a customer communication.

The test environment is part of the contract. A passing run in a sandbox is evidence about that version of the flow, not a claim that every production path or every agent will succeed.

3. Test discovery and field meaning

Start from a natural request, such as “prepare a demo request for the Team plan.” Do not give the agent CSS selectors or a click script. Watch whether it can reach the form through ordinary links and headings.

Then inspect the page the way an agent may inspect it. Depending on its tooling, it can use screenshots, raw HTML, or the accessibility tree. The web.dev guide on agent-friendly websites explains why those representations can differ.

Every field in the task should have a stable programmatic name, a visible label, an appropriate type, and a clear relationship to its help text. This small example shows the relationship you want to observe:

<label for="demo-email">Work email (required)</label>
<input id="demo-email" name="email" type="email"
       autocomplete="email" required>

It is an illustrative fragment, not a complete implementation. Follow the W3C form-label guidance, then inspect your actual accessibility tree. Check that repeated controls identify their object: “Request Team demo” tells an agent more than three identical “Submit” buttons.

If the computed role or name is unclear, use the DevTools accessibility-tree inspection workflow, then add focused regression checks for the repaired control.

Record the agent’s field map before it types. If it maps “company size” to “company name,” the problem is meaning, even if the server later rejects the value. Fix the interface and rerun the same contract.

4. Test every form state

A successful click is one moment in a longer interaction. Test the states that tell the agent whether it may continue:

Do not treat a green banner as proof that a request was accepted. Compare the displayed state with the network response and stored record. If the UI says “Thanks” after a timeout, that is a defect in the contract between the interface and the server.

Check focus order and status announcements as errors appear. Preserve a user’s entries after recoverable errors, but clear sensitive values when policy requires it. The agent should be able to tell which field needs attention without reading a screenshot pixel by pixel.

5. Test approval and authorization

Separate preparing a request from committing it. Researching a plan or filling a form is not the same as sending a message. Ask the agent to stop before submission, then confirm that it actually stops.

Run at least these cases:

1. A signed-out visitor tries to submit an account-only form.
2. A signed-in test user tries to act on data outside its account.
3. The operator says “prepare this, but do not submit.”
4. The operator later gives explicit permission with the final values visible.
5. The server rejects a request after the agent has prepared it.

Authorization must be enforced by the server. A disabled button, prompt instruction, or hidden field is useful interface context, but it is not an access boundary. Log both the decision and the request so you can tell a safe refusal from a broken flow.

For sites exposing browser tools, the WebMCP security checklist covers consequential actions, untrusted content, cross-origin exposure, and retry behavior in more detail.

6. Verify the actual result

Define the source of truth before you run the agent. It might be a sandbox database row, a queue message, an email sink, or a test CRM record. Capture its identifier and compare it with what the page reports.

A useful evidence bundle contains:

• the original task contract and exact prompt;
• a trace or screen recording of the browser journey;
• the accessible names and values the agent used;
• request and response IDs, status codes, and timing;
• the stored record or explicit absence of one;
• the agent, browser, build, and test-data version.

When a response is uncertain, do not infer success from a network timeout. Query the sandbox by the test identifier. If no record exists, report “not created.” If two records exist, report a duplicate and investigate idempotency before running again.

Keep test data out of public logs and screenshots. Redact tokens, session cookies, and personal information before sharing a trace with a vendor or a bug report.

Use this compact acceptance matrix

Mark each row pass, fail, unknown, or not applicable. Unknown is useful: it tells you that your evidence collection is incomplete. It should not silently become a pass because the page looked right.

7. Repeat, triage, and connect the fix

Run the same task in a fresh session at least once after each meaningful change to fields, consent, authentication, pricing, navigation, or browser tooling. Keep a small history of results so a regression is distinguishable from an untested assumption.

Trace failures from the first divergence:

• If the page is never reached, use the robots.txt and llms.txt comparison to inspect access and discovery layers.
• If the wrong fact is used, compare the initial HTML, rendered content, and structured data.
• If a field is misunderstood, inspect its accessibility name and surrounding structure.
• If submission is unsafe or duplicated, review authorization, confirmation, idempotency, and server logs.

The main readiness guide helps you decide which layer to fix first. If you want a quick baseline before a browser run, the free scan checks public signals only; the API documentation lists its passive limits.

Testing an agent is a product-quality exercise. The goal is not a dramatic demo. The goal is a small, reproducible journey where the agent can explain what it found, ask for approval at the right moment, and leave a verifiable result.