Definitions

Definitions

The layers

Results

1. Collapsing detail is safe only if critical events are exempt; the invariant is part of the design, not an accident.
2. Fewer, better prompts beat more prompts under any model where attention declines.
3. Asking has a price: the margin sets how many questions the person answers; choose it from the cost of a wrong action.

Design rules

• Answer the three questions on every screen: doing now, needs me, stop or undo.
• Layer the detail: status line, attention, grouped timeline, expandable detail.
• Never collapse approvals or unrecovered errors.
• Tier approvals; batch the medium ones; preview and confirm the high-risk ones; expire as deny.
• Give an undo for every reversible action and a delayed commit for outbound messages; label irreversible actions clearly.
• Offer pause, resume, cancel and "add a correction" and save progress.
• Let users choose autonomy per task or action type.
• Express uncertainty only when calibrated; otherwise show sources instead of adjectives.
• Ask one or two focused questions, explain why, and remember earlier answers.
• Fail with state preserved, a plain explanation and a next step (retry, rephrase, human).

Interview questions, with the follow-ups

Common mistakes

• Streaming every internal event to the user.
• Hiding errors or approvals inside a collapsed log.
• Asking for approval on everything, then on nothing.
• No undo, or an undo that silently fails.
• A progress bar that is not tied to real steps.
• Confident wording with no source or calibration.
• Many questions at once, or questions the user already answered.
• No way to stop a long run.
• Starting over after a failure instead of resuming.
• Not testing with real users until the end.

What the example does not do

• No real UI: it is a view model and policy logic; layout, accessibility, animation and mobile behaviour are not covered.
• The fatigue model is invented; real attention depends on stakes, wording, training and context, so the percentages are only illustrative.
• The ambiguity model is invented: real models' scores are not Gaussian noise around fixed means.
• Event streams are random, not recorded from a real agent.
• No user testing: I measured items shown and invariants, not comprehension, trust or time to notice an error.
• The undo log is in memory, with no persistence, concurrency or third-party side effects.
• Optional real experiment (I did not run this): show five users a real agent run in the raw log and in the layered view, plant one risky approval, and measure completion time, whether they caught the risky item, and how they rate trust.

For the curious Fewer prompts protect the dangerous ones

With an assumed attention model in which the chance of reading a prompt falls 7 percent with each one answered, asking about all 20 actions led to only 52 percent of the 2 risky actions being read; tiered prompting 79 percent, tiered and batched 86 percent. Asking when the margin between readings is under 0.2 cut wrong actions from 13.3 to 1.5 percent at 44 percent asks. Parameters are mine; the lesson is general.

What you must be able to say (one page)

• The interface decides whether people trust and use the agent. Every screen must answer three questions: what is it doing now, what needs me, and how do I stop or undo it? Four UX principles follow for agent applications: capability discovery, cost-aware delegation, observability and provenance, and interruptibility.

• Show progress in layers, not as a log. (1) A one-sentence status line ("Working (3 of 8 steps): reading page 3"); (2) a needs you area for approvals and unrecovered errors, never collapsed; (3) a timeline with grouped steps and details on demand; (4) changes and controls (what was changed, undo, pause, cancel, add a correction). In my simulation (20 runs averaging 82 events) a raw event log showed 82 items, a grouped timeline (merge repeated tool calls, fold results into calls, hide thoughts) 26, and status plus attention plus changes 1.4, with every unresolved approval and unrecovered error still visible in the default view (a tested invariant).

• Approvals: tier them, batch them, default to no. Low-risk reversible actions run automatically and are logged and undoable; medium ones are batched into one review; high-risk or irreversible actions get a preview of the exact change and explicit confirmation; an unanswered request expires as denied. The reason is approval fatigue: with an assumed attention model (the chance of really reading a prompt falls 7 percent with each prompt answered), asking about all 20 actions in a session led to only 52 percent of the 2 risky actions being actually read, tiered prompting (6.4 prompts) 79 percent, tiered and batched (3.0 prompts) 86 percent. The parameters are mine; the lesson (fewer, better-placed prompts protect the dangerous ones) is general. See Level 10 module 5.
• Autonomy should be adjustable. Offer a range from fully manual, through assisted "Ask" mode, to fully autonomous, so behaviour matches user preference, task complexity and context.
• Undo is the best safety feature. Keep an action log with inverse operations, show what changed, and make irreversible actions explicit (my log refuses to undo an email and lists it as irreversible). For outbound messages use a delayed commit ("undo send" window): in my tests a message cancelled inside a 10-second window never went out, and a cancel after the window failed cleanly.
• Interruptibility. Give simple pause, resume and cancel controls, smart resume that catches users up on what happened during the pause, gentle interruption (adding a requirement without stopping everything) and saved progress. Long runs need durable state (Level 11 module 3) to support this.
• Uncertainty: say it when it is calibrated, ask when it matters. Express confidence through explicit statements, visual cues and behaviour such as offering suggestions rather than firm recommendations when confidence is low, and avoid sounding overconfident. Ask focused clarifying questions rather than make risky assumptions, without asking too many at once. In my simulation (three possible readings of a request, noisy scores, assumed): acting on the top reading always gave 13.3 percent wrong actions and asked 0 percent; asking when the margin between the best two readings is under 0.1 gave 4.9 percent wrong, 22 percent asks; under 0.2, 1.5 percent wrong, 44 percent asks; under 0.3, 0.3 percent wrong, 65 percent asks. Words such as "I am fairly sure" only help if the probability behind them is calibrated.
• Fail gracefully. Give clear explanations, fallbacks (for example moving from voice to text), preserve progress so users resume rather than restart, use empathetic wording, and offer clear paths to resolution such as human escalation.
• Show provenance and cost. Sources for claims (Level 12 module 2), which agent or tool did what, and what a run will cost before a large one starts (cost-aware delegation; Level 11 module 5).
• Evaluate interfaces with people: task completion, time to notice an error, approval accuracy (did they catch the planted risky action?), trust and satisfaction, and where they pause or cancel. Test with five or so real users before polishing (the project's done-when criterion).
• Honest limits: my code is a framework-free view model and policy logic with tests, not a web UI, and the fatigue and ambiguity numbers come from assumed human and model behaviour, not user studies.