That is better than silent execution, but it is not enough.

If the reviewer cannot understand the proposed action, the approval is ceremonial. If the agent cannot pause and resume reliably, approval breaks the workflow. If the system does not record what was authorized, the team cannot reconstruct the decision later.

Human approval is therefore not just a user-interface feature. It is infrastructure for agent operations.

Start by classifying actions

Not every tool call needs the same treatment. A useful starting point is to classify actions by impact and reversibility.

Read-only actions retrieve information without changing an external system. These can often run automatically when access is appropriately scoped.

Reversible writes change state but have a practical undo path, such as creating a draft or adding an internal label.

Irreversible or high-impact actions send messages, publish content, delete data, move money, make purchases, or change permissions. These usually need explicit approval.

The policy should be attached to the capability, not improvised by the model on every run.

Show the reviewer a decision packet

The reviewer should see the smallest complete set of information needed to make the decision:

1. What the agent wants to do.
2. Why the action supports the current goal.
3. Which account, person, or resource is affected.
4. The exact content or important parameters.
5. The expected effect.
6. Whether the action can be undone.

For an outbound email, that packet might contain the recipient, subject, final body, attachments, and the task that requested it. “Agent wants to use email.send” is not sufficient.

Approval must freeze the action

The payload reviewed by the person should be the payload that executes.

If an agent can edit the message, recipient, amount, or tool arguments after approval, the system has approved an idea rather than an action. Store a version or hash of the proposed payload and execute that exact version.

When circumstances change, invalidate the old approval and request a new one.

Pausing and resuming are part of reliability

Approval introduces a waiting state. The run may remain paused for minutes or days, a server may restart, or another team member may respond.

The workflow needs durable state so it can resume from the approved step without replaying earlier side effects. Each step should have an idempotency strategy, especially for messages, payments, bookings, and external API writes.

Record the decision, not only the click

An audit record should connect:

• the goal and task;
• the proposed action and payload version;
• the agent and tool involved;
• the reviewer;
• the decision and timestamp;
• the execution result.

This is useful for debugging and accountability, but it also improves the product. Teams can learn which actions are routinely approved and which ones repeatedly need correction.

Use exceptions to reduce approval fatigue

Requiring approval for every small action teaches users to click without reading.

Instead, keep low-impact operations within a defined policy and escalate exceptions: a new recipient, an unusually large purchase, a capability that was not previously granted, or an action outside the workspace goal.

The system becomes more autonomous where behavior is predictable and more cautious where the cost of error is high.

In Manor AI, we treat approvals as part of the path from a goal to a verifiable result. Manor AI is a self-hosted AI workspace, and its public edition is source-available under the Sustainable Use License 1.0.

The larger point applies to any agent system: a trustworthy workflow does not remove people from every decision. It gives people a clear, inspectable place to make the decisions that matter.