A practical method for specifying what an agent may do, how people can intervene, and what a team must test before release.
An agent that prepares the right action but carries it out without permission has not completed the task well. I would start an agent interaction review with a simple question: can the person predict, constrain and correct what happens next? The useful design artefact is not another conversational mockup. It is a set of decisions that product, design and engineering can implement and test.
This article develops the practical side of The Future of UX Design in the Age of AI. That companion piece explains the broader shift in UX. Here, I focus on the working method: an action-permission map, a state model, a recovery plan and a test suite.
Write the intended result in ordinary language before describing the agent. Identify who requested it, which information the system may use, which resources it may change and when its authority ends. Separate access to information from permission to act on it. Being able to read a calendar should not automatically permit sending invitations.
Illustrative scenario, not a shipped-project claim: a service-coordination assistant helps someone move an appointment. It can compare available times and prepare a proposed change. It cannot contact the customer or replace the existing booking until the person authorizes that specific action. This deliberately small scenario makes the permission boundary inspectable.
The design brief should also state what the assistant will not do. In this scenario, it does not change the service address, add paid work or infer consent from silence. These exclusions become test cases, not footnotes.
Avoid treating autonomy as one global on/off switch. Map each action to a permission level and a consequence. I would use three working categories: prepare without commitment; execute within an explicit, limited delegation; and request approval before committing. Some actions should remain outside the agent's authority altogether.
For the appointment scenario, the map might read:
Record how a delegation expires and how it can be revoked. If the recipient, time, cost or scope changes after approval, invalidate the old confirmation. A button labelled Continue is too vague when it actually means replace a booking and send a message.
Define the states before polishing the conversation: preparing, waiting for approval, executing, completed, partially completed, cancelled and failed. For each state, specify what the person sees, which controls are available and what event moves the task forward. Do not report completion merely because a request was sent to another service.
A useful update is specific: Two times are available. Your original appointment is unchanged. Waiting for you to choose. After execution, the receipt should distinguish the booking change from the notification, because one may succeed while the other fails.
Expose uncertainty where it affects a choice. If a calendar has not refreshed, say which availability is stale and offer a refresh or manual check. Do not turn missing evidence into a confident recommendation or display a numerical confidence score without a justified interpretation.
Status needs to work beyond a visual spinner. W3C's guidance on status messages is a useful implementation reference for conveying updates to assistive technologies without unnecessarily moving focus. Test the actual announcements and keyboard path; a labelled frame in a design file proves neither.
Specify what Stop means at each stage. Before commitment, it should prevent the pending action. During execution, the interface must explain whether cancellation is still possible. If the external operation cannot be cancelled, do not promise that stopping the assistant will reverse it.
Keep editable assumptions close to the proposal: the selected time, time zone, customer and intended notification. A correction should update the proposal and its approval state, not silently carry forward permission from an earlier version. Preserve the person's edits when a refresh or retry occurs.
Distinguish undo from a compensating action. Restoring an appointment may be possible; retracting a message someone has already read is not the same thing. When reversal is limited, explain the consequence before commitment and provide the appropriate recovery route afterwards.
Plan for partial success. Suppose the appointment changes, but the notification times out. The result should say exactly that, retain the confirmed booking details and offer to retry only the notification. Re-running the entire task could create another change or a duplicate message.
The engineering contract should specify how repeated requests are recognized, how the committed state is checked and when an unresolved operation is escalated. The interface must not turn an unknown outcome into either a success toast or an automatic retry. Show what is known, what is not and what the person can safely do next.
Google's People + AI Guidebook is useful here because it treats feedback, control and failure handling as product concerns. I would translate those principles into named recovery states and ownership, rather than leave them as a general instruction to make the agent trustworthy.
A receipt should answer who requested the change, what was approved, which version of the proposal was executed, what changed and what remains unresolved. Keep the record proportionate: it is not a reason to expose private customer data or internal model reasoning.
Assign an owner for failures the person cannot resolve. A generic Contact support link is weak if the next team cannot see the relevant task state. Define the handoff information, the safe amount of context to retain and the route for resuming or closing the task.
Test behaviour, not whether the conversation sounds reassuring. The following are proposed acceptance criteria for the illustrative appointment assistant, not results from a completed evaluation:
Agree on launch thresholds with the team before testing. Any observed unauthorized commitment should block release of this workflow until corrected and retested. For comprehension measures, define the participant tasks and acceptable error level rather than borrowing a universal percentage. Retest when the model, tools, permissions or interaction rules change.
The handoff is four connected artefacts: an action-permission map, a state-and-transition model, a recovery specification and an acceptance suite. Each needs an owner and a verification method. A fluent response is not evidence that the system respected any of them.
Trust becomes more concrete when a person can see the proposed consequence, make a meaningful choice, correct an assumption and recover from a failure. That is the standard I would design towards: not maximum autonomy, but useful authority that remains understandable and bounded.
The Future of UX Design in the Age of AI — the strategic companion on what is changing in UX and why.
Google People + AI Guidebook: Feedback + Control — guidance for balancing automation, feedback and user control.
W3C: Understanding Status Messages — implementation guidance for accessible status updates.
