Before an AI agent acts, show me what it can change

“Allow this action” is a difficult question to answer when I can’t see what the action actually does.

Which file will change? Who will receive the message? Is the agent preparing a draft, or sending it?

Before I approve an action, I want those details in front of me.

I’m KAT, co-founder of 123sudo. I work on product experience, creative direction, and growth. A recent conversation here on DEV got me thinking about what an understandable approval screen should show.

This is a product-design perspective, not a security specification or an announcement of existing features in our AI workspace, 9xchat.

Connected doesn’t mean approved

Connecting a tool makes certain actions available. It shouldn’t make the user guess which of those actions an agent is about to take.

An email tool might let an agent:

• Read a message.
• Prepare a reply.
• Save a draft.
• Send the reply.

Those are different outcomes.

The same goes for files. Reading a document is different from overwriting it.

I’d want the interface to distinguish between:

This tool is connected.

And:

This action is permitted for the current task.

That distinction matters more to me than a long list of integration names.

Show the outcome, not just the tool

A technical tool name may help a developer understand what’s happening. It may tell another user very little.

Compare these two approval requests:

Allow send_message?

And:

Send this email to Alex at an external address, with the attached project brief?

The second gives me something I can check.

For an email, I’d want to see:

• The sender account.
• The recipient, including CC and BCC.
• The subject and message.
• Any attachments.
• Whether the action sends immediately or saves a draft.

For a file edit, I’d want:

• The target file and its location.
• The proposed changes.
• Whether it creates, edits, or overwrites something.
• Any relevant limits on undoing the action.

The preview should answer a simple question:

What will be different after I click approve?

Build the preview from the pending action

Someone in the DEV discussion made a useful distinction: the preview should come from the tool call itself, not just the agent’s summary.

That changed how I thought about the interface.

An agent might say:

I’ll send the brief to Alex.

But the pending action contains the details that matter: the actual address, message, and attachments.

A reassuring explanation isn’t enough if it doesn’t match those details.

My design preference would be to show a readable explanation alongside the relevant fields from the pending action.

The explanation helps me understand. The fields help me verify.

And that preview alone isn’t a guarantee. The system still needs to enforce that the approved action is the one executed.

Approval should belong to a specific action

Imagine I approve a message.

Then the agent changes the recipient, adds an attachment, or rewrites the body.

Does my earlier approval still apply?

For changes like those, I’d expect a fresh approval.

Otherwise, I’m approving one thing and potentially getting another.

This is a principle I’d want the system to enforce, not just a promise written on the button:

Approve this action, with these details.

Warnings need words, not just colours

A coloured border might draw attention to an external recipient or a file outside the task folder.

But colour alone shouldn’t carry the meaning.

I’d pair it with a clear label:

• External recipient
• Outside the selected task folder
• Overwrites an existing file

Then explain why it matters.

For example:

This attachment will be sent to an address outside your organisation.

That tells me what I’m deciding. A red icon by itself doesn’t.

More prompts don’t automatically mean more control

I don’t want an approval dialog for every tiny step.

If every action gets the same warning, the interface risks teaching people to click through without reading.

I’d rather see understandable boundaries at the start of a task, followed by specific approval requests when the agent reaches an action outside those boundaries.

For example:

You can read the selected files and prepare a draft. Ask before editing files or sending messages.

That’s easier to reason about than an unexplained “full access” setting.

The right boundary will depend on the task, the sensitivity of the information, and the tool. Reading can matter too, especially when private information is involved.

What I’d want to see before execution

My starting checklist would be:

1. Access: What information can the agent read?
2. Actions: What can it create, change, send, or delete?
3. Targets: Which accounts, recipients, files, or folders are involved?
4. Approval: Which actions require me to review the exact details?
5. Changes: What happens if the action changes after I approve it?

This isn’t a complete security model. It’s a way to make the user’s decision less vague.

Clear previews still need reliable permission checks and execution controls behind them.

Trust needs something concrete to check

As a co-founder helping shape an AI workspace, I’m interested in interfaces that make an agent’s actions understandable.

Not because the agent should explain every internal step.

Because when it changes something on my behalf, I should understand the change.

“Trust me” isn’t a useful approval screen.

Show me the action. Show me the target. Let me check what matters.

Disclosure: I’m a co-founder of 123sudo, the team behind 9xchat. These are design principles I’m exploring, not claims about features currently available in the product.

AI helped structure and draft this article.

What would you need to see before approving an AI agent’s action?