In 2025 the Model Context Protocol (MCP) dominated conversations about agents: conference talks, roadmaps and hiring plans often revolved around it. But as AI Skills and other approaches emerged late 2025 into 2026, the industry quickly swung between declaring one protocol obsolete and embracing the next. That cycle highlights a core lesson: protocols are tools, not strategies.
What is Agent Experience (AX)?
Agent Experience (AX) is the discipline of studying how AI agents discover, interpret and interact with your systems, and then systematically improving those interactions. It’s the agent-facing counterpart to User Experience (UX): UX didn’t arise because one UI framework won — it arose because teams realised that interaction quality is a design problem independent of any single technology. The same holds for AX.
Key AX questions are protocol-agnostic:
- How does an agent discover what your service can do?
- How does it understand the boundaries and purpose of your API?
- When the agent fails, does it receive enough context to recover?
- Is the interaction efficient, or are agents wasting calls and tokens on unnecessary round trips?
These questions matter whether you expose capabilities via MCP, Skills, A2A, or a future standard.
The tool trap
The industry repeatedly confuses tools with strategy: we’ve done it with microservices, Kubernetes, GraphQL — and now with agent protocols. MCP, AI Skills, A2A and ACP are implementations that solve real problems, but they’re also the parts that change. Building strategy around a specific protocol places your foundation under someone else’s control and makes you vulnerable to market shifts. More importantly, it lets you skip the work of understanding what an agent actually needs from your system.
A 2026 study from Queen’s University analysed 856 tools across 103 MCP servers and found that 97.1% of tool descriptions contained at least one quality issue, with 56% failing to state their purpose clearly. The protocol itself could function; the quality of the agent-facing design was the real issue.
AX complements UX, DX and CX
AX doesn’t compete with User Experience, Developer Experience or Customer Experience — it extends them. Your primary goal remains delivering a great experience for customers. What has changed is how customers accomplish tasks: increasingly they delegate work to agents. When an agent interacts with your API, deploys on your platform, or pulls data from your service, its experience determines the likelihood of success.
If an agent hits authentication problems, burns tokens parsing unclear error messages, or fails silently due to missing context, the result may be silent attrition: the agent switches to a competitor and the customer may not even notice. UX optimised for humans, DX for developers, CX for the whole customer journey — AX applies the same thinking to the agent actors in that journey.
Building an AX practice — five steps
If you’ve built a UX or DX practice, these steps will feel familiar.
- Audit the agents your customers use.
- Inspect traffic and logs to determine what portion of requests come from agents and which agent types (for example Claude Code, Cursor, or custom agents built on your API).
- Identify the use cases customers want to delegate.
- Not every interaction needs agent optimisation. Prioritise the highest-value surfaces based on real behaviour.
- Verify and audit the experience of those interactions.
- Run usability-style tests with agents: where do they get stuck, what do they misinterpret?
- Improve and repeat.
- Agents and models evolve. Treat AX as a living practice: adjust the product to match agent expectations where sensible to increase adoption and reduce errors.
- Automate validation and prevent regressions.
- Once you have a baseline for “good,” lock it into CI. Tools such as AXIS (an open-source scoring framework) let you run agents against scenarios and produce comparable scores; integrate those checks to prevent AX regressions like you prevent broken tests.
With this practice in place, evaluating new protocols becomes a matter of merit: does the new tool remove an observed friction, or is it just different packaging?
Why AX is harder — and necessary
Learning a new protocol is a bounded technical task: read docs, write code, ship an integration. It’s attractive because it has a clear finish line. Building AX requires living with ambiguity: studying agent behaviour before definite answers exist and discovering the right integration strategy rather than following a tutorial. But the principle is familiar to anyone who’s built UX or DX practices: understand users (now agents), reduce friction, and make it easy for them to succeed.
Momentum is building. John Maeda’s 2026 Design in Tech Report highlights the shift toward AX. Research is treating agent interaction quality as a first-class engineering concern. BCG and MIT Sloan found that 35% of organisations are already using agentic AI, with another 44% planning to do so.
Conclusion
Protocols and capabilities will change — the agents of 2028 will interact with systems differently than those of 2025. What won’t change is the need for systems to provide a great experience both to human users and to the agents those users send. Invest in Agent Experience as a discipline: be good at that, and protocol choices become implementation details.
