Agent Experience
Spanish version available: Versión en español.
I wrote recently that your MCP server is just another client app.
I still think that is true. But I think the bigger idea goes beyond MCP.
What matters is Agent Experience, or AX.
It is a nod to UX. User Experience asks what it is like to use a product as a person. Agent Experience asks what it is like to use a product as an agent.
That can include an MCP server, but it can also include your API, your CLI, your docs, your auth model, your error messages, and the shape of the workflows you expose.
If an agent is going to use your product on behalf of a user, all of that becomes part of the interface.
This is bigger than MCP
MCP got people thinking in the right direction because it made the agent interface visible.
But it is easy to over-focus on the server itself, as if adding an MCP layer were the whole job.
It is not.
An agent may interact with your product through an MCP server. Or through a CLI. Or directly through an API. Or through browser automation. Or by reading docs and stitching things together the hard way.
The question is not "do we have an MCP server?"
The question is: how easy is it for an agent to actually get useful work done here?
That is an AX question.
What good AX looks like
Good Agent Experience does not mean exposing every primitive operation you have.
Usually it means the opposite.
It means giving agents a small number of clear ways to succeed:
- workflows, not a pile of endpoints
- discoverable capabilities
- predictable inputs and outputs
- useful errors
- fewer ambiguous paths
- easy ways to verify the result
This is very similar to the point I made in the MCP post. Agents do not want your internal service topology. They want a path to completing a task.
People sometimes talk about AI products as if the main opportunity were adding AI features for humans.
That is part of it.
But another part is making your existing product easy for agents to operate.
Ask the agents
One habit I have found useful is to ask my coding agents for feedback after they struggle with one of our tools.
What would have made it easier for you to get this information?
They are often more resilient than we give them credit for. They will try alternative paths and push through awkward workflows. But when you ask where they struggled, they will tell you. That is useful product feedback.
I have done this several times with tools like todoist-cli. A few improvements I have contributed over time came directly from that feedback loop.
Most recently, I noticed Codex was having a hard time finding my DM conversation in Twist with a specific person. It turned out there was no easy way to do that via the CLI. So that turned into a PR to improve the tool.
This works with any LLM chat with tools, not just Claude Code or Codex. You can ask the AI chats in the very apps that you may work on if you're a software developer:
What tools do you have right now, and what tools do you wish you had to do this more efficiently?
You often get good answers.
The practical takeaway
If you build software now, you should care about AX. Even if you are not building explicitly agentic products, your users will increasingly try to use your product through agents. If that experience is awkward, someone else's product may simply be easier for them to use.
Because agents are becoming real users of software. And real users need good interfaces.