UX Is Not Dying. It Is Moving From Operation to Understanding.
As agents absorb procedural interaction, UX becomes the comprehension layer that helps people understand system state, evidence, uncertainty, and consequences.
Agents are getting better at operating software. They can navigate APIs, apply filters, create resources, and complete workflows that previously required a person to move through a sequence of screens.
That does not make user experience less important.
It changes the job.
For product teams building agentic systems, the most useful distinction is no longer between graphical and conversational interfaces. It is between procedural UX and comprehension UX.
Procedural UX helps a person operate the system step by step. Comprehension UX helps them understand the state the system is in, how it got there, and what should happen next.
Agents reduce the need for the first. They increase the need for the second.
The Procedure Is Becoming a Tool Call
Many interfaces exist mainly to translate human intent into a valid sequence of system operations.
Choose a workspace. Select several items. Configure a schedule. Confirm permissions. Click through the wizard. The interface prevents invalid combinations and calls the right APIs in the right order.
An agent can increasingly perform that translation. Give it a clear goal, suitable tools, and constraints, and it can execute the same procedure without asking a person to operate every control.
This does not eliminate the underlying product work. The API, tool schema, permissions, validation, and error model become part of the experience. A vague tool description or an unsafe default is now a UX defect even if the screen looks polished.
The agent needs a clean contract. The human needs something different.
The Human Still Needs a Mental Model
After an agent completes a task, a chat message saying “Done” is rarely enough.
What changed? Which resources were created? What evidence did the agent use? Which assumptions did it make? What failed? What remains unresolved? What will happen automatically tomorrow?
These are comprehension questions.
Their answers often need more than conversation. Relationships are easier to understand in a graph. Changes are easier to judge in a diff. Trends need charts. Risk needs visible uncertainty and consequences. Complex state needs stable views that people can inspect, compare, and return to.
Chat is useful for expressing intent. It is not automatically a good interface for understanding a system.
A Deployment Wizard Is Not the Product
I have seen this distinction while building tools around Microsoft Fabric.
The Fabric Extensibility Toolkit includes controls for guided workflows, and our Package Installer can create a workspace, deploy preconfigured items, update data, and schedule items. A wizard is useful when a person needs to provide initial choices safely.
But once automation performs the deployment, the more important interface is the resulting state: what was installed, where it was installed, how the items relate, whether each operation succeeded, and what the user can do when one step fails.
The procedure can collapse from several screens into one request. The need to understand the outcome does not collapse with it.
This is where product design shifts from helping someone operate the machine to helping them understand the world the machine changed.
Oversight Is Too Narrow
One response is that interfaces become approval and monitoring layers. That is partly right, but it understates the human role.
People do not only supervise agents. They form judgments about the domain: whether a sales forecast is credible, whether an infrastructure change creates risk, whether a hiring recommendation fits the team, or whether a deployment reflects the intended architecture.
Those judgments require context, comparison, provenance, and sometimes direct manipulation. Interaction can itself be a way of thinking. Exploring a chart, adjusting a constraint, or comparing scenarios may help a person discover what they want before an agent can execute it.
The goal is not to remove humans from the workflow. It is to stop spending their attention on procedures that software can handle and invest that attention in understanding and judgment.
Design Both Sides of the Product
Agentic products have at least two interface surfaces.
The machine-facing surface includes APIs, tool definitions, context, permissions, and predictable failure modes. It determines whether an agent can use the product reliably.
The human-facing surface communicates state, change, evidence, uncertainty, and available intervention. It determines whether a person can trust the result and make the next decision.
Treating everything as chat neglects the second surface. Preserving every existing screen neglects the first.
The opportunity for developers and designers is to build both as one system: a precise contract for agents and a clear mental model for humans.
UX is not dying in an agentic world. The part devoted to operating software is shrinking. The part that helps people understand increasingly complex systems is becoming essential.
Which part of your product exists mainly to operate the system, and which part helps users actually understand it?