Design the interface around one loop: the agent previews its plan, the user approves anything that writes or sends, the agent acts, every step lands in a readable activity log, and undo is close at hand. Google's People + AI Guidebook and Microsoft's Guidelines for Human-AI Interaction point the same way: calibrated trust, visible reasoning and easy correction.

Picture an operations lead who asks the new in-app agent to "clean up the duplicate customer records from last week's import." The agent finds a few hundred likely matches, merges them and reports "Done." Two days later sales notices that two different companies with similar names are now one record, with one company's contacts and invoices attached to the other. Nobody saw the plan, nobody approved the merge, and there is no button that puts the records back.

The model did roughly what it was asked. The interface is what failed. It gave the agent the power to act without giving the person a way to see, steer or reverse what it did.

What makes designing for an AI agent different from designing for a chatbot?

An AI agent takes actions in your product, so its mistakes change data instead of just producing a bad answer. An AI agent is software that uses a model to plan and carry out multi-step tasks by calling tools, such as updating records, sending messages or filing tickets.

A chatbot's output is text a person reads; an agent's output is a changed system. That moves the design question from "is the answer good?" to "what did it do, was that allowed, and can we take it back?"

Two public sets of design guidance help here, though both predate today's agents: the People + AI Guidebook from Google's People + AI Research (PAIR) team, and Microsoft's Guidelines for Human-AI Interaction, 18 guidelines first presented in a 2019 CHI paper and published with design patterns in the HAX Toolkit. Their advice on trust, control and correction maps closely onto an agent's loop.

What is the approval loop for an AI agent?

The approval loop is five steps the interface runs for every task: plan preview, approve, act, activity log and undo. Each step answers a question the user will otherwise ask too late.

1. Plan preview. Before doing anything, the agent shows what it intends to do in plain language: which records, which tools, which changes. When the request is ambiguous, it asks first. This is HAX Guideline 10, Scope services when in doubt, whose first pattern is "Disambiguate before acting."

2. Approve. The user confirms, edits or rejects the plan before any write. The PAIR Errors + Graceful Failure chapter says that "In the case of higher situational stakes, there should be an additional check." An approval step is that check, placed where it still prevents harm.

3. Act. The agent runs the approved plan and shows progress and how sure it is. HAX Guideline 2, Make clear how well the system can do what it can do, asks you to "Help the user understand how often the AI system may make mistakes," which here means flagging the steps the agent is least sure of.

4. Activity log. Every action is recorded with what changed, when, and why the agent chose it. This is HAX Guideline 11, Make clear why the system did what it did: "Enable the user to access an explanation of why the AI system behaved as it did."

5. Undo. Any reversible action can be reversed from the log, one action or one whole run at a time. HAX Guideline 9, Support efficient correction, lists "Undo automated actions" as one of its patterns.

Which agent actions need approval before they run?

Actions that write, send, spend or delete need approval; actions that only read or draft usually don't. Asking for approval on everything trains people to click "Approve" without reading, so match the friction to the risk.

The PAIR Feedback + Control chapter describes "an essential balance between automation and user control." This list is one way to strike that balance.

• Read. Example: Search records, summarise a thread. Reversible: Nothing to reverse. Interface pattern: Run without asking; show in the log.

• Draft. Example: Write an email or a report, but don't send. Reversible: Yes, discard the draft. Interface pattern: Run, then present for review.

• Reversible write. Example: Tag tickets, update a field, merge with history kept. Reversible: Yes, if you store the old value. Interface pattern: Plan preview with one approval for the batch; undo from the log.

• Irreversible write. Example: Hard delete, overwrite without history. Reversible: No. Interface pattern: Item-level approval, a clear warning, and a typed or second confirmation.

• External effect. Example: Send an email, post a message, make a payment. Reversible: No, once it has left. Interface pattern: Approval on the exact content and recipient, every time.

Two refinements help. First, let users set the threshold themselves, which is HAX Guideline 17, Provide global controls: "Allow the user to globally customize what the AI system monitors and how it behaves." Second, approve plans, not keystrokes. One approval for "merge these pairs, here is the list" is better than a pop-up for every pair.

How should an agent show its work and its confidence?

An agent should show its work as a step-by-step activity log a non-technical user can read, and its confidence as plain-language flags on the specific items it is unsure about. A single overall "confidence: 87%" helps nobody decide what to check.

Write the activity log for people, not for engineers

An activity log is a running, timestamped record of each action the agent took, the data it touched and the reason it gave. Write each entry as a sentence: "Merged Acme Ltd into Acme Limited because the VAT numbers match." Link each entry to the record it changed, and group entries by run so a person can review one task as a whole.

Show confidence where it changes a decision

PAIR's Explainability + Trust chapter says that "Confidence displays help users gauge how much trust to put in the AI output," and warns that "Numeric confidence indicators are risky because they presume your users have a good baseline understanding of probability." In practice, sort the plan so the least certain items come first, label them in words ("names match, addresses don't"), and pre-select only the items the agent is sure about. The same chapter puts the aim plainly: users should "calibrate their trust correctly," trusting the system in some situations and double-checking it in others.

How do you design undo for actions an agent has already taken?

Design undo into the data model first and the button second: an action can only be undone if the system kept what it changed. Store the previous value, the agent run that changed it and the time, for every write the agent makes.

Three levels of undo

• Undo one action: reverse a single entry from the activity log, such as unmerging one pair.

• Undo one run: reverse everything a single task did, in reverse order.

• Take over: stop the agent and hand the task back to the person. PAIR's Errors + Graceful Failure chapter notes that "When an AI system fails, often the easiest path forward is to let the user take over."

When undo is impossible, move the check earlier

A sent email or a completed payment can't be recalled. For those, the safeguard has to sit before the action: approval on the exact content, a short delay with a cancel option before sending, or a draft the person sends themselves. Be honest in the interface about which actions are final, so "Undo" never appears where it can't work.

How do you know if the agent interface is working?

You know it is working when people can answer three questions without asking an engineer: what did the agent do, why, and how do I reverse it? Test with real users on real tasks, and watch where they hesitate.

Checklist before launch

• Every write, send, spend or delete has a plan preview the user can edit.

• Approval friction matches the action type, and users can adjust it.

• Uncertain items are flagged in words and listed first.

• Every action appears in a readable activity log, linked to the record it changed.

• Reversible actions can be undone one at a time and one run at a time.

• Irreversible actions are clearly labelled as final before approval.

• A user can stop the agent mid-run and take over.

• Rejections and undos are recorded, so the team can see which kinds of tasks the agent gets wrong.

That last item is how the loop improves over time. A cluster of undos on one kind of task says the plan preview should ask a question it currently doesn't.

How we approach it at Vizio AI

We design the loop before we design the screens. With the client, we list every action the agent will be allowed to take and sort each one into the action types in the list above. That list decides where approvals sit, what the activity log must record, and which actions need stored history so undo is possible.

Then we prototype the plan preview and the activity log with realistic data, including messy and ambiguous cases, and put them in front of the people who will supervise the agent. We test whether they can say what the agent will do before approving, and reverse it afterwards, without help. Engineering builds the history and undo paths into the data model from the first sprint, because adding them later usually means a rewrite.

This is part of how our Venture Studio builds AI products. If your app is still taking shape, Why Product Discovery Should Happen Before Development covers the step before any of this. If you built it with AI coding tools, Your AI-Built App Works in the Demo. Here's What Breaks With Real Users is the launch checklist.

Sources

• Google PAIR, People + AI Guidebook: https://pair.withgoogle.com/guidebook/

• Google PAIR, People + AI Guidebook, Explainability + Trust: https://pair.withgoogle.com/chapter/explainability-trust/

• Google PAIR, People + AI Guidebook, Feedback + Control: https://pair.withgoogle.com/chapter/feedback-controls/

• Google PAIR, People + AI Guidebook, Errors + Graceful Failure: https://pair.withgoogle.com/chapter/errors-failing/

• Microsoft HAX Toolkit, Guidelines for Human-AI Interaction: https://www.microsoft.com/en-us/haxtoolkit/ai-guidelines/

• Microsoft HAX Toolkit, Guideline 2: Make clear how well the system can do what it can do: https://www.microsoft.com/en-us/haxtoolkit/guideline/make-clear-how-well-the-system-can-do-what-it-can-do/

• Microsoft HAX Toolkit, Guideline 9: Support efficient correction: https://www.microsoft.com/en-us/haxtoolkit/guideline/support-efficient-correction/

• Microsoft HAX Toolkit, Guideline 10: Scope services when in doubt: https://www.microsoft.com/en-us/haxtoolkit/guideline/scope-services-when-in-doubt/

• Microsoft HAX Toolkit, Guideline 11: Make clear why the system did what it did: https://www.microsoft.com/en-us/haxtoolkit/guideline/make-clear-why-the-system-did-what-it-did/

• Microsoft HAX Toolkit, Guideline 17: Provide global controls: https://www.microsoft.com/en-us/haxtoolkit/guideline/provide-global-controls/