A chat assistant that gives a wrong answer wastes a minute. An agent that sends the wrong email, deletes the wrong record or moves the wrong money wastes a lot more.
That is the main difference when you design an agentic interface. The software does not only suggest. It acts. So the design has to answer a new set of questions. What can it do alone? What must it ask about first? How does the user see what it did? How do they take it back?
These are the parts we design first when an AI feature can take actions.
What an agent may do alone
Start with a simple sort of every action the agent could take. For each one, ask two things: how bad is it if this is wrong, and can it be reversed?
A rough scale that works in practice:
- Read-only. Searching, summarizing, looking things up. Safe to do alone.
- Reversible and private. Creating a draft, adding a tag, saving a note for the user. Usually fine to do alone, with a way to undo.
- Visible to others. Sending a message, posting a comment, inviting a person. Ask first, at least at the start.
- Hard to reverse or costly. Deleting data, spending money, changing permissions, publishing. Always ask.
The sort is not fixed. A user who has watched the agent do the same task correctly twenty times may want to let it run alone. A new user should start with more checks. Which is why the next step matters: let the user move actions between the groups.
Whatever you decide, write the rules down in plain words and show them somewhere the user can find. "This assistant can read your calendar and draft replies. It will ask before sending anything." That one sentence builds more trust than a page of settings.
Previews before action
An approval step is only useful if the user can tell what they are approving. "Allow this action?" with a yes and a no is almost worthless. People click yes.
A good preview shows the real result, in the shape the user will see it:
- For an email: the recipient, subject and full body, ready to edit.
- For a data change: a before and after view of the fields that change, with the changed values highlighted.
- For a bulk action: the count and a list of items, with the option to open any of them. "Archive 38 invoices" should show the 38.
- For a payment or booking: the amount, the account, the date and any fee.
Make the preview editable where you can. If the draft is nearly right, the user should be able to fix one line and approve, not reject it and start over.
Also say what the agent is unsure about. If it guessed which "Alex" you meant, the preview should say so: "Sending to Alex Morgan (3 contacts match)". Showing the guess is better than hiding it.
Approval flows
Approvals can wear people out. If the agent asks about everything, users stop reading, or stop using it. Design the flow so it asks less over time without becoming unsafe.
Some patterns that help:
- Batch approvals. Group related steps into one plan. "I will do these five things. Approve all, or change any." This is better than five separate pop-ups.
- Approve once, for a scope. "Always allow drafts in this project" is better than asking every time. Keep the scope narrow and visible.
- Approve at the right moment. Ask just before the risky step, not at the beginning of a long task. The user then has the context to decide.
- Make the safe choice the easy one. Do not style "Approve" as the only big button. "Edit" and "Cancel" should be as easy to reach.
- Give a way to stop mid-task. A visible stop button while the agent runs. When it stops, show what was done and what was not.
Think about who approves, too. In a team product, the person who asked for a task may not be the person who should approve it. A manager may need to sign off on spending. Build that into the flow from the start, not as a later patch.
Undo and recovery
Undo is the part teams most often skip, because it is hard to build. It is also what makes people brave enough to let an agent act.
Think in three levels:
- Instant undo. A short "Undo" link right after the action, the way many email apps let you unsend for a few seconds. Good for low-risk changes.
- History-based undo. A list of recent changes, each with a "Revert" option. Needs the product to store the earlier state.
- Compensating actions. Some things cannot be undone, such as a sent email. Here the product can offer the next best step: send a correction, cancel the booking, refund the payment.
Be honest about which actions fall into which level. If something cannot be undone, say so in the approval step, before the action: "This cannot be undone." Do not discover it afterward.
For multi-step tasks, think about what happens when step three of five fails. Does the agent stop? Roll back steps one and two? Ask the user? Pick one behavior and show it clearly. A message like "Steps 1 and 2 are done. Step 3 failed because the file was missing. Nothing else was changed." is much better than a vague error.
Logs the user can read
Trust grows when users can see what happened without asking an engineer.
An activity log should say, in plain language:
- What the agent did, and when
- Why it did it (which request or rule triggered it)
- What it used (which data, which tools)
- Whether a person approved it, and who
- What changed, with a link to the result and to undo
Write the entries like a person would: "Moved 12 tickets from New to Waiting. You approved this at 10:42." Avoid raw system output like action: update_status, ids: [..]. You can keep a technical view behind a "details" link for people who want it.
Let users filter and search the log, and let admins export it. In many business products the log is also what a security or compliance team will ask to see.
Setting limits
Give users the controls to say how much freedom the agent has. Examples:
- Spending caps per task or per month
- A list of apps, folders or contacts the agent may touch
- Working hours or a "pause everything" switch
- A maximum number of actions before it must check in
- Role-based rules: who in the team can let the agent do what
Set the defaults to be careful. It is easier for a user to loosen a limit than to recover from a mistake. And show the current limits near the place where the agent works, not only in a settings page nobody opens.
One more point: test the failure cases with real people. Show a prototype where the agent gets something wrong, and watch what the user does. Do they notice? Can they find undo? Do they trust it less, or more, after seeing it recover? These tests change designs more than almost anything else.
Where to go from here
If your product is adding agent features, start by listing every action and sorting it by risk and reversibility. That one page drives the rest of the design.
This is part of what we cover in our AI product UX work, and you can read more on our AI product design page. Some of the patterns here also appear in the interfaces we build in our Lab. If you would like a second opinion on one agent flow, ask for a free design review at /contact.
