April 13, 2026

How to design websites for AI agents (not just humans)

Make your site agent‑ready with AOM policies: task‑centric surfaces, structured data, and clear rules that let AI agents work safely and reliably on your existing web UI.

Read on Medium Read the spec (.org)Explore tools (aom.tools)

The web was built for people. Screens, typography, and interaction patterns assume a human is on the other side of the glass. That assumption is no longer sufficient. Software agents now read pages to complete tasks — research, purchase, triage, summarize, migrate, and coordinate. If your site only speaks HTML meant for eyes, agents are forced to scrape: brittle selectors, broken layouts, and ambiguous intent. The result is slower automation, higher failure rates, and more risk for everyone.

Agent Object Model™ (AOM) is a practical response: publish a structured surface alongside your human experience. Tasks, entities, actions, and policies become explicit JSON that agents can validate, compose, and execute against — while humans keep the brand, narrative, and creative presentation they expect.

This article is our canonical on‑site guide to designing for AI agents. If you prefer the full origin story and a more narrative walkthrough, you can also read the launch story on Medium: How to design websites for AI agents (not just humans).

The hidden cost of “HTML-only” automation

Most teams do not set out to block agents. They simply ship what design systems produce: routes, components, and content. Automation then reverse-engineers that output. The cost shows up as flaky bots, one-off integrations, and security theater (blocking without policy). Every redesign becomes a breaking change for someone’s script. That is not a stable platform; it is a fragile mirror.

Structured surfaces invert the relationship. Instead of agents inferring intent from presentation, you declare intent in a machine-readable contract. The human UI remains free to iterate because the contract is versioned and validated independently of CSS.

What “agent-ready” means in practice

Being agent-ready does not mean exposing your database or removing human oversight. It means publishing a policy-first description of what automation is allowed to do on a page or workflow:

Tasks describe what can be accomplished (read, compare, submit, escalate).
Entities identify the nouns agents must understand (product, invoice, policy clause).
Actions are the safe verbs with explicit inputs and outputs.
Policies encode consent, rate limits, scopes, and expiration — your rules, not the agent vendor’s defaults.

AOM packages these ideas into JSON that can be validated, linted in CI, and referenced from a clear automation policy hosted at a well-known URL. That combination is how agents move from “best effort scraping” to contracted collaboration.

From overnight adoption to compounding leverage

Teams can start small: publish a minimal surface for a high-value flow (support ticket, quote request, documentation lookup). Validate with open tools, iterate with schema feedback, and expand coverage as confidence grows. The point is not to boil the ocean on day one — it is to avoid painting yourself into a purely human-facing corner while the ecosystem accelerates.

The compounding part is consistency. When surfaces share a model, agents can reuse skills across sites without bespoke engineering for every layout variant. Your brand site becomes interoperable on purpose rather than by accident.

Policies beat mystery boxes

The most important product decision is not which agent runs first; it is who owns the rules. AOM puts policy next to content: explicit automation posture, clear scopes, and expiration dates that match how businesses actually operate. That is how you avoid the worst of both worlds — neither uncontrolled scraping nor arbitrary blocking without transparency.

If you want agents to work with you, publish the contract. Use agentobjectmodel.org for normative definitions and schemas, and aom.tools for validators, plugins, and workflows that keep your JSON honest in production.

Who wins?

Why site owners win?

Your site, your rules: Define exactly what agents can do.
No scraping risks: Agents consume your structured surfaces, not a brittle mirror of your DOM.
Zero required UI rewrites: Add AOM alongside your existing React, Vue, Next.js, or static site.
Ecosystem leverage: Plugins and starters exist so you are not inventing plumbing from scratch.

Why agents win?

Interoperable: Any AOM-compliant agent can work on any AOM-backed site.
Token savings: Explicit tasks and entities cut reasoning steps, OCR, and screenshot loops—often dramatically per workflow.
Reliable surfaces: Fewer broken selectors and fewer surprises when the brand site ships a redesign.
Policy-aware: Respect "forbidden" scopes, escalate when needed, and stay inside what the site published.

A short implementation posture

Pick one critical journey and model it as tasks + actions with conservative defaults.
Publish your site policy JSON and page-level AOM files alongside routes.
Validate in CI and against public validators; iterate when schemas evolve.
Expand entities and actions as you learn how agents interact with your content.

This is not a rewrite of your frontend. It is an additive layer that tracks how automation should behave — and it is the layer that ages well as agents multiply.

Closing

The next generation of web experiences will be judged by both human delight and machine clarity. AOM™ exists to make that dual mandate explicit: structured surfaces, open policies, and tooling that rewards builders who publish responsibly. Start with one flow, validate relentlessly, and grow the surface as your confidence grows — the ecosystem is moving fast, but your rules can move faster when they are written down.