- Published on
Experience Design for Agents: AXD in 2026
My behavior has shifted. I use my agent for most tasks now. That means the products I build need to work for other agents too, not just humans.
This has me thinking about products in three layers:
- Product principles govern what you build and why
- UXD principles govern how humans experience it
- AXD principles govern how agents interact with it
AXD is the one I know least about. But I think it's going to become table stakes for all products, the way SEO did in the early 2000s. Most businesses had websites in 1999. Almost none of them were optimized for search. The ones who figured that out first won the next decade.
We're at that moment again, with one important distinction.
AEO (Answer Engine Optimization) / GEO (Generative Engine Optimization) is about being found and cited by AI. AXD is about being operated by AI. One is still content strategy. The other is infrastructure.
I worked through this with Claude. The questions are mine. The table took about 20 minutes to build together. That's also kind of the point.
So I started with a concrete question: what does AXD actually look like for a local home services company?
| Dimension | UX — designed for humans | AX — designed for agents |
|---|---|---|
| Discoverability | Does my site show up in Google and local listings? Can a person find me when they search "roofer near me"? | Can an agent find and parse my business instantly? Is my data structured so it can be extracted without interpretation? |
| Trust signals | Star ratings, review count, photos of past work, a professional-looking site. Things a human eye scans in seconds. | Verified license numbers, machine-readable certification data, structured job history. Things an agent can verify against an authoritative source. |
| Getting a quote | A form or estimator widget a homeowner fills in. Clear labels, sensible defaults, mobile-friendly layout. | An API endpoint an agent can call with structured inputs (address, job type, scope) and get a structured response back — no human needed. |
| Scheduling | A Calendly or booking widget. Easy to use, shows available slots, sends a confirmation email. | An availability endpoint an agent can query and book against directly — no clicking, no UI, no human in the loop on either side. |
| Communication | Responsive, clear messaging. A human answers the phone or replies to texts within a reasonable time. | Structured status updates an agent can consume. Job state exposed as data (confirmed, en route, complete) not as a text conversation. |
| Service area | A "we serve these cities" page or a map visual. Easy for a homeowner to check if they're covered. | A machine-readable geofence or zip code list an agent can validate against without loading a page. |
| Pricing | A rough guide page or "starting from" figures. Gives a human enough to decide whether to reach out. | Structured pricing schema — job type, material grade, price range — that an agent can use to pre-qualify or compare providers. |
| Post-job verification | A follow-up email asking for a review. A human hopefully leaves one on Google. | A structured job completion record — what was done, when, by whom — that an agent can log, verify, and use to update trust scores. |
| Accessibility | Can everyone use my site? Screen readers, contrast ratios, keyboard nav — designed for human diversity. | Can any agent use my API? Standard protocols, versioned endpoints, clear error responses — designed for system interoperability. |
The pattern that emerges: UXD optimizes for human comprehension. AXD optimizes for machine parsability. They're not opposites, but they pull in different directions. A beautifully designed booking widget is a UXD win and an AXD failure.
What building for the agent experience actually requires
Schema markup as your agent-facing front door. JSON-LD schema is how agents understand what your business is without reading your copy. Most businesses don't have this properly implemented. The ones that do will be the ones agents recommend.
An API layer for every key transaction. Quotes, bookings, availability, job status. If the only way to initiate any of these is through a human-facing form, you're invisible to agent-driven workflows.
A trust signal layer agents can verify. Star ratings are for humans. Agents need structured credentials they can cross-reference: license numbers, insurance status, verifiable job history. "5 stars on Google" means nothing to a system that can't validate it.
A machine-readable service contract. What do you do, where, at what price, under what conditions? This needs to exist as structured data, not buried in a PDF or behind a "call for a quote" button.
Status as data, not conversation. Job state needs to be queryable, not communicated through texts and phone calls.
An OpenAPI spec as your agent-facing business card. This is what lets agents understand what you can do and how to work with you. Without it, even a well-built API is invisible.
Most of this doesn't exist yet, anywhere. That's either a problem or an opportunity depending on where you're sitting.
I'm thinking through this as I build. What are you seeing?