By Mehdi HassanAn agent doesn't wait for the next prompt. It takes a goal, breaks it into steps, calls tools and changes things in other systems. That makes the chat-first interface most AI products start with a poor fit, because the important information isn't the reply, it's what the agent did and what it's about to do. This guide covers the patterns that matter when the AI acts on its own. It's part of our guide to AI product UX.
What is agentic UX?
Agentic UX is the design of interfaces where an AI agent pursues a goal across several steps, using tools and making changes, with the user supervising rather than directing each step. The design problem shifts from presenting an answer to making delegated work visible, controllable and reversible.
A useful test is who decides the next step. In chat, the user does, by writing the next message. In an agent, the system does. Every pattern in this guide exists to give that decision back to the user at the moments that matter, without making them approve every trivial action.
Aspect | Chat UX | Agentic UX |
|---|---|---|
User role | Asks and reads | Delegates and supervises |
Unit of work | One message and reply | A task with many steps |
Main screen | The conversation | The plan, progress and results |
Time | Seconds | Minutes or hours, often in the background |
Risk | A wrong answer | A wrong action in another system |
Key controls | Regenerate, edit | Approve, interrupt, roll back |
How is designing for AI agents different from designing chat?
Designing for AI agents is different because the agent's output is a set of actions with side effects, often taking longer than a user will watch. You design for delegation, background progress, interruption and audit, rather than for reading a reply.
- State lives outside the chat: the agent changes records, files and messages elsewhere, so the UI has to show those changes, not just describe them.
- Users leave: long tasks run in the background, so you need progress indicators, notifications and a clear summary when the user returns.
- Errors compound: a wrong assumption in step two can make steps three to ten wrong. Plans and checkpoints catch this early.
- Permissions matter: the agent acts with the user's access. The UI must make that scope visible and adjustable.
Not every AI feature should be an agent. Our comparison of copilot vs agent vs chat helps decide, and for smaller tasks, inline AI patterns often fit better.
How should an agent show its plan?
An agent should show its plan as a short, numbered list of steps in plain language before it starts, with the tools or systems each step will touch. Users should be able to edit, reorder, remove or approve steps, then let the agent run.
Restate the goal
One line confirming what the agent understood, such as "Find overdue invoices over $5,000 and draft reminder emails". Misunderstandings surface here, before any work is done.
List the steps
Plain-language steps, each naming the system it touches: "Search invoices in Billing", "Draft 12 emails in Gmail".
Mark risky steps
Steps that send, spend, delete or affect other people get a visible marker and will pause for approval.
Allow edits
Users can change parameters, remove steps or add constraints like "don't contact anyone in the EU accounts".
Start or schedule
Run now, run in the background or schedule. Make it clear the user can stop at any point.
For quick, low-risk tasks, a plan step adds friction. Show plans by default for multi-step or risky tasks, and let experienced users skip them for task types they've already approved.
When should an agent ask for approval?
An agent should ask for approval before any action that's hard to reverse or that affects someone other than the user: sending messages, spending money, deleting data, changing permissions or publishing content. Reading, searching and drafting usually don't need approval.
Action type | Example | Approval pattern |
|---|---|---|
Read or search | Look up account history | No approval, log it |
Draft | Write emails for review | No approval, results held for review |
Change own data | Update the user's notes | Approval optional, undo available |
Change shared data | Edit CRM records in bulk | Batch approval with a preview of changes |
External or irreversible | Send emails, pay, delete | Explicit approval per batch or item |
Show approvals as a diff where you can: what will change, from what, to what. A list of "Update 40 records" asks for blind trust. A preview of the 40 changes, with the option to exclude some, asks for review. When approvals pile up across a team, they become a review queue. Pair every approval with undo, as our guide to recovery patterns for AI errors explains.
What should an agent task log show?
An agent task log should show each step the agent took, the tool it used, the result and a link to anything it changed, in time order. It turns an opaque process into something the user can audit, debug and undo.
- Live progress: the current step highlighted, completed steps checked, remaining steps greyed out.
- Tool calls in plain words: "Searched invoices: 23 results" rather than raw function names, with details expandable for technical users.
- Links to changes: every created or edited record links to the record itself.
- Sources: when the agent used documents or web pages, show them the way you would show citations in AI answers.
- A summary at the end: what was done, what was skipped and why, and what needs the user's attention.
While the task runs, the log doubles as the loading state. Our guide to AI loading states covers how to show thinking and tool use without overwhelming users.
Hypothetical example: an agent that cleans up a CRM
For example, suppose a sales agent is asked to merge duplicate contacts. The plan shows three steps: find duplicates, propose merges, apply approved merges. Step one runs without approval and logs "Found 48 likely duplicate pairs".
Step two shows each proposed merge as a side-by-side diff, with the fields that will be kept highlighted. The user excludes six pairs and approves the rest. Step three applies the merges and links each merged record in the log, with one "Undo all merges" control available for a set period.
How do interrupt and rollback work in agentic UX?
Interrupt lets users pause or stop an agent mid-task, ideally at a safe point between steps, and redirect it. Rollback lets users reverse what the agent did after it finishes, either per action or as a whole task. Together they're what makes granting autonomy feel safe.
Pros
- Users grant more autonomy when they know they can stop and undo.
- Mistakes become cheap, so the agent can be useful before it is perfect.
- Audit and compliance teams get a clear record of what changed.
Cons
- True rollback needs engineering support in every connected system.
- Some actions, like sent emails or payments, can't be undone, only followed up.
- Pausing mid-step can leave data half-changed without careful design.
Be honest in the UI about what can be undone. Mark irreversible steps clearly in the plan, and for them, offer the closest alternative, such as drafting rather than sending. The design system components for AI products guide covers how to standardize plan, log and approval components so every agent feature behaves the same way.
How do you explain an agent product to buyers?
Explain an agent product by showing what it does step by step, with a real task, its plan, the approvals and the result, rather than describing autonomy in abstract terms. Buyers need to see where they stay in control, because that's their biggest worry about agents.
The same patterns that build trust in the product build trust on the website. Our guide to designing an AI agent website covers how to show this on a marketing page. If you're hiring help with the product itself, read how to pick an AI product design agency, and the UI/UX glossary explains terms you'll hear along the way.
