Designers Have a New User. And It Is Not a Human
For the last twenty years, we mostly designed for a person in front of a screen. Now products have another participant: an AI agent that reads data, calls tools, and runs multi-step workflows across systems. Human interfaces are not going away, but a second object of design is emerging alongside them: the environment, contracts, boundaries, and rules in which an agent operates.

For the last twenty years, designers mostly designed for a person in front of a screen: where they click, what they see, whether they understand a form, and whether they can make it through a flow without unnecessary friction. Our entire craft was built around gaze, attention, clicks, and cognitive load.
Now products have another participant: an AI agent. It can work with data, call tools, talk to APIs, and run chains of actions across systems. The interface is not disappearing; it is simply no longer used only by humans.
When a workflow stops being a sequence of screens
Take a typical internal workflow. An employee receives an email, opens the CRM, cross‑checks the data, switches to another system, verifies limits, and makes a decision. Previously, a designer tried to make that path shorter and clearer: bring the information onto a single screen, remove extra fields, highlight the status, and cut the number of steps.
Once an agent takes over part of that work, you have to design the logic itself: which data it can access, what it is allowed to do on its own, what counts as an exception, and at what exact moment control must be handed back to a person. The workflow stops being just a sequence of screens and becomes a route between autonomous action and human judgment.
And the design questions change accordingly:
- what context the agent receives up front, and how it knows which source of truth to trust;
- which actions are reversible and safe by default, and which require explicit human approval;
- what edge states look like when data is incomplete or two systems disagree;
- how to show a person not just the final output, but a concise, verifiable trace of why the agent arrived there.
AX: a new title or a new layer of work
People increasingly use the term AX — Agent Experience for this. Back in 2025, Salesforce described AI agents as a new kind of user that also needs a designed environment and interaction rules. They wrote a good piece on it: Welcome to a New Era of Agent Experience Design.
Still, I would not rush to put AX Designer in a LinkedIn profile just yet. Right now it looks much more like a new layer of work on top of product design, service design, and engineering than a standalone profession — at least for now (though trends travel fast, and people already put all kinds of titles in their bios).
We saw something similar with Design Systems and DesignOps: at first they looked like extra tidiness inside regular product work, until it became clear that large products fall apart without explicit rules, tokens, and contracts. The same thing is happening with agents, except the cost of ambiguity is higher: a human facing a confusing screen will pause and ask, while an agent will confidently keep executing the chain.
What is obvious to the eye is invisible to a machine
This is especially visible in design systems and internal tools. Humans infer a huge amount of meaning from visual context: we see that a red button next to a project name probably deletes data; we tell from spacing which fields belong together; we recognize muted gray text as a hint rather than a value.
If a rule exists only in a designer’s head — or can only be understood by looking at a Figma frame — a machine cannot see it. An agent needs explicit descriptions of states, constraints, available actions, and tooling: everything that can be exposed in structured form through rules, schemas, plugins, and MCP.
In practice, that quickly changes how we document a system:
- Not just a picture of a component, but a contract: what job it does, when not to use it, which states are required, and which props change the meaning of an action.
- Not raw values, but semantics: tokens and element roles that let both an engineer and a coding agent assemble a predictable interface without guessing HEX codes or spacing by eye.
- Not “click here,” but explicit action boundaries: what a tool actually does, which parameters it accepts, what side effects it creates, and what it returns when something fails.
Agent‑Computer Interface
Anthropic calls this the Agent‑Computer Interface (ACI) and notes that the quality of tool descriptions, parameters, and boundaries directly shapes how reliably an agent performs: Building Effective AI Agents.
In their own work, refining tool definitions and interfaces sometimes took more effort than tuning the main prompt. And by nature, that is very much a design problem. When we design a form for a human, we think about field labels, sensible defaults, preventing destructive mistakes, and helpful error states. When we design a tool or specification for an agent, we are doing the exact same job — except our materials are parameter names, response schemas, guardrails, and validation rules instead of buttons and modals.
A poor ACI fails the same way a cluttered screen does: too many overlapping actions, ambiguous parameters, unhelpful errors, and blurry ownership. A good ACI narrows the room for hallucination and makes the right action the easiest path.
Two loops of the same product
So UX is not going anywhere, and a new title will not replace the discipline tomorrow. People still need clear screens, legible hierarchy, predictable states, and calm control over what is happening. In fact, once an agent handles the routine steps, the human interface at the moments of review, escalation, and handoff matters even more.
What changes is that alongside interfaces for people, we now have a second object of design — the environment in which an agent acts: context, documentation, available tools, guardrails, and validation feedback.
We used to explain to humans how to use the system. Now we also have to explain to the system what it is allowed to do.