Agent engine optimization best practices are ways to improve website infrastructure to let AI agents perform tasks on behalf of user’s input.
1. Make Every Necessary Action Visible in the User Interface
The UI should always show what’s happening and what’s possible. Nothing should be invisible or implied. In practical terms:
For state changes: If an action does something such as adds an item to cart, submits a form, toggles a setting, the interface must visually confirm it happened. No silent background operations.The state change needs to actually live in the HTML/accessibility tree in a stable, lasting way,not just flash for a second and disappear. A brief toast notification is fine for humans, but an agent reading the DOM a moment later would see nothing.
For available actions: Every action a user can take should be present as a real, visible element in the interface. Don’t hide controls behind hover states, right-clicks, or gestures that an agent would never discover.This same principle applies to everything from form submissions, toggles, filters to sign-in states. Whatever the action does, the interface must show it happened.
Example: A user asks an AI agent to “add the Blue Sneakers to my cart.” Here’s how the UI responds, and what the agent sees.
2. Ensure stable layout.
Avoid asynchronous content loading, diagnose images or videos with unknown dimensions that causes occurrence of layout instability in the agent’s session.
A useful mental model for designing agent-friendly layouts is to imagine every interactive element has a “promised coordinate.” Your job as a designer is to honour that promise across every state, user type, and day of the week.Regardless of what A/B tests, personalisation logic, or marketing campaigns do to the content above it.
Reserve space upfront. Instead of letting dynamic content push things down, give it a fixed-height container that’s always there, empty when the content isn’t showing, filled when it is. The elements below that container never move.
Agent task: “Complete checkout.” The agent locates the “Place order” button by screenshot on the checkout form.
3. Don’t hide interactive elements with ghost elements or transparent overlays while designing user interfaces.
For the agent, a <div> with opacity: 0.01 is still a real DOM node sitting in the z-stack and it physically covers whatever is beneath it.
When the agent does its visual analysis, it sees an element occupying that region and concludes “this area is covered, the nodes underneath are not accessible.” It discards them. The button might as well not exist.
Ghost overlays show up in real codebases in a few common ways.Hover-effect divs that expand to fill a card, click-tracking layers added by analytics tools, drag-and-drop handle zones, or dismissible tooltip triggers. All harmless looking, all potentially fatal to an agent trying to interact with what’s underneath.
The fix is simple. Just don’t put anything on top of interactive elements unless it genuinely needs to be there. If you do need an overlay, remove it completely from the DOM once it’s done its job.Don’t leave it behind at near-zero opacity.
Agent task: “Save this item to my wishlist.” The wishlist button is a heart icon on the product image — but something is hiding it from the agent.
4. Use semantic HTML while building clickable elements and fix the accessibility tree manually with role and tabindex.
building clickable elements in a way that makes their purpose clear to both users and AI agents. For example, buttons should be built as actual buttons, and links should be built as actual links, rather than making ordinary page elements behave like buttons or links.
Agents via the accessibility tree know a <button> is always a button, an <a> is always a link and an <input> is always a field.
When developers use a <div> or <span> instead and wire up clicks with JavaScript, that contract breaks. The HTML says “this is just a container” even though visually it looks and behaves like a button. The accessibility tree, which ignores CSS and JS entirely, reports it as a meaningless box.
Use semantic HTML when you can, and if you can’t, repair the accessibility tree manually with role and tabindex.
Agent task: “Find and click the Subscribe button and the Terms of Service link.”
5. Set cursor: pointer in CSS
When an agent uses screenshots to analyse a page, it doesn’t just look at shapes and labels. It also reads visual signals that indicate “this thing is clickable.” The mouse cursor changing to a hand when you hover over something is one of the strongest of those signals. It’s how browsers universally communicate “this is interactive.”
Agent task: “Identify and click all interactive elements on this page.” The agent reads screenshot cursor shapes as signals of actionability.
6. Add the for attribute on <label> tags to link them to inputs.
When an agent looks at a form, it needs to answer one question for every input field: “what is this field for?” A raw <input> tag alone gives almost no information, it’s just a box. The label next to it is what provides the meaning. But “next to it visually” is not the same as “linked to it in the DOM.”
The for attribute on a <label> creates an explicit, machine-readable bond between the label text and the input field. When that bond exists, the accessibility tree reports the input as “Email address, text field” rather than just “text field.” Without it, the label and the input are two completely unrelated nodes. The agent sees the text and the box but has no way to know they belong together.
Agent task: “Fill in the signup form and enter the email address and choose a password.”
7. Every button, link, or control essential to completing a task must have a visible area larger than 8 square pixels.
When an agent analyses a screenshot, it doesn’t process every single pixel that would be too slow and expensive. Instead, the vision model runs a filtering pass first: it scans the page and discards anything that appears too small to be a meaningful interactive element. The threshold mentioned here is 8 square pixels,essentially a 3×3 pixel dot. Anything at or below that size gets thrown out before the agent even tries to classify it.
The problem is that some real interactive elements like close buttons on modals, tiny icon-only actions, small “X” dismissals, arrow nudge buttons can render at sizes that fall near or below this threshold, especially on high-DPI screens or when CSS shrinks them down. The element is real, it’s in the DOM, it’s perfectly clickable by a human but the agent’s visual filter never even sees it.
