Designing approval screens for agent actions

Show the actual consequence before approval

An approval screen should identify the action, target, important values and any irreversible effect. Present enough supporting context for a person to judge whether the action matches the request. Avoid asking for a vague approval of an agent's plan when the eventual write could differ. Approval should be tied to the specific operation being executed.

Worked example

Illustrative scenario; not a claim of measured client results.

For an email action, show the recipients, subject, body and attachments. For a record update, show the record identity and changed fields. If the agent alters a material value after approval, obtain a new decision or apply a clearly defined rule. A single Approve button beside a generic summary can hide the information the reviewer needs.

Checks, limitations and next decisions

Test rejection, cancellation, expired approvals and repeated submission. Confirm that the system does not execute when the reviewer closes the screen or when the approved action has changed. Keep a record of the approved version and execution result. The goal is a real decision boundary, not a ceremonial click that shifts responsibility without giving the user control.

A practical starting point

Work through these checks in order. Use the results to decide what needs to change in your own workflow.

1. Show the action, destination and relevant data.
2. Highlight irreversible or externally visible consequences.
3. Allow the reviewer to edit or reject before execution.

A mistake to avoid

Do not combine unrelated consequential actions into an opaque approval.

How to check progress

Track edits and rejections to identify where the agent needs better constraints.