UX/UI is not dying: the next interface will be a delegation contract

A claim is beginning to circulate with growing confidence: the user interface is heading toward death.

The argument sounds obvious. If I can tell my computer, “review these emails, match the complaints with the CRM, prepare a response for each customer, and notify me before sending,” why should I open four applications, learn their menus, and carry out every step with a mouse?

The conclusion, however, confuses two different developments: less manual interaction and the disappearance of user experience.

We are not stopping the design of interfaces. We are changing what the interface governs.

For decades, digital products assumed that a person had to translate intent into a sequence of actions: open, search, select, fill in, compare, confirm. Agents change that relationship because they let people express an outcome and delegate part of the journey. Yet the more work the system executes, the more we need to understand its scope, operational decisions, permissions, evidence, and recovery capabilities.

The interface stops being only the place where work is performed. It becomes the place where we define, authorize, supervise, verify, and, when necessary, undo the work performed by an agent.

In summary

UX/UI is not dying. It is losing its monopoly over direct execution.

Voice will be an excellent entry point for expressing intent, interrupting, and coordinating. The screen will remain better for comparing options, reviewing large bodies of evidence, editing details, detecting anomalies, and understanding consequences.

The most likely future is not a voice-only experience but a hybrid architecture:

• Voice-first when speaking is the fastest way to declare a goal, add context, or change direction.
• Visual-first when verification, comparison, or authorization requires precision.
• API-first for the agent when a reliable structured tool exists.
• GUI or human intervention when the capability is unavailable, context is ambiguous, or risk requires direct control.

And yes: we will design UX for agents. But this does not mean drawing screens an AI might “like.” It means designing a semantic surface the agent can discover and use reliably: unambiguous tool names, typed parameters, structured results, least-privilege permissions, actionable errors, queryable states, and reversible operations.

The strategic deliverable will no longer be only a wireframe or a flow. It will be a delegation contract.

Voice changes the entry point; it does not remove the interface

As of August 5, 2026, OpenAI’s official documentation describes an experience in which ChatGPT Voice can be used with Work and Codex to start tasks, check progress, prioritize, interrupt, redirect, and coordinate several agents through a conversation. GPT-Live adds a full-duplex architecture: it can listen and speak at the same time and maintain the conversation while delegating more complex work.

This dramatically lowers the cost of expressing intent. People no longer need to know in advance where each function lives. They can describe what they want to achieve in natural language.

But speaking is not the same as granting unlimited control.

Voice uses the tools and permissions available to the selected experience. Computer context may require access to the microphone, screen and audio recording, accessibility controls, local files, or specific applications. A workspace can enable or restrict features. A tool may read data without being able to modify it, create drafts without being able to send them, or prepare a change without being able to deploy it.

Voice makes interaction feel continuous. Permissions, boundaries, and states remain discrete.

A good experience therefore needs to distinguish, verbally and visually, at least three messages:

“I heard you.”

“I accepted the new instruction.”

“The instruction has already been applied to active tasks.”

They are not equivalent. In a system with several parallel tasks, a correction may affect only one branch, arrive too late for an action already executed, or remain pending approval. Conversational fluency cannot hide that operational reality.

The agent is a bodiless android

The most useful metaphor is not “a smarter chatbot.” It is a bodiless android.

It can speak with us, listen while we think, observe parts of the digital environment, and use the “hands” provided by tools, APIs, connectors, terminals, and system permissions. It can also retain context, coordinate subtasks, and react to events.

Metaphorical capability	Digital implementation
Voice	Speech-to-speech conversation, transcription, and synthesis
Ears	Microphone, activity detection, and shared audio
Eyes	Screenshots, browser, files, and structured data
Hands	APIs, MCP tools, terminal, connectors, and automations
Memory	Conversation context, files, and authorized instructions
Nervous system	Orchestration, events, states, and tool calls
Awareness of limits	Policies, sandbox, permissions, schemas, and human checkpoints

The decisive point is that it has no universal hands. We lend it specific hands.

It can read email when an authorized email-reading tool exists. It can draft when the tool supports drafts. It can send only when there is a send action and the granted authority includes that verb, that recipient, and that volume. It can analyze transactions without permission to cancel a subscription. It can prepare a rollback without being allowed to execute it in production.

Every additional verb—read, modify, publish, send, delete, pay—increases the blast radius.

This is why the interface does not disappear. When the system only suggests, the cost of failure may be a poor answer. When it acts, the error can propagate outside the chat. Design must make the distinction between capability and authority visible.

From screen design to collaboration design

Traditional UX organizes possibilities: menus, buttons, hierarchy, and journeys. Agentic UX must organize responsibilities.

We used to design an action: “Send.” Now we need to design a complete delegation:

“Identify the affected customers, draft a response using this policy, do not promise compensation above €100, create drafts but send nothing, and notify me when a case is ambiguous.”

The product must turn that sentence into a verifiable operational state. It needs to distinguish:

• The desired outcome.
• Authorized and excluded sources.
• Permitted and prohibited actions.
• Limits on money, volume, time, and scope.
• Success criteria.
• Situations requiring human intervention.
• Evidence that will demonstrate the work was done correctly.
• The way to correct or reverse the result.

This changes the smallest unit of design. It is no longer only the click. It is the working relationship among a person, one or more agents, and the systems they act upon.

Magentic-UI explores this relationship through co-planning, co-tasking, multitasking, action guards, and memory. The important idea is not one particular interface but the existence of different levels of participation: distant supervision, close control, joint problem solving, or full human takeover. Users should be able to change levels without restarting the whole task.

A plan, for example, should not be a decorative list generated by the model. It should be a manipulable object: reorder steps, cancel a branch, change a source, reduce scope, or add a mandatory checkpoint.

Are we going to design UX/UI for agents?

Yes, but it helps to separate two disciplines that will share the same product.

UX for people collaborating with agents	Experience for agents using systems
Understandable language	Unambiguous tool names
Summary before detail	Strict input and output schemas
Visual comparison	Structured and typed data
Contextual explanation	Precise operational descriptions
Confirmation proportional to risk	Impact and reversibility signals
Pause, redirect, and takeover	Queryable task states
Evidence and provenance	Stable identifiers and references
Undo and recovery	Idempotent or compensating operations
Multimodal accessibility	Machine-readable errors
Organizational accountability	Auditable logs and traces

For a person, a capability may be represented by text, a card, a button, a comparison, or a conversation. For an agent, the same capability needs a structured representation.

The Model Context Protocol formalizes part of this second surface. A tool can declare a name, description, inputSchema, outputSchema, and structured results. This helps an agent discover what exists, validate parameters, and receive an output without having to interpret a screen.

But a protocol does not replace design. A function named processItem remains ambiguous. A tool named create_refund_draft, requiring order_id, reason, maximum_amount, and requires_human_approval, communicates its intent, boundaries, and risk far more clearly.

The new product responsibility is to design the semantic surface of tools.

AXIS offers a useful signal: long sequences of visual clicks can introduce latency and lower reliability, while an API-first approach can complete tasks with fewer steps. Its results came from Microsoft Word and should not be generalized carelessly, but they illustrate a clear direction: applications prepared for agents will need structured capabilities in addition to screens for people.

The new deliverable: a delegation contract

A delegation contract is not necessarily a legal document or a single screen. It is the observable set of conditions determining the desired outcome, what the agent may do, and how its work will be checked.

It can be organized into eight layers.

Layer	Design question	Required affordance
Intent	What outcome did the system understand?	Editable “I understood that…” summary
Context	Which sources, periods, and exclusions will it use?	Source and freshness panel
Capability	Which tools exist and are connected?	Capability inventory and status
Authority	What may it read, modify, send, or delete?	Permissions by verb, object, and impact
Plan	How is the task decomposed and where are decisions made?	Editable timeline and checkpoints
Execution	What is running, blocked, or changed?	Observable state, pause, and takeover
Evidence	What proves the result is correct?	Diffs, sources, tests, and provenance
Recovery	How can it be corrected, reversed, or escalated?	Undo, rollback, and compensating actions

Intent

“Clean up my inbox” is ambiguous. “Archive newsletters older than 90 days, label invoices, and delete nothing” defines an outcome and boundaries. Before a broad task starts, the interpretation should be editable.

Context

Users need to know what data is included and excluded. An account analysis should state banks, periods, currencies, and freshness. “I did not find the data” is not the same as “I lack permission,” “the source is not connected,” or “the tool failed.”

Capability and authority

Having a tool does not imply permission to use every action it exposes. Reading is not modifying. Modifying is not publishing. Publishing is not deleting. Authority should be granted by verb, object, period, volume, and impact level.

Plan and execution

The plan should support changes without restarting the work. Execution needs to reveal which branches are still active, which instruction each branch is following, and which actions can no longer be undone.

Evidence

A convincing answer is not enough. The agent should connect claims and changes to sources, operations, diffs, tests, or screenshots. Codex already demonstrates part of this pattern by returning reviewable changes, terminal results, and validation evidence.

Recovery

Every action with effects should declare whether it is reversible, partially reversible, or irreversible. When technical undo does not exist, the product needs a compensating action: restore a version, send a correction, create a ticket, or escalate to an accountable person.

Concrete patterns for an agentic interface

The theory becomes useful when translated into product components.

Mission header

It should show the current objective, responsible agent, execution environment, elapsed time, state, and authority level. States such as preparing, waiting for approval, running, blocked, verifying, completed, failed, and reverted are more informative than a generic “thinking” animation.

Result summary

A useful closing state should answer six questions:

Field	Content
Result	What was achieved
Scope	Which sources, accounts, or files were processed
Changes	What was modified outside the chat
Exceptions	What remains incomplete and why
Risks	Which assumptions or uncertainties remain
Next action	What should happen now

Activity timeline

It does not need to expose private reasoning or an endless transcript. It should record observable actions: tool used, object affected, time, result, generated evidence, and reversibility.

Approval card

“I need permission” is insufficient. Approval should describe a concrete action:

Action: send 14 replies
Recipients: reviewable list
Content source: support policy v3.2
Data included: name, order, and proposed compensation
Impact: external communication
Reversibility: irreversible after sending
Alternatives: save drafts / send 2 test cases
Approval valid for: 10 minutes

Provenance and uncertainty

Every important claim or chart should connect to its source, date, tool, and transformation. An isolated “92% confidence” says little. It is better to explain the cause: “two statements are missing,” “three documents contradict the current policy,” or “the classification uses approximate matching.”

Recovery center

The button should not merely say “Undo.” It should explain what will be restored and the blast radius: “Restore 18 email labels to their state at 10:42.”

Security is also a UX decision

An agent reading web pages, email, or documents may encounter malicious instructions embedded in those materials. If it also has broad tool permissions, an untrusted input can become a real action.

OWASP uses email to illustrate excessive agency: an assistant that only needs to read messages is also given sending capability, and an indirect injection attempts to make it forward sensitive information. The mitigation is not simply a better prompt. It is removing unnecessary functions, using read-only credentials, requiring review before sending, and limiting volume.

The UX response cannot be a confirmation prompt for every micro-action either. That creates fatigue and trains people to approve without reading. Design needs to combine:

• Least privilege by default.
• Approvals at moments of meaningful impact.
• Separation among reading, writing, publishing, and deleting.
• Limits on volume, money, time, and recipients.
• Visible state and stop controls.
• Post-action evidence and an auditable record.
• Technical or compensating recovery.

Governance crosses the whole product. The NIST AI RMF organizes risk management around Govern, Map, Measure, and Manage. For design teams, this means defining roles, accountable owners, evaluation criteria, and incident procedures before a demo becomes critical infrastructure.

Which work will shrink, and which work will grow?

The uncomfortable part is that not every current task will retain the same value.

It is reasonable to expect less demand for work focused exclusively on producing many screen variations, documenting deterministic journeys, or turning stable requirements into predictable components. Agents can already accelerate part of that production, and natural language will remove some intermediate steps.

Other responsibilities will grow:

• Modeling how an open-ended intention becomes a verifiable objective.
• Designing transitions among autonomy, collaboration, and human takeover.
• Defining permissions and approvals proportional to risk.
• Designing state for parallel and long-running tasks.
• Creating tools and APIs that agents can understand.
• Representing provenance, uncertainty, and evidence coverage.
• Designing undo, rollback, and compensating actions.
• Evaluating behavior rather than only screens.
• Working with security, legal, operations, and business on governance.
• Preserving accessibility across voice, text, images, keyboard, and direct control.

The designer is no longer only the person who arranges controls on a surface. They participate in defining who may do what, on whose behalf, with which information, under what boundaries, and with what accountability.

What a design team should do today

There is no need to wait until the whole organization has autonomous agents. Teams can begin by applying six questions to any existing flow:

1. What outcome is the person trying to achieve? Not which button they press, but which change they want in the world.
2. Which parts can be delegated safely? Separate research, preparation, modification, and publication.
3. What evidence would verify the result? Sources, diffs, tests, samples, or metrics.
4. Where must a person intervene? Ambiguity, external impact, money, sensitive data, or irreversibility.
5. How does the system recover from an error? Undo, snapshot, rollback, or a compensating action.
6. How is the same capability exposed to people and agents? One understandable representation and one structured representation.

Deliverables should change too. Alongside the journey map or prototype, a team should document:

• An authority matrix by action.
• A state and event model.
• A tool inventory.
• Schemas and expected errors.
• Human checkpoints.
• An evidence and provenance plan.
• A recovery strategy.
• Collaboration-quality metrics.

The next great interface will not be a screen

The graphical interface is not disappearing. It is ceasing to be the exclusive center of the experience.

We will still need buttons, forms, tables, charts, and editors. Their role changes. In many cases, they will no longer be the instrument used to execute every step but the surface where we understand the mission, bound authority, observe progress, review evidence, and decide whether to accept, correct, or reverse.

Voice makes this shift visible because it lets us express intent without manually traversing software. Codex and other agents make it operational because they can use tools, act in parallel, and produce reviewable changes. That combination does not kill UX/UI. It forces the discipline to mature.

We move from designing instruments a person operates directly to designing working relationships with a bodiless android—one that listens, observes, executes, makes mistakes, and needs understandable boundaries.

The next great interface will not be only a screen.

It will be a contract.

Frequently Asked Questions

Will voice replace graphical interfaces?

No. Voice lowers the cost of expressing intent, starting work, and interrupting a task. Visual interfaces remain better for comparing alternatives, reviewing evidence, editing precisely, understanding complex states, and confirming risky actions.

Will there be less work for UX/UI designers?

There will probably be less work focused exclusively on producing screen variations and deterministic flows. Work on interaction models, permissions, observability, behavior, evaluation, multimodal accessibility, recovery, and governance will grow.

What does designing UX for agents mean?

It means creating capabilities an agent can discover and invoke reliably: clear tool names, strict schemas, structured results, least-privilege permissions, actionable errors, queryable states, and reversible operations.

What is a delegation contract?

It is the observable specification connecting the requested outcome with authorized context, available tools, authority boundaries, the plan, checkpoints, evidence, accountability, and recovery options.

When should an agent ask for approval?

When an action creates a significant external effect, exposes sensitive data, raises privileges, involves money, affects third parties, exceeds the granted scope, or is difficult to reverse. Approval should be proportional to risk rather than interrupting every micro-action.

How do you measure a good human-agent experience?

Beyond success and speed, measure required corrections, avoidable interventions, time to detect errors, evidence coverage, scope compliance, recovery quality, calibrated trust, and the percentage of reversible actions.