UX has a second user now

Designing for the agent that now operates products on the human's behalf

UX has a second user now because AI agents from OpenAI, Microsoft, and Perplexity can operate product interfaces on behalf of humans. The human supplies intent; the agent performs the work. That shift turns UX from direct-use design into delegated-use design, where products need permission rules, evidence, recovery, and accountability.

---

In this essay:

• Intro

• The shift

• The second user

• Where the agent enters

• The conversation that’s already happening

• The smaller conversation

• The territory ahead

---

For most of the web and app era, UX had a stable default: the user was a person operating an interface directly. A person opened the product, read the screen, made a decision, clicked the control, corrected the mistake, and carried the consequence. Design work grew around that assumption.

The second user class.

Research methods, journeys, flows, components, usability tests, accessibility rules, and design systems all treated the human operator as the main actor.

That assumption now covers only one half of the product.

A person can give intent to an agent and let the agent perform the journey. The agent can read product information, compare options, click through screens, call actions, retrieve records, submit forms, book a table, place an order, or prepare work for approval. The product still gets used, but the direct operator has changed. The human supplies intent. The agent does the work on that human’s behalf.

This creates a second user class:

• the human with intent

• the agent doing work for that human

Once that is true, interface work changes. Products need to be understandable, usable, and governable by both. The human needs control, context, consent, and recovery. The agent needs structure, state, action boundaries, permission rules, and evidence it can use while acting.

---

The shift

UX has always had intermediaries. Search engines indexed pages. Assistants answered questions. Automation ran in the background. The difference now is agency. The intermediary is starting to point, decide, and perform product journeys.

[Agent activity monitor]

The interface is still there.

The agent may use it directly. Browser agents and computer-use agents can see, click, type, and navigate through product surfaces built for people. That matters because a product can gain an agent user without shipping a new API, an MCP server, or an official connector first. If a workflow exists behind a screen, an agent may be able to operate it.

The practical design question changes from “can a person complete this flow?” to:

Can a person delegate this flow and still remain in control?

---

The second user

Calling the agent a user can feel strange because the human remains the customer, the account holder, the legal subject, and the person with the real need. The agent becomes a second operator inside the product relationship.

The distinction matters because each user class brings different material to the system.

The human has the goal.

"Find the right hotel." "Cancel the subscription." "Prepare the report." "Book dinner for Friday." These are intent statements with constraints, preferences, risk, and consequence. The human may care about price, timing, cancellation policy, emotional stakes, privacy, or effort. Some of those constraints are explicit. Some are implied. Some need to be asked before the agent acts.

The agent has the operating burden.

It reads the product surface, interprets available options, chooses a path, takes actions, and returns with a result. The agent may enter through a visible UI, a browser, an API, a protocol, a plugin, or a tool chain. From the product’s point of view, the agent is an active actor trying to understand the product well enough to do work.

The product has to bind the two.

Identity becomes the first gate. Which human is this agent acting for? What scope did that human grant? Which actions are within the instruction? Which actions need confirmation? Which result should be recorded as the agent’s action, the human’s action, or both? Without that binding, the product sees activity but cannot reason well about authority.

This is why the second-user frame matters for design systems. A traditional design system can tell a human team how to build the checkout screen, the form, the empty state, or the confirmation modal. An agent-operated product also needs to tell the agent what the journey means, which actions are safe, when to stop, what to reveal, and what can be undone.

---

Where the agent enters

There is no single “agent interface.” That is part of the problem. The run-time agent can enter the product through more than one route, and each route stresses a different part of the system.

Through the screen. A computer-use agent can operate the same graphical interface a person uses. It sees visible state, clicks controls, types into fields, and moves through the flow. This puts pressure on ordinary product UX: labels, state, feedback, destructive actions, error recovery, and confirmation moments become machine-facing signals too.

Through structured action surfaces. The agent may also call APIs, protocols, connectors, MCP tools, App Intents, commerce protocols, or other action layers. This route can be cleaner than screen operation because it exposes formal actions and parameters. It also moves permission away from the visible interface. If the protocol allows checkout, refund, cancellation, or deletion too broadly, a polished UI leaves the gap open.

These two routes can overlap inside a single journey. An agent might read a screen, call a tool for the next step, hand the user a confirmation moment, and then complete the final action through a third-party product. The product team does not get to pick one place where “agent UX” lives. It has to map the journey across screens, action surfaces, and oversight moments.

---

The conversation that’s already happening

There is one conversation about all of this that has volume. How do we make the design system readable by coding agents and design agents, so they can generate UI without inventing tokens, missing intent, or drifting from the system?

The work is real and well staffed. Pandya has written structured specs, closed token layers, audits, and drift detection. Wolosin has proposed a metadata layer that sits on top of the system. Frost is extending the design system inward toward what an agent needs to read. Around them, design-system MCP servers and AGENTS.md / rules files in repos turn the system itself into ingestible context for coding agents. The pattern across all of it is the same: turn the design system into context an AI agent can ingest at the moment of generation.

This is build time. The agent is being asked to produce something, and the system is being made legible enough to guide that production. It is the right thing to work on. A team that ships an LLM-readable design system has done useful work.

It is also not the layer the second user changes most.

---

The smaller conversation

There is a second conversation, smaller and quieter, already underway. The shape is starting to be named in pieces: the interface is becoming a governance layer.

What is being designed next is the permission model the agent acts inside. That permission model is the new interaction model.

Romina Kavcic encodes trust ladders, approval queues, and audit logs inside the design-system container. Wolosin, Cristian, and Trueman build governance-adjacent infrastructure outside it: rules files, MCPs, drift telemetry. Josh Clark and Victor Yocco bring AI-UX vocabulary for autonomy, consent, and recovery. The thread across them is that the design system, as it exists, does not yet have language for what the agent at the keyboard is allowed to do.

But the work is mostly conceptual. The vocabulary is fragmented: behavioral contracts here, trust gradient there, permission model elsewhere. The artifacts a staff designer can actually pick up on Monday are still mostly missing: a permission matrix, a reversibility class, a “must stop” list, an audit-trail template. And the volume of attention sits firmly with the build-time work, where the tooling is more mature and the wins are easier to demonstrate.

This is the run-time layer. The agent is operating, not producing. Build-time work asks whether the agent can generate a button that matches the system. Run-time work asks whether the agent is allowed to click this button, on this user’s behalf, in this context, without confirmation, and who carries the consequence if it gets it wrong.

A token audit catches #2563EB where var(--color-link) should be used. It does not tell you whether the agent should be allowed to confirm the booking, send the email, place the order, or transfer the funds. A structured spec teaches an agent what a Button looks like. It does not teach it whether the agent has authority to press it.

The build-time conversation has volume, names, conferences, and tooling. The run-time conversation is named in pieces, gestured at by smart people, and not yet crystallized into the artifacts teams can use. That is the gap: sparseness, fragmentation, and a vocabulary still forming.

---

The territory ahead

The gap is the run-time layer: vocabulary fragmented, artifacts missing, attention pulled elsewhere. This publication works that side.

Make the second user visible. Agents are already running journeys inside products people have shipped. A later essay in this series, Can vs. may: the gap in every design system, will trace one of those moments end to end: Comet placing orders on Amazon, Amazon pushing back, a federal judge drawing the line the product had not drawn. That is what the second user costs when nobody designs for it. The work here is to keep surfacing those moments, named and dated, while they are still in motion.

Sharpen the vocabulary. Readers need distinctions sharp enough to argue this on their own team. Build time and run time. Capability and permission. Guideline and guardrail. Generation and operation. The design system as documentation and the design system as governance.

Survey the field. The container split between extending the design system inward and building governance outside it. The browser-agent cluster: Mariner, Operator, Atlas, Comet. The protocols: MCP, App Intents, the agentic commerce stack. The experience-design voices working the run-time side. What each one is actually solving, and what it leaves open.

Implementation is the reader’s. The job here is making the territory legible to the people crossing it.

One question to send back: which of the four run-time artifacts — permission matrix, reversibility class, “must stop” list, audit-trail template — has anyone on your team actually drafted for your product?

---

Thanks for reading LeLines!

This post is public so feel free to share it.

---

Frequently asked questions

What does it mean that UX has a second user now?

It means product teams now need to design for two different actors in the same journey: the human who owns the goal and consequence, and the AI agent that may execute the work. The human still remains the customer, account holder, and accountable party. The agent becomes the operator that reads state, chooses paths, calls tools, and returns with results.

Why call an AI agent a user if the human is still the customer?

Because from the product’s point of view, the agent is doing user-like work. It can read the interface, interpret options, click controls, call APIs, submit forms, and prepare or complete transactions. Calling it a second user helps design teams separate intent from execution, then bind the two through identity, permission scope, confirmation, recovery, and audit trails.

How can an AI agent enter a product experience?

An agent can enter through the screen or through a structured action surface. Screen-based agents use the same graphical interface a person uses, which makes labels, state, feedback, and confirmation moments machine-facing signals too. Structured routes include APIs, MCP tools, connectors, App Intents, commerce protocols, and agent-to-agent handoffs. A single journey can use both routes.

What is the difference between build-time and run-time design-system work?

Build-time work helps coding and design agents generate UI without drifting from the system. It covers tokens, structured specs, metadata, audits, and repository rules. Run-time work governs an agent operating a shipped product. It asks whether the agent may click this button, for this user, in this context, with this evidence, and who owns the result.

What should design systems add for agent-operated products?

Agent-operated products need reusable governance artifacts alongside reusable UI. The missing artifacts include a permission matrix, a must-stop list, reversibility classes, disclosure rules, audit-trail templates, and ownership rules. These artifacts connect the human’s intent to the agent’s execution so the product can reason about authority before the agent acts.

---

Source trail

• OpenAI introduced Operator in January 2025 as an agent that could use its own browser to click, type, scroll, fill forms, order groceries, and hand control back to the user for sensitive actions. (source: OpenAI, 2025-01-23)
  

• OpenAI later introduced ChatGPT Atlas as a browser with Agent Mode, with examples that include automating tasks, planning events, booking appointments, and adding groceries to a cart. (source: OpenAI, 2025-10-21)
  

• Microsoft describes Browse with Copilot as working in the current tab or a new tab, interacting with webpages through selecting, scrolling, and typing, and asking for attention or supervision on actions such as buying, booking, sending email, or deleting a calendar event. (source: Microsoft Support)
  

• Perplexity describes Comet as a browser that can help with email, shopping, grocery orders, inbox management, finance, and vacation planning. (source: Perplexity Comet)
  

• Consumer Reports tested ChatGPT Atlas, Perplexity Comet, and Microsoft Edge Copilot Mode on tasks including restaurant booking, laptop comparison, and email summarization. In its OpenTable test, Atlas completed the flow up to final confirmation after contact information. (source: Consumer Reports, 2025-11-10)
  

• Hardik Pandya’s “Expose Your Design System to LLMs” is the build-time reference for structured specs, closed token layers, audits, and drift detection for UI-generating agents. (source: Hardik Pandya, 2026-03-03)
  

• Diana Wolosin’s machine-readable design-system work is the source trail for treating AI as a design-system user and for using structured metadata, benchmarks, and MCP delivery to improve model behavior. (source: Wolosin, 2026-03-05; source: AIMS case study)
  

• The companion essay “Can vs. may” develops the permission side of this argument through the Amazon and Perplexity Comet dispute. (source: Lelines, 2026-05-14)