Designers and software makers are familiar with user experience: the overall experience a person has with a product, system, or service. For decades, the “user” was assumed to be human. With the rise of agentic AI, that is no longer always true. Agents now discover tools, interpret context, and act within many of the same systems people use.
Developer experience (DX) treats the developer as the end user, applying product thinking, research, and design to the tools, APIs, and systems used to build software. Internal and third-party developers may have different goals, but both benefit when the distance between intent and working software shrinks.
As the software development lifecycle becomes faster and less expensive, AI agents are taking on more execution and becoming fellow developers. Netlify co-founder Mathias Biilmann calls the discipline of designing systems for them Agent Experience (AX).
Biilmann categorizes AX in four areas:
Access: Can the Agent access your product? Do they have the right permissions? Must the human be in the loop?
Context: Does the LLM know about your product? Does it have the right context to use your product? Do your responses build the right context?
Tools: Are you building your product for agents? Do you offer the right tools for agents? Can you reduce friction for a human working through an agent?
Orchestration: Can you trigger agent runs from your product? Can you pass the right context along? Do you offer sandboxes and environments?
What Biilmann describes is the standard for DX expanding to AX. Let’s widen the aperture of that definition of experience. I’m thinking of it in three categories: Agent Readable, Agent/Human, and Agent-to-Agent. Agent Readable is what Biilmann defines; the literacy and rhetoric of how an agent views and interactions. Agent/Human is the nascent opportunity current personified by chat assistants. This is the workspace for humans and agents. Agent-to-Agent is how these sentient teammates interact with one another.
Infrastructure that unblocks agents is critical, but the larger unsolved problem is how humans and agents experience a system together. Interface patterns are immature today, resulting in both users squeezed into the same chat interfaces
Humans and agents behave differently throughout a task. A frustrated person might contact support, post on social media, or give up. An agent does not complain. It may retry, brute-force a path, or silently fail until instructed otherwise. Designing for agents therefore requires observability: systems must make confusion, retries, errors, and dead ends visible to the humans responsible for them.
This is where AX, DX, and UX converge. I believe a new MVC is emerging: agents become the controller for decoupled apps, while LLMs and context reshape the model layer. The following principles are still evolving, but they guide how I approach design and engineering today.
I wrote about Dynamic Interfaces three years ago. At the time it was a prediction, but with frameworks such as json-render, A2UI, Copilokit and MCP apps, they are becoming real. Dynamic interfaces combined with autonomous agents can make software feel sentient-like; not because it is, but because contextual responses and well-timed cron jobs can feel magical.
Humans and agents can pursue the same goal through different paths. A person might use a familiar search bar; an agent may query the source directly. Do not force both into one interaction model. Design parallel paths to the same outcome.
When the iPhone launched, its skeuomorphic interface borrowed from the physical world. That is why Freddy Anzures’ realization that slide to unlock would work feels so intuitive. Humans bring tactile familiarity to digital interfaces; agents do not.
Giving an agent computer use is a start, but it is often an inefficient translation layer. The larger opportunity is to expose structured context and actions in forms native to agents. Consider a document. Its human-readable and agent-readable forms can be bidirectional without being visually identical. The person may need hierarchy and typography; the agent may need structure, metadata, and clear affordances for action.
For every experience moving forward, there are human-readable, agent-readable, and a bi-directional experience of the two. That is the opportunity to figure out.
Should an experience use a god-mode agent, a swarm, or specialized subagents? The answer is all of them with the right user scenario. For precise work, a person may want to collaborate directly with a specialist. Higher on the ladder of abstraction, they may prefer one coordinating agent. The architecture can support several forms, but the product should make a strong contextual choice about which creates the least friction. It is not so different from another agent we know: Smith in The Matrix: Reloaded.
The biggest mistake people make in designing agentic systems is constraining it to human familiarity. Why force an octopus to open a jar with two tentacles because you as a human have two hands? Designing for agents to be adaptable unlocks new interactions and breaks away from anthropomorphic agents that act more like staff augmentation than being a unique AI teammate.
Of MVC’s three pillars, the Controller has the biggest opportunity in the age of AI. Information (Model) and interface (View) were reliable but static, while control required teams to build fixed APIs and people to learn the right navigation paths. Human-centered design tested those paths with a sample of users and hoped the result served the broader population.
Interfaces will become dynamic, personal, and contextual; rightsized for the the Job To Be Done (intent to value). MCP and protocols give teams an interpretation layer instead of requiring a bespoke endpoint for every permutation. Agents can become the primary controller, translating intent into actions while presenting people with the right view at the right time.
Using agents is not sufficient. To design well for Agent Experience, you have to build agentic systems. Their behavior is nondeterministic, and working under the hood reveals where context, tools, permissions, memory, and feedback loops break down. Designing one without that knowledge is like designing a car without understanding how its engine connects to the vehicle.
Using Claude or Codex is a good way to learn how agents work, but building your own exposes the underlying pieces. I use OpenClaw, an open-source autonomous agent that executes tasks. Whether you choose OpenClaw, Hermes, or another framework, building an autonomous agent takes you deeper than a chat interface can.
Though the majority of users will use an Out-of-the-Box (OOTB) solution, designers can learn a lot about the systems by building their own to prototype: loops, memory, permissions, handoffs, failure states, and the interfaces agents present.
It is also important to prototype multi-substrate experiences in which agents move across devices and environments, as I explored in Hyper-local, hyper-cloud. Tailscale offers one example of a mesh-as-agent substrate: a tailnet can connect local devices and cloud services into one secure environment for agents to act across.
As with UX and DX, evaluating AX requires both qualitative and quantitative evidence. Measure whether the agent completed the intended task, how many retries and tool errors occurred, how much time and compute it consumed, and when a human had to intervene. Pair those signals with traces and agent retrospectives to understand why the failures happened.
Tools such as Axis and DX’s Agent Experience Score are early attempts to make that quality visible; providing excellent quantitative measures. There is a qualitative measure typically forgot by people when designing AI systems and user experiences.
Ask the user.
In my prototype system, I ask the OpenClaw agents to run a retro together at the end of the day to send me feedback what could improve their effectiveness and productivity. I ask for theme feedback on, you guessed it, Access, Context, Tools, and Orchestration. In addition, they tell me how many tokens they are using and if there are recommendations to rightsize the job with model selection.
For customers, developers, and agents, every experience should bridge the gap from intent and value. UX-DX-AX is quite a mouthful, but this is the amalgam of experiences designers need to consider. There is Agent Experience as defined by Biilmann. In addition, we’re in the early journey of Human-to-Agent interactions and the co-working space they share and Agent-to-Agent experiences.
Agent Experience is not a future speculation. Though it’s in a nascent space to the early adopters right now, the implications of systems being re-written for the general end users is what to figure out. The moment is now.
The winning interaction will make those boundaries legible without making the underlying complexity the user’s problem for human or agent. It’s an exciting time for a designer to think through UX, DX, and AX. In the end, nothing changes in our craft as designers and developers. It’s bridging the gap of intent to value.
Introducing Agent Experience by Josh Beitler
Superlogical → This is going to be an interesting one to watch!
“Interactive tools assume a person at an interface.”
Design in Tech Report 2026: From UX to AX by John Maeda
Charlie at Atlassian: A dinner and conversation with Rethink
blog.davidhoang.com → I updated my personal blog with a custom theme I built. Long live RSS and you’ll find more personal takes such as what I think of X-Men ‘87 or The Odyssey there