AI agent user experience: keep people in control
Design agent interfaces that show the permitted task, support precise corrections and make approvals meaningful, without inventing confidence scores.
An agent interface should make the delegated task visible and let people correct, limit or stop it. Show what the system can read or change, distinguish a draft from an external action, and connect any approval to the exact proposal it authorises.
Ask an assistant to update a guide but keep it as a draft. It should show the draft and its sources, not publish it because the text looks finished. Correcting the version number should update that draft without silently changing the audience or permissions.
A fluent conversation can hide a basic misunderstanding: the user asked for a draft, while the assistant is preparing to publish. The interface should expose that difference before anything leaves the application. A friendly tone cannot repair a missing control.
Show the task before promising the result#
In this illustrative design, a documentation assistant receives: “Update the CSV guide for version 2.3, but keep it as a draft.” It can read the connected manuals and save a proposed revision. Publishing to the public site is a separate operation that this request does not authorise.
Show the guide, product version and destination beside the task. The completion view should say that a draft was saved and offer “Open draft”, not imply that readers can already see the update. Keep the source references near the changed claims so the user can inspect them.
Chapter 3 of Albada’s book discusses communicating capabilities and maintaining trust. Microsoft’s Human-AI Interaction guidelines similarly address capability disclosure, correction, dismissal and control. The draft workflow here is our application of those principles, not a usability result reported by either source.
Let people correct one thing#
Suppose the assistant used the desktop manual, but the user meant the web application. Let the user correct the product variant while preserving “version 2.3” and “draft only”. Show which claims need to be checked again. Regenerating everything without explaining what changed makes a small correction expensive to review.
A useful correction can be a field, a comment attached to a passage or a chat message. The important property is that the application applies it to the right proposal and retains the constraints that still hold. The design does not require a chat-only interface.
Offer access to the earlier draft and a comparison of changes. Do not describe a revision as corrected merely because the model apologised. The source selection and resulting text must actually reflect the new product variant. Tracing the retrieved evidence helps diagnose a correction that changes the wording but keeps the wrong manual.
Try it: change one part of a draft task
- Keep version 2.3 and draft-only scope.
- Replace the desktop source with the web manual.
- Recheck claims affected by that source change.
A local correction changes evidence selection, not publication permission.
Illustrative interface states; no draft or publication occurs.
A clarification is not permission#
“Do you mean the web application?” resolves the subject. It does not ask whether to publish. A “yes” to that question must not approve a public update. Store what the answer applies to rather than treating any positive reply as permission to continue with every planned action.
If the user later requests publication, present the particular draft, destination and relevant consequences. In this example, the approval is tied to that revision. Changing its audience or material content invalidates that approval; the system must check the revised action rather than reuse a generic approval flag.
This is a proposed policy for the example, not a rule that every read needs a modal dialog. OWASP’s excessive-agency guidance recommends limited privileges, approval for high-impact actions and downstream authorisation. The interface communicates the decision; the execution path enforces it. For the saved-question and resume mechanism, see when an agent stops and asks.
Explain what is known and what is missing#
The chapter illustrates uncertainty with numerical confidence statements. We do not carry those numbers into this interface as measured probabilities. A generated “90% confident” does not tell the user which manual was checked or establish that comparable claims are correct nine times out of ten.
Show the decision-relevant gap instead: “The version 2.3 web manual covers CSV export. I have not found its behaviour for an empty selection.” The user can inspect the source, supply missing information or leave that claim out of the draft.
A product that displays probabilities needs an evaluation showing how those estimates relate to actual outcomes on relevant cases. The recommendation here is narrower: do not label an untested self-assessment as calibrated certainty. Likewise, a list of source links is useful only when the sources support the adjacent statements.
Make stopping and remembering understandable#
Stopping preparation can prevent further edits while retaining the saved draft. It cannot promise to recall a publication already accepted by another service. Report what is saved, what has stopped and any external action whose result is still unknown. The interface must not offer an “undo everything” promise that the tools cannot fulfil.
Keep notification preferences separate from execution permission. Muting progress messages should not approve publication; an urgent question should not silently override a user’s chosen notification policy. Decide which events warrant interruption and explain the available controls.
A correction can apply to this draft, this project or a saved preference. Make that scope inspectable and editable. “Use the web manual here” should not become “always ignore desktop documentation”. The memory guide explains why storing a preference and training a model are different operations.
Test whether people can recover from a mistake#
For a usability session, deliberately start with the wrong product variant. Ask the participant to correct it, find the supporting source and stop before publication. Observe whether they can explain what changed and what remains private. This is a proposed test, not evidence that the design has already passed.
Separately test the backend: a clarification must not authorise a write, an old approval must not apply to a changed revision, and a stopped task must not schedule new actions. Add those conditions to the evaluation set. A screen that looks controllable and a system that enforces control are two things to verify.
Questions people also ask
2 QUESTIONSDoes every agent action need a confirmation dialog?
No. The product needs an explicit policy for permitted actions and their consequences. Ordinary investigation can proceed within that scope. A confirmation is useful when a person must make a consequential decision, not as a substitute for permissions enforced by the application.
Should an agent display its entire reasoning process?
Give the user the information needed to judge the proposal: relevant sources, assumptions, changes and unresolved questions. A long generated explanation is not proof that the action is correct. Link to inspectable results rather than requiring people to read every intermediate step.