Rules for Interaction Systems in the Age of AI Agent Use

For twenty years, the implicit contract of a web interface was: a human will look at this, infer intent from layout and color and copy, and click the right thing. Bots were an adversarial minority to filter out — scrapers, spammers, credential stuffers. The defenses built for that era (CAPTCHAs, aggressive rate limiting, obfuscated markup, session fingerprinting) all assume the traffic you want is human and the traffic you don't want is automated.

That assumption is breaking. OpenAI's Operator and ChatGPT agent mode, Anthropic's computer use and Claude in Chrome, Google's Project Mariner and Gemini's agentic Chrome features, and a growing field of shopping-specific agents are now legitimate, wanted traffic driving real conversions and signups. Protocols are showing up specifically to give agents a sanctioned way to transact — OpenAI and Stripe's Agentic Commerce Protocol is already processing live purchases for Etsy and rolling out to Shopify merchants, Google and Shopify's Universal Commerce Protocol covers the full shopping journey, and Google shipped an early WebMCP preview in Chrome for structured agent-to-site interaction. That infrastructure is being built in parallel by every major player, which means a site that ignores it is choosing to be the one agents fail on.

That has direct implications for how interaction systems should be built. Below is the set of rules I'd apply if I were designing or auditing one today.

1. Stable selectors and URLs are now an API contract, not a UX nicety

Agents navigate the way early screen readers did: by walking the DOM, matching text, and following links. A UI that reshuffles its DOM structure on every deploy, hides state behind client-generated hash routes, or renders critical content only after a sequence of JS-triggered animations isn't just annoying to a screen reader — it's opaque to an agent that has no way to "just look" the way a human does.

This doesn't mean freezing your frontend. It means treating identifiers as contracts: stable id/name attributes on form fields, consistent data-* hooks, real URLs for real states, so a product page, a filter combination, or a checkout step each has an address rather than living entirely in client memory. If you wouldn't break it for a Playwright test suite, don't break it for an agent — they're doing the same kind of interaction.

2. Dark patterns fail agents and humans for the same reason

Confirm-shaming, pre-checked upsells, countdown timers that reset on refresh, "are you sure you want to leave" modals that require three clicks to actually leave — these work on humans (a little, at a reputational cost) because humans get impatient or feel socially pressured. Agents don't feel pressure. They either have logic to detect and route around the pattern, in which case it does nothing, or they don't, in which case they get stuck in the same loop a confused human would, except now they retry it algorithmically and hammer your endpoint doing so.

Dark patterns were always a tax on trust; agentic traffic just removes the chance that the tax pays for itself in short-term conversion lift. A confusing checkout doesn't manipulate an agent into buying the upsell — it produces a support ticket, a failed transaction, or a user who told their agent "buy this" and is now wondering why it didn't happen.

3. Rate limiting has to model intent, not request velocity

Naive rate limiting keys on requests-per-IP-per-minute. That was a reasonable proxy when the ratio of humans to requests was roughly 1:1. An agent acting on a real task — comparing five product variants, filling a multi-step form, retrying a flaky endpoint — will generate a request pattern that looks identical to a scraping run or a credential-stuffing attempt under that model, and it will get throttled or blocked.

The fix isn't whitelisting known agent user-agent strings — those are trivially spoofed and will always lag behind reality. It's moving the signal from request shape to session shape: is this pattern consistent with one task completed once, with normal backoff on errors, from an identity that can be challenged if needed? Authenticated sessions, proof-of-work challenges scoped to suspicious behavior rather than applied blanket, and anomaly detection tuned to actual abuse patterns (many distinct accounts, no session continuity, no respect for Retry-After) all discriminate on the right axis. Requests-per-minute no longer does.

4. Anti-scraping and agent-friendliness are the same design problem wearing different hats

There's a real tension here and pretending otherwise is dishonest: content owners have legitimate reasons not to want their catalog, pricing, or editorial content bulk-extracted and repackaged elsewhere. But the tools historically used to prevent that — obfuscated class names, canvas-rendered text, JS-only content injection, honeypot fields — degrade the experience for every legitimate agent too, and for humans on assistive tech, which was always the collateral damage nobody priced in.

The more durable answer differentiates by what's being done with the data, not by whether the fetch is automated. robots.txt and its emerging AI-specific extensions, rate-limited but structured API access for anything you'd rather serve as data than have scraped as HTML, and licensing terms enforced at the point of bulk export rather than a single page load — these let you say "one agent looking something up for one user is fine, an unattributed bulk crawl is not" without punishing the former to stop the latter. If your only lever is making the HTML hostile to parse, you're not stopping the sophisticated scraper — it solves the puzzle once and moves on — you're stopping the well-behaved agent.

5. Semantic HTML and structured data are the actual agent interface

Every agent framework I've tested defaults to the same strategy on a page: try the accessibility tree and semantic markup first, fall back to visual/pixel reasoning when that's absent or unreliable. The ARIA labels, <label for> associations, heading hierarchy, and schema.org structured data you'd add for accessibility and SEO are, unglamorously, the same interface an agent uses to understand your form. A <div onclick> styled to look like a button gives an agent nothing but coordinates. A real <button> with a clear accessible name gives it a role, a name, and a state.

This is one of the few places where accessibility, SEO, and agent compatibility are the same work item. There's no tradeoff to litigate — semantic markup is strictly better for every non-agent consumer too.

6. Authorization has to model delegation, not just identity

Login flows assume the entity typing the password is the entity that wants access. Once an agent is acting on a person's behalf — buying something, changing a setting, cancelling a subscription — that assumption splits into two separate questions: who is this acting for, and what, specifically, were they authorized to do?

Password-based auth handles this catastrophically: an agent with a stored password can do anything a human logged in could do, with no scoping. This is exactly the gap protocols like Google's AP2 are trying to close, using cryptographically signed mandates that scope what an agent may spend, on what, and within what bounds, rather than handing over a blanket credential. Whichever protocol wins, the shape of the right answer is clear: scoped, revocable, auditable authorization — closer to OAuth token scopes than to a shared password — with consent made explicit ("this agent may complete purchases up to $200 from this merchant") rather than implicit in the act of logging in. A site that hasn't thought about this is currently relying on users treating their agent's credentials with more care than they treat their own, which isn't a safe bet to make on their behalf.

The throughline

Every one of these rules reduces to the same principle: an interaction system that depends on a human noticing something, feeling something, or being worn down by friction is an interaction system with an expiration date. The sites that will hold up as agent traffic grows are the ones whose forms, checkouts, and auth flows would work identically if you stripped out every pixel and left only the semantics, the structure, and the contract. That was always good design. It's just no longer optional.

Sources:

• The State of Agentic AI Standards in 2026: MCP, A2A, WebMCP, OSI, and the Protocol Stack Taking Shape
• What Is Agentic Commerce? The 2026 Guide
• Agentic commerce — Wikipedia