Approval buttons need context

“Approve tool call” is not a decision a person can make.

The button may be fine. The card around it is doing the real work. I need to know what changes, where it changes, under which identity, and what happens if I say yes.

For a local file edit, that might be enough:

action: edit local file
target: src/content/blog/example.mdx
change: replace the current body
after approval: write file, run markdown check
undo: restore previous contents from git diff

The exact fields vary with the side effect. An email needs recipient, subject, and body. A calendar change needs time, attendees, and timezone. A database write needs table, filter, row count, and fields. A tool name such as updateRecord is implementation language. The arguments are the real interface.

Risk should control how much context is visible. A read-only lookup can stay compact. A file write needs the target and diff. An external write or identity boundary should start expanded. Hiding the important details behind a “more” link makes the card tidy and the decision worse.

Timing matters too. If an approval arrives after the agent has taken ten intermediate steps, reconnect the user to the original request. What is this step? What is already done? What remains if I approve? Approval is permission for one move, not a declaration that the whole run is correct.

The agent should not argue for the click. “I need this to finish your request” is pressure, not evidence. Show the file, the scope, the relevant check, and the reason the system believes this is the next action.

Denials are useful signals. “Wrong file,” “too broad,” “show me the diff,” and “stop” should feed recovery and product improvement rather than ending as unexplained rejection events.

After the action, leave a receipt:

approved by: jeremy
approved action: edit local markdown file
approved target: src/content/blog/example.mdx
executed: yes
verification: markdown check passed

That record lets the next reviewer compare the approved plan with the actual side effect.

I do not want an approval step everywhere. Too many turn the user into a click-through operator. When the action matters, though, the button has to earn the click.