Sub-grade

Usability — can AI agents actually use your product?

Usability is the AAIO sub-grade covering whether agents can complete actions on your site once they've reached and understood it. Checkout flows, search, faceted nav, cart accessibility, booking, inquiry/contact flows, agent API specs. Most sites are designed for human attention spans and fail silently when an agent tries to use them. Five scored parameters.

By Chris Mühlnickel · 2026-05-04

What is Usability?

Usability (in AAIO) is the set of interaction-layer signals — flow stability, accessibility under bot UA, predictable error handling, agent-callable APIs — that determine whether AI agents can successfully complete the actions they're trying to take.

By the numbers

Why it matters

*Agents do active interactions — not just retrieval.* Search, add-to-cart, fill forms, book, route messages. The bar at the Usability layer is conversion, not citation. A site that's perfectly indexed and beautifully marked up but ships a checkout that breaks under bot UA loses the user at the moment of value capture. The Visibility and Clarity work compounds; the Usability failure cancels it.

Many sites silently degrade when accessed under non-human UA. Bot fingerprinting at the CDN, captcha walls on critical actions, 429 responses to legitimate agent traffic, focus-trap modals that lock CUAs in the same way they lock keyboard users. These are revenue leaks once agent traffic shifts. Most sites in our calibration corpus weren't designed to handle non-human interaction; the failure modes are silent and broad. The fix is structural — you can't bolt agent-friendliness onto a fundamentally adversarial frontend.

*Faceted navigation that requires JS hover states, modals that trap focus, error messages that say "Something went wrong" — all of these are agent-killers.* And all of them are also accessibility failures. The 97% faceted-nav failure rate in our e-commerce corpus is the same 97% that fail WCAG-AA filtering. Sites that solved accessibility are halfway to solving Usability for agents; sites that haven't have two distribution problems for the price of one.

API-first SaaS has a much shorter path to agent-usability than DOM-first SaaS — but DOM-first sites can still get most of the way with deterministic flows + clear error states. The 80% of API-first sites in our corpus that fail the agent-callable API check mostly haven't packaged their existing API as an MCP server. Most have an OpenAPI spec; few have curated MCP tool descriptions. The gap between "we have an API" and "we have an agent-callable API" is small but real.

*The economic prize is high — an agent that completes checkout 90% of the time on your site vs. 60% on a competitor's becomes a default routing decision by the agent's parent system.* This is the long-tail compounding that the Adobe 4,700% YoY agent-traffic growth (cited in Agent Commerce) implies. The agent at the top of the funnel makes a routing decision based on past completion rates; the routing decision repeats for every user the agent encounters in that vertical. Defaults harden. Today's reliable site is tomorrow's default.

Sub-topics

The six scored parameters in the Usability sub-grade

  • U-API Agent API Spec + Sandbox + Rendered Docs — Does your service expose a public OpenAPI / MCP-friendly schema? Are auth patterns clear and scoped? Is there a sandbox environment for agents to test against without affecting production data?
  • U-FIL Faceted Navigation Usability — Does your filter / faceted-nav UI work without JavaScript execution? Are filtered views accessible via stable URLs that agents can construct or follow?
  • U-CART Cart Accessibility — Does your cart page work under bot UA? Is the add-to-cart action reachable via a stable URL or POST endpoint? Does cart state persist correctly across an agent's stateless requests?
  • U-BOOK Direct Booking Flow — Is your booking flow agent-completable on your own site? Are time-slot availability + reservation actions exposed via structured endpoints or scrapable HTML rather than JS-only widgets?
  • U-INQ Inquiry / Contact Flow — Is your contact / inquiry form completable by an agent? No bot-fingerprinting that catches legitimate UAs, predictable validation, machine-parseable success/error response, no honeypots that trap agents.
  • U-RESV Marketplace Bookings — For marketplaces with multiple hosts/vendors: is inventory unified across the network? Can agents reserve a slot without per-host integration hand-offs? Is the booking confirmation machine-parseable?

Where it's heading

Idempotency promotes from Frontier to scored. Idempotency / retry-safety (an Agent Intelligence Frontier watcher) is the most likely to promote — when agent traffic share crosses ~5-10% of POST volume on a representative sample, retry-safety becomes a scored Usability parameter with a power-cap.

Agent-callable APIs become a baseline expectation. The pattern is converging: services that don't ship an MCP server stop appearing in agent-mediated workflows. Today, lacking an MCP server is a small disadvantage; in 2027, it's a hard fail for action-taking agents on the major platforms.

*Computer-use-agent reliability ceiling becomes the site's UI stability rather than the agent's model quality.* OSWorld scores have tripled in 18 months; the bottleneck is shifting from "the agent can't navigate" to "the site is too unstable to navigate." Sites that ship semantic HTML, stable selectors, and clean state machines pull ahead structurally.

Multi-agent flows on the same site. Today, an agent acts on a site for one user at a time, sequentially. Tomorrow's pattern: multiple agents acting concurrently (a personal assistant + a shopping agent + a CUA) all touching the same flow. Sites built for single-user-one-tab break here. Sites built with idempotent endpoints, predictable state machines, and clear concurrency semantics work.

Self-healing UI patterns. Sites that detect retry-in-flight, surface clearer state ("we're processing your previous request"), and degrade gracefully under partial-failure conditions are emerging as the high-leverage UX pattern for the agent-traffic era. Stripe Checkout does this; the rest of e-commerce will follow.

Common mistakes

  • Bot-fingerprinting that blocks legitimate agents. Cloudflare bot-fight, AWS Shield, Akamai bot manager all default to flagging non-human UAs as adversarial. Configure for AI-agent allowlist or accept the silent traffic loss.
  • Modals with focus traps. Lock CUAs in the same way they lock keyboard-only users. Use role="dialog", manage focus correctly, and provide a stable Escape path.
  • JS-only faceted filters. The single most common Usability failure in our corpus. SSR your filtered views or accept that 97% of agent-driven shopping comparisons won't reach the filtered set.
  • Generic error messages. "Something went wrong" helps no one. Use HTTP status codes correctly + structured error codes in the response body.
  • CAPTCHAs on every form. Most break legitimate agents. If you need bot defense, use rate limiting, login-gated actions, or HTTP-Message-Signature-based agent identity rather than reCAPTCHA on every form submit.

Frequently asked

What does 'agent-friendly checkout' mean concretely?

Five things, in order of leverage: (1) guest checkout works (no mandatory account creation step), (2) prices and stock are server-rendered (not waiting on a JS API call), (3) error responses are structured (HTTP status code + machine-parseable error code + human-readable message), (4) no bot-fingerprinting at the cart or payment layer, (5) idempotent POST endpoints so agent retries don't double-charge. None of these hurt human conversion; all of them improve it. The first two alone fix the top reasons our calibration corpus shows e-commerce carts breaking under bot UA.

Should I expose an API specifically for agents, or will my human-facing one work?

Both. Your human-facing API often works well enough for retrieval (read endpoints) but breaks for action (write endpoints) — agents need clearer auth scopes, better error responses, and idempotency on POSTs. The right pattern for most sites: publish a stable OpenAPI spec → expose it as an MCP server with curated tool descriptions for the LLM-as-reader → keep your human-developer API documented the way humans expect. Two surfaces, one underlying API. The 80% of API-first sites in our corpus that fail this haven't done the MCP-server packaging work.

Do agents respect rate limits? How aggressive are they?

Mostly yes, increasingly. Modern agents (ChatGPT, Claude, Perplexity) implement backoff and retry with respect to 429 responses. Computer-use agents (Operator, Computer Use, Project Mariner) are slower than API agents — they're driving a browser, which is naturally rate-limited by render time. The aggressive failure mode is older agent frameworks or self-built ones; the well-known agents are well-behaved. Treat rate limits as a defense against misbehavior, not a tool against legitimate agents.

How do I know if my faceted nav works for agents?

Test with curl + a JS-disabled browser. If your filters require JavaScript to populate or to apply, agents that don't execute JavaScript can't use them. The fix is server-rendered URLs for filtered views (/products/category/blue-shoes/size-10/ should be a real URL that returns the filtered set, not a JS state mutation). Faceted-nav SSR is the single biggest Usability win for e-commerce in our corpus — 97% of sites fail it, and most have legacy JS-heavy filter implementations they could swap.

Should error messages be different for agents vs. humans?

No — the same error structure should serve both. The pattern: HTTP status code (machine-readable), machine-parseable error code in JSON body (e.g. {"error": "insufficient_inventory", "message": "Only 2 left in stock"}), and a human-readable message. Humans see the message; agents read the code; both work. The failure mode is generic 'Something went wrong' responses that give neither audience anything to work with.

What's the deal with computer-use agents (Anthropic CUA, OpenAI Operator) vs. headless API agents?

API agents call structured endpoints (your REST API, your MCP server). Computer-use agents drive a sandboxed browser and click around. The two are complementary: API agents are faster and more reliable for sites that expose APIs; CUAs are the only option for sites that don't. Most sites should ship both — an MCP server for the API path, and stable semantic HTML for the CUA path. CUAs are improving fast (OSWorld scores up 3× in 18 months) and are the bridge for sites that can't or won't expose APIs.

Will agents pass CAPTCHA challenges?

Sometimes. Computer-use agents can solve some image CAPTCHAs (Anthropic and OpenAI both report this). Most reCAPTCHA v2 challenges fail. Cloudflare Turnstile blocks most agents by default. The strategic move: don't gate critical actions behind CAPTCHAs — either require login (a clearer authorization signal) or trust HTTP-Message-Signature-style agent identity. Spekto's calibration corpus shows CAPTCHA-gated forms as one of the top three Usability blockers across verticals.