Do you design your app for agent experience (AX)?

Apps have always been built around human interaction. Good UI and UX is essential to giving people a great experience.

Now agents are using your apps more and more. They can't click through a pop-up login or a 4-step wizard. They guess from screenshots, burn tokens, and give up for a tool that just works.

Agent experience (AX) is UX where the user happens to be an agent. Give agents a front door - a CLI, an MCP server, or WebMCP tools - and they can finish the job without scraping your UI.

What is agent experience (AX)?

AX is designing your product so an AI agent can understand it and use it on its own. Agents don't see your layout. They read command names, tool descriptions, schemas and error messages.

• Agents pick tools that work - If a flow needs a human mid-way, the agent moves on to another tool
• No screenshot-and-guess loops - One structured call replaces a dozen clicks
• Easier to permission - A named tool with a schema is easier to approve than "click anything on the page"

How is AX different from UX?

AI tools are bad at inferring context or reading between the lines. They need clear, straightforward documentation and definitions, and discoverability should be a priority.

Humans are the opposite. A person can scan a screen, guess what an icon means, and ask a colleague when stuck. An agent has none of that.

• Humans infer, agents need it spelled out - A person understands "a couple of days" or an unlabeled icon. An agent needs the exact value and a name
• Humans explore, agents need discoverability - A person clicks around menus to find a feature. An agent can only use what it can list, like commands, tools, schemas and docs
• Humans tolerate vague errors - "Something went wrong" makes a person retry or call support. An agent needs to know what failed and what to try next
• Humans can ask for help - A person can answer a pop-up or pause for a colleague. An agent running unattended can't

Which AX surface should you build?

There are three ways to give agents a front door. They are not exclusive.

Pick by where the agent runs: a CLI for agents in a shell, an MCP server for agents reaching your system remotely, and WebMCP for agents acting inside the user's open browser tab.

CLI

A CLI needs no hosting, and agents already know how to run one. Make it agent-friendly:

• Never prompt - Take input from flags and environment variables, not interactive questions
• Output structured data - Offer --json or similar, and print an explicit message when there are zero results
• Fail loud - Return meaningful exit codes, and reject unknown flags instead of ignoring them

MCP server

Use an MCP server when agents need to reach your system from anywhere, not just a machine with your CLI installed. The tool name and description are the only UI the agent sees, so write them for an agent.

See Do you have an MCP server to let AI agents plug into your app? for how to build one.

WebMCP

WebMCP lets a web page register JavaScript tools that an in-browser agent can call, using document.modelContext.registerTool(). The agent reuses the user's session instead of re-authenticating.

What makes a good AX, whichever surface you pick?

• Non-interactive auth - Use tokens or service accounts, never a browser pop-up the agent can't answer
• Errors that explain the fix - Say what went wrong and what to try next
• Descriptions written for agents - Say what a tool does, what it needs, and what it returns

Learn more

• SSW: Do you have an MCP server to let AI agents plug into your app?
• SSW: Do you give your AI agents context with MCP servers and skills?
• SSW: Do you know when to use agents, subagents, skills, and MCPs?
• WebMCP specification - Draft Community Group Report
• WebMCP on Chrome Developers - origin trial and flag setup
• AXI: Agent eXperience Interface - 10 principles for agent-friendly CLIs
• What is Agent Experience (AX)? - Nordic APIs