Agentic UX: How to design interfaces when AI acts for the user

The user clicks “Book me a flight to Lisbon next weekend cheaper” and leaves to pour coffee. Returns in a minute, and the agent has already compared three aggregators, chose a flight with a transfer in Madrid, because the difference is 80 euros, and is waiting for confirmation of payment. The designer of this screen did not draw any search form, filters, or result card in the usual form. He designed trust, control and exit points.

Agentic UX is not an AI chat on the side of a product. This is a shift in the role of the user from the performer to the customer. We used to optimize the click-click-result path. Now you need to design delegation: how the user sets the task, how he watches it, how he intervenes when the agent is going to do something stupid, and how he understands exactly what happened when it was over.

The problem is that 90% of classic UX patterns stop working. A progress bar does not reflect a job in which an agent can revise his plan in the middle. In a world where an agent has already sent three API requests and started a fourth, the Cancel button is not what it used to be. And the usual “show the result – the user decides” turns into a wall of text, through which no one can get through.

## What Changes in the Interaction Model

A classic interface is a set of tools. The user collects the result by pressing the buttons. The agentic interface is a conversation about intent and a constant checkup: did I get you right, can I do this, that's what happened.

### Three new entities on screen

The usual UI had screens, states, and actions. There are three other things in the agentic product that need to be clearly shown:

• Intent: How the agent understood the task. Not raw prompt, but its interpretation: "I am looking for a round trip flight, 2 passengers, economy, flexibility on dates ± 1 day.".
• **A plan is a sequence of steps that an agent intends to follow. At least with large strokes.
• The border of autonomy is what the agent will do and where he will stop and ask.

If these three things are not explicitly on the screen, the user does not trust the agent. He's doing the right thing.

### Anti-Pattern: Black Box with Spinner

The most common mistake of early agentic features is to show one line “I think...” and a rotating indicator for 40 seconds. The user does not know whether the agent is working or hanging, his task was understood correctly or not, whether something can be corrected or later.

The solution is not to replace the spinner with “beautiful animation.” It’s about streaming steps: “Check Aviasales → found 12 options → discard with transfers more than 4 hours → compare with Skyscanner.” Every step is a point where you can intervene.

## Projecting Intent: How an Agent Shows He Understands

This is the first and most underrated screen in Agentic Flow. The user wrote a vague phrase – the agent should reformulate it into a structure and show it back. Before he acts.

### Checklist of a good proof of intent screen

• The key parameters of the problem are seen in a structured form, rather than a retelling
• Each field is edited in one click without returning to chat
• It is clearly shown that the agent came up with it (for example, the default “economy”)
• You can see what data the agent will take from the context (profile, history, calendar)
• There are “Let’s go” and “Stop, not so” – two equivalent buttons, not one main one

### Scenario: Meeting reservation

User: "Agree with Anya to call next week." A bad agent immediately sends a letter with three slots. Good - shows the card: Anya Ivanova (from the last correspondence on November 12), 30 minutes, Google Meet, your free windows W/S/S/H after 14:00, a letter in Russian in your usual tone. And then the send button.

The difference is the cost of the mistake. A letter to the wrong Ana sent on your behalf is more expensive than an extra confirmation screen.

## Levels of autonomy: not everything is worth doing yourself

The main project fork is where the agent acts in silence, where he asks, and where he has no right to decide at all. This is not a setup in the bowels of the profile, but part of the main interface.

It is convenient to keep three levels in mind:

• Auto - Reversible and cheap actions: search, filter, draft, reformat the table.
• ** With confirmation** – actions with external effect: send a letter, book, write off money, change someone else’s calendar.
• Manually only – irreversible and sensitive: data deletion, publication, legally significant transactions, all with money above the threshold.

The boundary between levels should be visible to the user and customizable. Otherwise, he will either turn off the agent completely after the first incident, or he will begin to double-check each step, and then the agent’s meaning is lost.

### Questions for Agentic Flow Review

• What happens if the agent makes a mistake? Is it reversible?
• Will the user understand in a minute what the agent has already done?
• Is there a way to stop an agent in the middle without losing context?
• Can you see what external systems the agent is touching right now?

The short summary of the segment: agentic-interface is not “chat on top of the product”, but reassembly of roles. The user becomes the customer, the agent becomes the executor, and the designer designs the transparency of intent, the visible plan, and the boundaries of autonomy. Next, we will discuss how to show the process of work, how to make meaningful points of intervention and what to do with the mistakes of the agent.

## How to show the process: stream instead of spinner

When the agent started acting, the user’s main question was “Is he still alive?” Not “Tell me about the LLM architecture,” but literally, it’s work or hang. Therefore, the process should be streamed – give steps as they occur, and not save and show the finished result.

Streaming is not a developer log. This is a narrative for a customer who has little time.

### What to stream and what not

• **Stream: what instrument the agent is calling, what source is checking, what interim decision has been made.
• Do not stream: raw model tokens, internal reasoning chains, JSON API responses, retrai debugging errors.

A useful rule is that if a step cannot be described in one short phrase in the language of the user’s task, it does not go into the main stream. It can be hidden in a technical log for those who need it.

### Anti-Pattern: An Infinite Stream of Thoughts

The reverse extreme is to dump the entire chain-of-thought onto the screen. The user sees ten screens of reasoning, loses the thread, does not understand where he is in this thread, and closes the tab. The stream should be dense: five or seven meaningful steps are better than fifty lines of reflection.

A good heuristic is that each step is an action verb and an object: “Comparing prices from three suppliers”, “Forming a draft letter”, “Checking free slots in the calendar”. No “I’m thinking about how best to approach the task.”.

## Intervention Points: Where Users Can Intrude

The unstoppable agent is not an agent, but an autorun. The minimum that should always be:

• Stop button at any time, not recessed in the menu.
• The ability to correct the intermediate result and continue with it, rather than starting from scratch.
• Retraction of the last action, if it is already performed in the external system.

### Screenplay: editing on the fly

The agent prepares a letter to the client, shows a draft. The user sees the tone too formal. Bad flow: rewrite the prompt, the agent starts from scratch, loses already selected facts. Good: The user edits two phrases right in the draft, clicks "Continue with my edits" - the agent finishes the rest in a new tone.

This requires the designer to think about the states of the artifact, not just the steps of dialogue. The artifact – letter, document, reservation – lives separately from the chat and is edited directly.

### List of points of intervention

• Stop is available in one click at any step
• Intermediate artifacts are edited in-place, without returning to chat
• After editing, the agent continues, not restarts
• You can see the history of steps - you can roll back to anyone
• Actions with an external effect have a clear undo as long as it is technically possible

## Agent Mistakes: Three Types and What to Do About Them

The agent is wrong differently than regular software. It’s not “500 Internal Server Error,” it’s “confidently done the wrong thing.” It is useful to divide the three types.

** Misunderstanding.** The agent misinterpreted the task. It is treated at the stage of confirmation of intent - if this screen is made well, such errors are caught before action.

I got it right, but the tool returned the nonsense or the agent chose the wrong source. Here it is important to show * what exactly* went wrong and at what step, and not the general "failed to complete the task.".

Did everything technically correct, but the result is bad in meaning - chose a strange flight, wrote the letter in the wrong tone. The most insidious type because the system doesn't know it's wrong. Captures only the eyes of the user - which means that the artifact should be conveniently revueable.

### Anti-Pattern: Success Without Verification

The agent completes the work with a green tick "Done" - and inside the letter went wrong, the reservation was made for the wrong day. The user will see this in a day, and trust in the agent will nullify.

It is more correct to end the session not with the status of “success”, but with a summary: what has been done, where, with what parameters, and an explicit request to confirm that everything is OK. Especially for external effects.

## How to apply this in the layout tomorrow

If you’re designing an agentic feature and you don’t want to drown, there are three practical steps.

1. Draw the flow as an artifact story, not as a chat branch. Where the artifact appears, how it changes, who touches it when he goes to the outside world.
2. Tag each action according to the level of autonomy - auto, with confirmation, manually. This will show where confirmation screens are needed and where they are redundant.
3. ** For each step, answer: What will the user see if they come in after a minute of silence? ** If the answer is "spinner," redo it.

### Questions for review layout

• Is the agent’s intention visible before he acts?
• Can we stop the process without losing context?
• What is shown at the moment of work - narrative or emptiness?
• What does a judgmental error look like, not just a technical one?
• Where the "agent himself" ends and the "need man" begins - does the user see it?

In short, the agent’s process is a separate design object, not a side effect. Streaming instead of a spinner, an artifact separate from the chat, explicit points of interference and honest mistakes are the four pillars on which trust in the agentic interface rests. Next, let’s see how all this affects product metrics and what changes in the work of the design team.

## Agentic Product Metrics: What to Measure

The usual product metrics on agency flow lie. The DAU grows because the agent pulls the service itself. Time on task falls, not because it’s more convenient, but because the person clicked “start” and left for coffee. Conversion can grow perfectly on paper, until it turns out that half of the tasks were “technically successful”, but the user then reworked everything with his hands.

In order not to lie to yourself, it is worth looking at three separate slices on agentic-fitch.

### Slice 1: Quality of autonomy

It's about how much an agent does without a person - but honestly.

• Proportion of sessions completed without intervention - and separately: the share where the intervention was, but the user did not cancel all flow
• Intervention rate on steps - at which stage people most often press a stop or rule an artifact
• Rollback rate - how often after "Done" the user rolls back or reworks the result manually
• Time before the first edit – if users rule en masse 3 seconds after displaying the artifact, the agent misses with intent

Rollback rate is the most honest metric of all. A green tick doesn't mean anything if an hour later the user has remade everything.

### Slice 2: Trust

Trust is poorly measured by a single digit, but there are indirect signals.

• Proportion of tasks running in auto vs confirmation mode – if users sit en masse on manual confirmation even after a month of use, there is no trust
• Reuse on sensitive scenarios - sent a letter to the client once, whether returned for a second
• Depth of tasks: Does the average complexity of what people delegate grow over time

### Slice 3: cost of error

Not all mistakes are equal. It is worth keeping a separate counter of “expensive” misses – those that have gone to the outside world: letters sent to the wrong place, unnecessary reservations, erroneous payments. This metric should be on the team dashboard in red and discussed at each review, even if the value is 0.

## How to Review Agentic Flow in a Team

The usual design review is arranged around the screens. Agentic-flow falls poorly on this format - most interesting things happen between screens and in states that you will not show in one frame.

### Review format: script playback

Instead of bypassing the layouts in order, play the script live. One person reads the user’s replica, the second reads the agent’s actions, and the third reads the artifact. It sounds theatrical, but this is how holes come out: “And what does the user see while you say this?”, “And if he closes the tab now?”.

### Three mandatory questions for the review

• What does the screen show in the 15th second of the agent's silence? ** If the model does not have this condition, the layout is not ready.
• ** Where is the point of no return? * Before it everything should be canceled cheaply, after it there should be a clear confirmation.
• What does the same flow look like if the agent made a mistake in step 3 of 5? Not "how did the bug work," but what does the whole screen look like.

### Anti-Pattern Review: Show the Happy Path

The temptation to show only the perfect script is because it is beautiful and easier to draw. On agentic feature, the happy path shows almost nothing useful. Real complexity lives in forks: the user intervened, the agent doubted, the tool returned the void, the context is outdated. A review without these branches is a wrapper review.

## How to explain decisions to the development team

Agentic Flow is a place where the designer is forced to talk about things that were not his territory before: what tools are available to the agent, in what order he calls them, which is considered a “confident” answer. Without this, you cannot design an honest UI.

In order not to drown in disputes with engineers, a simple document for each feature helps - one page, three blocks.

Блок	Что там
Намерения	Какие задачи агент берёт на себя, какие нет, какие требуют подтверждения
Контракт UI	Какие состояния агент обязан стримить наружу, в каком формате, с какой частотой
Обработка сбоев	Что считается ошибкой понимания, исполнения, суждения — и как каждая выглядит в интерфейсе

This document is neither TK nor sin. It is a common pillar that the agent’s design and backend are negotiated in terms of the same level. Without it, the designer draws a “beautiful process,” and the engineer builds a system that physically cannot give away what is drawn.

### Checklist of Fichi readiness for development

• Levels of autonomy for each action
• Described stream format: what comes from the agent and how often
• Points of intervention and behavior after editing
• A summary is written at the end - fields, sources, wording
• It is agreed what actions have undo and how long he lives
• There is an error of judgment scenario, not just technical

An agentic feature requires a designer to go beyond screens—metrics that capture real utility, revisions that play scripts, and documents that synchronize UIs with the behavior of the agent itself. Next, it’s about how all this changes the composition and rhythm of the design team.

## Consolidated checklist: agentic feature before launch

This is not a checklist for "is everything beautiful." This is a checklist, after which there is no shame in giving the feature to living people, whose agent will waste their time, money and reputation.

### Intentions and boundaries

• It is clearly listed which tasks the agent takes and which refuses to perform
• For each action, the level of autonomy is fixed: ask, offer, do
• You can see where the line between “cheap action” and “expensive action” runs
• There is a wording of refusal - what the agent will say if the task is beyond his competence

### Visibility of the process

• Every long-term operation has an intermediate state, not just a spinner
• Shows what sources the agent is using right now
• You can see what the agent is doing in the 15th and 60th seconds of silence
• Any action in the outside world leaves a trail that the user can re-read later

### Control and rollback

• Every reversible action has an undo with a clear window
• Before an irreversible action - a separate confirmation screen, no toast
• The user can interfere with the work of the agent without closing the context
• After the intervention, the agent does not lose part of the work already done

### Disruption and uncertainty

• There are three types of errors: understanding, execution, judgment
• For each type, a screen is described, not just text
• The agent is able to say “not sure” and does not give a guess for fact
• With partial success, you can see what is done, what is not, and what to do next

## Anti-patterns that occur most often

### “Chat as a universal interface”

When any feature is reduced to a correspondence window. Chat is good for refinements and nonlinear tasks, but fails when you need to show structure, compare options, or go back to step 3 of 8. If the entire interface is a message history, the user loses orientation after ten replicas.

### "The Illusion of Consent"

The agent writes "ready," but doesn't show what he did. The user clicks “ok”, and only a day later finds that the letter went wrong. A drug is a mandatory summary of actual actions, with sources and reversible references, not the final point in the dialogue.

### "Default confidence"

An agent's tone is equally firm when he knows the answer and when he guesses. This is the most expensive mistake: the user stops checking. The UI should have a visual signal of insecurity—separate, non-textual—so it can’t be missed.

### "Quiet context"

The agent relies on data that the user does not see: past correspondence, files, profile. When the result is suddenly strange, the person has nothing to look at to understand the cause. Context should be open – not always visible, but always accessible in one click.

### "Progress Bar instead of Meaning"

The strip, which runs from 0 to 100, says nothing about what's going on or whether it's possible to intervene. On agentic-flow, it is better to show progress in steps with the names: “reading correspondence”, “drawing up a draft”, “checking addresses”. Steps provide an entry point for editing.

### "One big undo for everything."

The “cancel everything” button creates a false sense of security and doesn’t work where some of the action has already gone out. It is better to have a separate undo for each action with a different lifespan, and an obvious “this can no longer be canceled” where it is true.

## Questions for the final review

Before you put the feature in the release, go through the list. If the answer to any question is “don’t know” is a job, not a release.

• On which screen will the user realize that the agent did not understand him?
• What does an interface look like if the agent is 60% sure, not 95% sure?
• What will the user see if he opens the feature in a week and does not remember what he agreed?
• How many clicks between “agent is going to do” and “I stopped it”?
• Where in the float is the most expensive miss, and why is there confirmation?
• By which metric will the team know that users trust the agent more?

## Short practical outcome

Agentic UX doesn’t undo old skills — it adds a few new responsibilities. The designer is now responsible not only for the screens, but also for how the agent shows his work, how he admits to insecurity and how he returns control to the person. This requires a different density of communication with engineers, other reviews, and other metrics.

It almost boils down to three things. The first is not to hide the process: everything the agent does for the user must leave a visible and reversible trace. The second is to divide levels of autonomy by cost of action, not by ease of development. The third is to project error and uncertainty as separate states of the interface, not as a bug.

If the feature passes your own checklist, experiences a script playback on a review and does not fall into the anti-patterns from the list above, it can already be shown to users. Metrics, observation, and iterations work like any other product.