Original practice question. The scoring rubric is our teaching guide. How we research and score answers
TL;DR: Give users an activity feed of everything the assistant did, in plain language with links to the affected items; make every reversible action undoable for a sensible window, ideally individually and in bulk; clearly mark actions that cannot be undone and require confirmation before them; and notify users at the right moments without overwhelming them. Use undo rates as a quality signal.
How to approach it
Classify the assistant's actions by reversibility, then design three things: what users see while and after actions happen, how undo works, and how irreversible actions are handled. Consider notifications and how the data feeds back into quality.
A strong answer
Take a workspace assistant in a project management tool that can create tasks, reassign work, update due dates, move items between projects, archive old items, and send messages to teammates.
Classify by reversibility.
| Action | Reversible? | Treatment |
|---|---|---|
| Create, edit, move tasks | Yes | Act, log, undo |
| Archive items | Yes | Act, log, undo |
| Reassign work | Yes, but others are notified | Confirm if it affects others; undo also notifies |
| Change due dates | Yes, but others may react | Log, undo; highlight if many items affected |
| Send messages to teammates | No | Draft for approval |
| Delete permanently | No | Never by the assistant; route to the user |
The activity feed. A dedicated view listing everything the assistant did, grouped by request: "You asked: tidy up the Q3 launch project. I archived 14 completed tasks, moved 3 tasks to Q4, and updated 2 due dates." Each item links to the affected object and shows before and after values.
Undo.
- Per action and per request. Undo one change or everything from a request.
- A clear window. Undo available for a defined period, after which changes are permanent (or recoverable from trash).
- Undo that really reverses. Restores previous values, re-sends notifications where appropriate ("Task returned to Priya"), and handles conflicts (if someone edited the item since, show both versions).
Irreversible actions. Never surprise users. Draft and require confirmation, showing exactly what will happen ("Send this message to 6 people in #launch-team"). The application renders the confirmation from the pending action itself; the model never writes it. Where the action allows, add a short hold before it executes, the way Gmail's undo send lets a user set a cancellation period of 5 to 30 seconds.
Notifications. For actions within an active session, inline confirmation is enough. For background actions, a digest ("While you were away, I updated 8 tasks") instead of a notification per change.
Undo state comes from the system, never from the agent. In July 2025 a Replit agent deleted data from a user's database during a declared code freeze and then told the user a rollback would not work; Fortune reported that the user recovered the data manually. Replit's CEO called it unacceptable and announced automatic separation of development and production databases, rollback improvements and a planning-only mode. The model's account of what can be reversed was wrong, and that account was the user's only guide in the moment. Show what undo covers from the application's own records.
Be exact about scope, too. Claude Code's checkpointing documentation (checked 6 November 2026) says rewind restores edits made by its file editing tools, that a file changed only by shell commands is not tracked, and that Git remains the recovery path for those. That is an honest undo contract: it names what it does not reverse. Write the equivalent for this assistant, and show it next to the undo button.
Feedback loop. Undo is the most honest quality signal an action-taking assistant gets. Track undo rate by action type and request type; spikes after a model or prompt change are regressions. Ask, lightly, why on undo ("Wrong items", "Wrong project", "Didn't want this").
What interviewers probe next
"The assistant changed 200 items and the user wants half of them back." Bulk undo with filters (by project, by action type), plus a preview of what undo will restore.
"Can undo reverse everything the assistant did?" No, and the product should say which parts it cannot: messages already read, notifications already delivered, anything an external system acted on. List them in the activity feed against the action, so the user learns it before needing it.
"An undo conflicts with a teammate's later edit." Show the conflict and let the user choose; never silently overwrite someone else's work.
How it's scored
| Signal | Weak | Hire | Strong Hire |
|---|---|---|---|
| Visibility | Notifications only | Activity log | Feed grouped by request with before and after values and links |
| Undo | Single undo button | Per-action undo | Per action and per request, defined window, real reversal including notifications and conflicts |
| Irreversible and feedback | Not distinguished | Confirmation for risky actions | Reversibility classification, app-rendered confirmations, digests, undo rates and reasons as quality signals |
Common mistakes
Undo that restores values but not the notifications others received.
A notification for every single change.
Treating irreversible and reversible actions the same way.
See risk and reversibility and measuring trust.