Why AI agents reach your site but cannot finish the task

A site can be accessible and easy to understand while its checkout or booking flow still fails. Test what happens between finding an offer and receiving confirmation, including the moments when the customer needs to take over.

Reviewed October 1, 2026 · 8 min read

An agent can read your product page and still fail to buy the product. Access, understanding and task completion are separate parts of the journey. Our 652-site readiness study checked public access and selected machine-readable signals; it did not test whether an agent could complete every business’s checkout or booking flow.

A failed task might come from a blocked request, an ambiguous field, a lost cart or an action the assistant does not support. Diagnose the stopping point before deciding that the solution is more structured data or fewer security controls.

Check access, understanding and completion separately#

Each stage needs its own evidence:

You can instrument all three. Record key steps such as opening checkout, selecting a slot, submitting a form and creating an order. A missing event does not prove why someone stopped, but it narrows the investigation when combined with a controlled test.

Know what the visiting agent can do#

A crawler, a browser agent and an API client do not have the same capabilities. Some fetch HTML, some run JavaScript and interact with pages, and some call tools directly. Test the client your customers actually use rather than assuming all agents behave like a browser or all behave like a crawler.

Product restrictions matter too. OpenAI’s current Cloud browser guidance says it cannot sign in or complete payments at launch. A handoff caused by that limit is different from a broken checkout. Check current support before asking a client to perform an unsupported action.

Common obstacles to completing a task#

Review these parts of the interface using both an unfamiliar human tester and the intended automated client:

Keep necessary consent, authentication and abuse protection. Improve how those controls work in the journey. The goal is a reliable authorized action, not a path that bypasses the checks your business needs.

Review bot defenses using evidence#

Inspect the actual request that failed. Determine whether a CDN challenge, rate limit, application permission or unsupported browser action caused the stop. Changing robots.txt will not repair a checkout error or reverse a firewall decision by itself.

Where supported, verify the agent’s identity before applying a targeted rule. Keep customer authorization and endpoint limits in place. A known operator is easier to recognize, but its requests still need to follow your application’s rules.

Return useful errors and recovery instructions#

Use HTTP status codes that describe the response, with a readable explanation or structured error where appropriate. Agents can inspect response bodies, but they should not have to infer every failure from an otherwise successful status.

Avoid returning a generic failure page with 200 when the requested resource could not be served. Some APIs legitimately represent application-level results inside a successful response, but that behavior must be documented and understood by the client. Check both HTTP success and business success.

RFC 6585 defines 429 for rate limiting and permits Retry-After. The header can give a delay in seconds or an HTTP date. It helps a compatible client plan a retry, although it cannot guarantee that every client will wait or return.

Make the point of commitment clear#

A purchase or booking flow should make clear when a customer is committing. Show the item or service, total, date and material conditions before the final action. Required approval should refer to that concrete summary.

Use labels that describe the result: Place order, Confirm paid booking or Request a quote, as appropriate. A button labeled Continue should not unexpectedly charge a card or confirm a nonrefundable reservation.

After submission, provide a confirmation identifier and a clear status. If processing is still pending, say so. Design retries to avoid duplicate orders or bookings, and give the customer a way to check what happened.

How to test an agent-assisted customer journey#

1. Inspect the public product or booking response. Check which facts are present in HTML and which require a browser or an API.
2. Test the interface with keyboard navigation and accessible labels. Follow the form errors through to a successful correction.
3. Use a test account and sandbox transaction to complete the journey from a fresh session. Check variant selection, totals, timing and confirmation.
4. Repeat with an assistant that supports the intended actions. Record where it pauses, what it asks the customer to do and whether the task resumes.
5. Test an expired session, unavailable item, rate limit and duplicate submission in staging. Verify recovery as well as the error message.
6. Connect the observed stops with request logs and conversion events. Confirm completion in the order or booking system.

Ask a tester who does not already know the interface to repeat the task. Give them the customer’s requirements, not a list of buttons to press. Their observations can reveal assumptions that an owner or developer no longer notices.

Prioritize repeatable failures with clear customer impact. Fix one, repeat the same task and verify the resulting record. Structured data, access rules and interface improvements each have a role; the completed journey is the test that connects them.