A copilot waits for you. An agent does not. You hand it a goal, close the tab and it keeps working: reading, deciding, calling tools, sometimes spending money. The interface problem changes completely, because the user is no longer in the loop by default.
This guide shows you AI agent UX patterns for software that works on its own. You will get a five point model of an agent run, seven patterns, a table of the signals to show at each point and a test you can run this week.
Key takeaways
An agent run has five points: brief, plan, watch, intervene and review. Design each one.
Make the plan visible before the agent acts, and the activity visible while it runs.
Give people checkpoints and a stop control, with limits on time, spend and scope.
Make review fast. A result nobody can check is a result nobody trusts.
Autonomy raises the cost of errors, so start with narrow tasks and widen them as trust grows.
How is designing for an agent different from designing for a copilot?
A copilot works inside the user’s attention, while an agent works outside it. That changes what the interface has to do.
With a copilot, every output is seen the moment it appears. With an agent, hours of work can pass unseen, so the interface must report on what happened, ask for judgment at the right moments and make the result easy to check afterward.
Anthropic’s engineering guide to building agents (published December 19, 2024) describes the shape: a person starts the task, the agent works on its own and returns for more information or judgment when needed, and it can pause at checkpoints or when it hits a blocker. Its authors, Erik Schluntz and Barry Zhang, state the design rule plainly: “Prioritize transparency by explicitly showing the agent’s planning steps.” They also warn that “the autonomous nature of agents means higher costs, and the potential for compounding errors.” Those are interface requirements as much as engineering ones.
For assistants that work alongside the user, see AI Copilot UX Patterns.
What is the Five Point Run?
The Five Point Run is a model of one agent task from start to finish. Each point has a different design job.
Point | What happens | What the interface must do |
|---|---|---|
1. Brief | The user sets the goal | Capture scope, limits and success criteria |
2. Plan | The agent proposes steps | Show the plan and ask for approval where it matters |
3. Watch | The agent works | Show activity, progress and cost in a calm way |
4. Intervene | The user steps in, or the agent asks | Offer pause, redirect and stop, and clear questions |
5. Review | The agent reports | Show the result, the evidence and what changed |
Most agent products invest in 1 and 5. The gaps are usually in 3 and 4, which is where trust is lost.
Which seven AI agent UX patterns matter most?
These seven cover most agent interfaces. Not every product needs all of them.
A brief with limits. Ask for the goal, the scope, what the agent may not do and when to stop.
A visible plan. Show the steps the agent intends to take, and let the user edit or approve.
An activity feed. Record what the agent did, in order, in plain words.
Checkpoints. Pause at risky or irreversible steps and ask.
Budgets and stop rules. Set caps on time, spend, number of steps and scope.
Pause, redirect and stop. Let the user step in at any point without losing work.
An evidence rich result. Show what changed, the sources used and how to undo it.
Pro tip: Design the stop button before the start button. If you cannot say what happens to half finished work when a user stops, the agent is not ready to run unattended.
How do you show a plan and activity without overwhelming people?
Show a short plan up front and a calm, scannable feed while the agent works. Detail should be one click away, not on the screen by default.
Element | Good version | Weak version |
|---|---|---|
Plan | Five or six steps in plain words, editable | A wall of tool names |
Activity feed | One line per action, with a time and a result | Raw logs |
Progress | Which step, how many left, rough time | A spinner with no meaning |
Cost | Running total against the budget | A bill after the fact |
Errors | What failed, what the agent did next | Silent retries |
Group activity by step, and let users expand a line to see the inputs and outputs.
When should an agent stop and ask?
An agent should ask when an action is hard to undo, costs money, reaches other people or falls outside the brief. Everything else it can do and report.
Hard to undo: deleting, sending, publishing, paying.
Outside scope: anything the brief did not authorize.
Ambiguous: when two reasonable readings lead to very different outcomes.
Blocked: when the agent has run out of options, say so and describe what it tried.
Over budget: when it is about to exceed a limit set in the brief.
Write each question so it can be answered in a tap: what the agent wants to do, why, and the options. Avoid asking so often that users stop reading, since a stream of low value prompts teaches people to click approve.
How do you design the review?
Make it faster to check the result than to redo the work. Review is where the user decides whether to trust the agent with more next time.
Lead with a short summary of what was done and what changed.
Show evidence next to each important claim: sources, screens or records.
Mark anything the agent was unsure about, or skipped.
Offer a one click undo for changes it made.
Let the user accept, edit or reject parts, not only the whole.
Record the outcome so the next run can use it.
For the wider question of when users decide to rely on AI, read How to Design Trust Into AI Interfaces.
How do you widen an agent’s autonomy over time?
Start with narrow, reversible tasks and widen scope as the agent earns trust. Trust grows from runs that went well and were easy to check.
Stage | The agent may | The user sees |
|---|---|---|
Observe | Read and report | Findings only |
Propose | Prepare changes | A diff to approve |
Act with limits | Apply low risk changes | A log and undo |
Act broadly | Run longer tasks | Summaries and exceptions |
Anthropic’s guidance recommends extensive testing in sandboxed environments with guardrails because errors compound. A sandbox or dry run mode, where the agent shows what it would do without doing it, is a useful pattern for building trust before real runs.
Where does agent UX usually break?
Agent UX breaks when users cannot see the plan, cannot stop a run safely or cannot check the result. Six mistakes to avoid:
No plan shown. The agent acts and the user learns afterward.
A feed full of noise. Nobody reads it, so nobody notices real problems.
No budget. One bad run can be expensive.
A stop button that loses work. Users never dare to press it.
Prompting for everything. People click approve without reading.
A result with no evidence. The user cannot tell if it is right.
How do you test an agent interface this week?
Run a task with five users and break the run on purpose.
Give each user a real task and let the agent run.
Make the agent hit a blocker, and see whether the user understands what happened.
Ask them to stop and redirect the agent halfway, and watch what happens to the work.
Seed one subtle mistake in the result and see whether they catch it in review.
Pass if most users recover without help and still say they would use it again.
Pro tip: Count how long review takes. If checking the result takes as long as doing the work, the review design has failed, however good the agent is.
To see how we design interfaces for AI products, read our ORYN AI agent monitoring landing page case study, or browse all of our case studies.
What does your agent show while it works?
Send us a flow and we will map it onto the Five Point Run. Book a design review · See our work
AI agent UX FAQs
They are repeatable interface solutions for software that works on its own: a brief with limits, a visible plan, an activity feed, checkpoints, budgets, pause and stop controls and an evidence rich result. They keep people informed and in control while the agent runs tasks outside their attention.
A chatbot responds turn by turn while the user watches. An agent runs a longer task with many steps and may finish while the user is away. So agent interfaces need plans, progress, checkpoints, budgets and a strong review step, not only a good reply.
Yes, at any point, and without losing the work done so far. A stop control that destroys progress makes users afraid to use it. Also give a pause and a redirect, and show what the agent had completed when it stopped.
Decide which actions need approval: those that are hard to undo, cost money, reach other people or go outside the brief. Let the agent do and report the rest. Keep questions short enough to answer in a tap, and avoid asking so often that users approve without reading.
Yes. Kraftbase is a product messaging and UI/UX design studio for AI and B2B SaaS companies. We design the agent interfaces and the pages that explain them together, so users and buyers understand what the agent does and where they stay in control.
One plain line per action, in order, with a time, what the agent did and what came back, grouped by step. Let users expand a line for inputs and outputs. Show errors and what the agent did next. Raw logs belong behind a click, not on the main screen.
Start with narrow, reversible tasks, make the plan and activity visible, set budgets and stop rules and make review fast with evidence. Widen the agent’s scope only as runs prove reliable. A dry run mode that shows what the agent would do is a useful first step.
About the author
Aneri is a designer at Kraftbase, a product messaging and UI/UX design studio in Vadodara, India, that helps AI and B2B SaaS teams in the US, UAE and India explain and design what they’ve built.
Sources
Building effective agents, Anthropic Engineering, Dec 19, 2024, read Nov 3, 2026
Five Point Run: Kraftbase framework, not a published standard
Design review
What does your agent show while it works?
Send us a flow and we will map it onto the Five Point Run.
A copilot waits for you. An agent does not. You hand it a goal, close the tab and it keeps working: reading, deciding, calling tools, sometimes spending money. The interface problem changes completely, because the user is no longer in the loop by default.
This guide shows you AI agent UX patterns for software that works on its own. You will get a five point model of an agent run, seven patterns, a table of the signals to show at each point and a test you can run this week.
Key takeaways
An agent run has five points: brief, plan, watch, intervene and review. Design each one.
Make the plan visible before the agent acts, and the activity visible while it runs.
Give people checkpoints and a stop control, with limits on time, spend and scope.
Make review fast. A result nobody can check is a result nobody trusts.
Autonomy raises the cost of errors, so start with narrow tasks and widen them as trust grows.
How is designing for an agent different from designing for a copilot?
A copilot works inside the user’s attention, while an agent works outside it. That changes what the interface has to do.
With a copilot, every output is seen the moment it appears. With an agent, hours of work can pass unseen, so the interface must report on what happened, ask for judgment at the right moments and make the result easy to check afterward.
Anthropic’s engineering guide to building agents (published December 19, 2024) describes the shape: a person starts the task, the agent works on its own and returns for more information or judgment when needed, and it can pause at checkpoints or when it hits a blocker. Its authors, Erik Schluntz and Barry Zhang, state the design rule plainly: “Prioritize transparency by explicitly showing the agent’s planning steps.” They also warn that “the autonomous nature of agents means higher costs, and the potential for compounding errors.” Those are interface requirements as much as engineering ones.
For assistants that work alongside the user, see AI Copilot UX Patterns.
What is the Five Point Run?
The Five Point Run is a model of one agent task from start to finish. Each point has a different design job.
Point | What happens | What the interface must do |
|---|---|---|
1. Brief | The user sets the goal | Capture scope, limits and success criteria |
2. Plan | The agent proposes steps | Show the plan and ask for approval where it matters |
3. Watch | The agent works | Show activity, progress and cost in a calm way |
4. Intervene | The user steps in, or the agent asks | Offer pause, redirect and stop, and clear questions |
5. Review | The agent reports | Show the result, the evidence and what changed |
Most agent products invest in 1 and 5. The gaps are usually in 3 and 4, which is where trust is lost.
Which seven AI agent UX patterns matter most?
These seven cover most agent interfaces. Not every product needs all of them.
A brief with limits. Ask for the goal, the scope, what the agent may not do and when to stop.
A visible plan. Show the steps the agent intends to take, and let the user edit or approve.
An activity feed. Record what the agent did, in order, in plain words.
Checkpoints. Pause at risky or irreversible steps and ask.
Budgets and stop rules. Set caps on time, spend, number of steps and scope.
Pause, redirect and stop. Let the user step in at any point without losing work.
An evidence rich result. Show what changed, the sources used and how to undo it.
Pro tip: Design the stop button before the start button. If you cannot say what happens to half finished work when a user stops, the agent is not ready to run unattended.
How do you show a plan and activity without overwhelming people?
Show a short plan up front and a calm, scannable feed while the agent works. Detail should be one click away, not on the screen by default.
Element | Good version | Weak version |
|---|---|---|
Plan | Five or six steps in plain words, editable | A wall of tool names |
Activity feed | One line per action, with a time and a result | Raw logs |
Progress | Which step, how many left, rough time | A spinner with no meaning |
Cost | Running total against the budget | A bill after the fact |
Errors | What failed, what the agent did next | Silent retries |
Group activity by step, and let users expand a line to see the inputs and outputs.
When should an agent stop and ask?
An agent should ask when an action is hard to undo, costs money, reaches other people or falls outside the brief. Everything else it can do and report.
Hard to undo: deleting, sending, publishing, paying.
Outside scope: anything the brief did not authorize.
Ambiguous: when two reasonable readings lead to very different outcomes.
Blocked: when the agent has run out of options, say so and describe what it tried.
Over budget: when it is about to exceed a limit set in the brief.
Write each question so it can be answered in a tap: what the agent wants to do, why, and the options. Avoid asking so often that users stop reading, since a stream of low value prompts teaches people to click approve.
How do you design the review?
Make it faster to check the result than to redo the work. Review is where the user decides whether to trust the agent with more next time.
Lead with a short summary of what was done and what changed.
Show evidence next to each important claim: sources, screens or records.
Mark anything the agent was unsure about, or skipped.
Offer a one click undo for changes it made.
Let the user accept, edit or reject parts, not only the whole.
Record the outcome so the next run can use it.
For the wider question of when users decide to rely on AI, read How to Design Trust Into AI Interfaces.
How do you widen an agent’s autonomy over time?
Start with narrow, reversible tasks and widen scope as the agent earns trust. Trust grows from runs that went well and were easy to check.
Stage | The agent may | The user sees |
|---|---|---|
Observe | Read and report | Findings only |
Propose | Prepare changes | A diff to approve |
Act with limits | Apply low risk changes | A log and undo |
Act broadly | Run longer tasks | Summaries and exceptions |
Anthropic’s guidance recommends extensive testing in sandboxed environments with guardrails because errors compound. A sandbox or dry run mode, where the agent shows what it would do without doing it, is a useful pattern for building trust before real runs.
Where does agent UX usually break?
Agent UX breaks when users cannot see the plan, cannot stop a run safely or cannot check the result. Six mistakes to avoid:
No plan shown. The agent acts and the user learns afterward.
A feed full of noise. Nobody reads it, so nobody notices real problems.
No budget. One bad run can be expensive.
A stop button that loses work. Users never dare to press it.
Prompting for everything. People click approve without reading.
A result with no evidence. The user cannot tell if it is right.
How do you test an agent interface this week?
Run a task with five users and break the run on purpose.
Give each user a real task and let the agent run.
Make the agent hit a blocker, and see whether the user understands what happened.
Ask them to stop and redirect the agent halfway, and watch what happens to the work.
Seed one subtle mistake in the result and see whether they catch it in review.
Pass if most users recover without help and still say they would use it again.
Pro tip: Count how long review takes. If checking the result takes as long as doing the work, the review design has failed, however good the agent is.
To see how we design interfaces for AI products, read our ORYN AI agent monitoring landing page case study, or browse all of our case studies.
What does your agent show while it works?
Send us a flow and we will map it onto the Five Point Run. Book a design review · See our work
AI agent UX FAQs
They are repeatable interface solutions for software that works on its own: a brief with limits, a visible plan, an activity feed, checkpoints, budgets, pause and stop controls and an evidence rich result. They keep people informed and in control while the agent runs tasks outside their attention.
A chatbot responds turn by turn while the user watches. An agent runs a longer task with many steps and may finish while the user is away. So agent interfaces need plans, progress, checkpoints, budgets and a strong review step, not only a good reply.
Yes, at any point, and without losing the work done so far. A stop control that destroys progress makes users afraid to use it. Also give a pause and a redirect, and show what the agent had completed when it stopped.
Decide which actions need approval: those that are hard to undo, cost money, reach other people or go outside the brief. Let the agent do and report the rest. Keep questions short enough to answer in a tap, and avoid asking so often that users approve without reading.
Yes. Kraftbase is a product messaging and UI/UX design studio for AI and B2B SaaS companies. We design the agent interfaces and the pages that explain them together, so users and buyers understand what the agent does and where they stay in control.
One plain line per action, in order, with a time, what the agent did and what came back, grouped by step. Let users expand a line for inputs and outputs. Show errors and what the agent did next. Raw logs belong behind a click, not on the main screen.
Start with narrow, reversible tasks, make the plan and activity visible, set budgets and stop rules and make review fast with evidence. Widen the agent’s scope only as runs prove reliable. A dry run mode that shows what the agent would do is a useful first step.
About the author
Aneri is a designer at Kraftbase, a product messaging and UI/UX design studio in Vadodara, India, that helps AI and B2B SaaS teams in the US, UAE and India explain and design what they’ve built.
Sources
Building effective agents, Anthropic Engineering, Dec 19, 2024, read Nov 3, 2026
Five Point Run: Kraftbase framework, not a published standard
Design review
What does your agent show while it works?
Send us a flow and we will map it onto the Five Point Run.