Human approval for AI agents: approve the action, not the conversation

An assistant asks, “Should I proceed?” A manager clicks yes. A few seconds later, the assistant updates a record, sends a message and closes a case. The manager thought the approval covered only the draft.

This is an approval-design failure. The question did not identify a concrete action, and the system treated a conversational response as a broad grant of authority.

A useful AI approval authorizes a specific operation against specific current records. It shows the effect, binds the approval to the reviewed payload and records whether execution succeeded. If the action changes, the system must check whether the existing approval still applies.

Decide which actions need a person

Do not ask for approval before every harmless lookup. That creates interruption without meaningful control and trains reviewers to approve automatically.

Classify operations by their consequences, reversibility and existing business policy. Reading an authorized status can usually proceed within the request. Preparing a draft is different from sending it externally. Correcting a local report is different from changing the source ledger.

Some operations can follow established delegated authority. Others require a fresh decision. The approval design should represent those distinctions rather than treating all tool calls as equally risky.

Use existing business authority

If a supervisor can approve a particular customer concession in the ordinary application, the AI workflow should not invent a parallel role with broader authority. Reuse the business rule and record which authorized person approved the action.

The model can propose an action. It should not decide that the requester has approval rights because their message sounds senior or urgent.

Show the reviewer the exact consequence

An approval request should identify the target, operation, material parameters and expected effect. Include the evidence the reviewer needs to make the decision without reopening the entire investigation.

For an outgoing message, show the recipient and final text. For an entitlement change, show the current value and proposed value. For a deployment, show the artifact or commit being released and the verification status.

Do not bury unresolved uncertainty under a green approval button. If a source record is missing or a validation failed, that fact belongs beside the proposed action.

The examples are design patterns, not authorization for any particular company to automate these operations.

Bind approval to a versioned payload

Store the approved action in a durable record. Include the reviewer, timestamp, operation identifier, relevant source version and the payload that was reviewed.

Execution should use that approved payload. If the agent regenerates a message after approval, the new text is not the approved text. If it changes a target record, the new target is not covered by a general “proceed.”

A content hash or version identifier can help detect changes, but it is not the whole authorization system. The application still needs to check identity, current permissions and whether the operation remains valid.

Separate cosmetic changes from material changes carefully

A system may permit some non-material formatting changes under a defined policy. That policy should be explicit and narrow. Changing a date, recipient, price or commitment is material even if the wording change is small.

When the distinction is difficult to implement reliably, require review of the final payload. The cost of a brief reapproval can be lower than the cost of reconstructing what a person believed they approved.

Recheck the world before execution

A valid approval can become stale. The customer may have cancelled the request, another employee may have already completed the action or the source record may have changed.

At execution time, compare the relevant preconditions with current state. If they no longer hold, stop and prepare a new proposal. Do not force an old decision onto a changed business situation.

This is especially important for queued work. An approval given during an incident should not automatically authorize the same action after the incident has ended.

Give approvals an expiry and a cancellation path

Define how long an approval remains usable. The appropriate period depends on the action and business process; there is no universal timeout that makes every workflow safe.

Provide a way to withdraw approval before execution. The execution service must check cancellation, not merely the presence of a historical approval record.

If the reviewer leaves the organization or loses the relevant role, decide how pending approvals are handled. For sensitive operations, rechecking current authority avoids relying on a permission that no longer exists.

Cancellation should not erase history

Keep the proposed action and the reason it was cancelled. That record helps explain why the workflow stopped and prevents another worker from interpreting the absence of a result as a reason to repeat the request.

A cancelled operation and an operation that never existed are different states. Treat them differently during recovery.

Approval does not prove execution

After the action is approved, the downstream system can still reject it, time out or complete it without returning a response. The user interface must not label the operation complete merely because a person clicked approve.

Record the confirmed downstream result. If the outcome is unknown, mark it as unknown and reconcile it before retrying a non-idempotent operation.

The final message should distinguish “approved,” “submitted” and “completed.” This matters in customer communication, access management and financial workflows, where premature confirmation creates another operational problem.

Avoid repeated actions after a restart

Use a stable operation identifier for the approved action. The execution worker should be able to determine whether that identifier has already produced a result.

If the target API supports an idempotency key, use it according to the target's contract. If it does not, design a reconciliation step or a manual exception path. Do not assume a timeout means nothing happened.

AWS's discussion of idempotent APIs explains why a retry can create additional side effects when the original outcome is uncertain. The application-level approval design needs to account for that uncertainty.

Make independent checks genuinely independent

A second model can help review a proposal, but it should not be treated as independent authority merely because it is a second call. It may share the same incomplete evidence or repeat the first model's unsupported assumption.

Use deterministic checks for facts the application can establish: current balance, permitted recipient, required fields, allowed action type and record version. Use a qualified reviewer for judgement the policy assigns to a person.

The model may explain a recommendation. The application should verify the conditions it can verify without relying on that explanation.

Design the review queue for real people

Reviewers need priority, context and a manageable workload. A queue containing hundreds of indistinguishable approvals will not receive careful attention simply because each item has a confirmation button.

Group related evidence, but avoid approving unrelated actions in one vague batch. Allow a reviewer to accept some proposals, reject others and request a specific correction.

Measure review time and rejection reasons. If most approvals are returned because the same field is missing, improve the proposal generator. If reviewers routinely lack authority, fix routing before adding more automation.

Escalate by responsibility, not only elapsed time

An unanswered request can mean the assigned reviewer is absent or the proposal belongs to another team. Escalation should preserve the authority rules.

Do not send a sensitive operation to the first person who responds. Identify a permitted substitute or let the job remain safely blocked.

A hypothetical customer-service workflow

A support assistant investigates a delayed order and drafts a customer message. It retrieves permitted order facts and identifies that the dispatch date is unconfirmed.

The proposed message states the confirmed facts and offers a follow-up, without inventing a delivery commitment. The supervisor sees the recipient, exact message and evidence references.

Before sending, the application checks that the case is still open and the recipient is unchanged. Another employee has just added a confirmed dispatch date, so the workflow stops for a revised draft rather than sending stale information.

The revised message receives a new approval. The sending service records the downstream message identifier, and the case history shows who approved which version. The agent can then report the completed action accurately.

Test the approval boundary before launch

Change a payload after approval and verify that execution is refused. Cancel a pending operation and verify that a delayed worker cannot revive it. Revoke the reviewer's role and check the configured policy.

Also test the user explanation. A refusal should tell the operator what needs reviewing without implying that the business action has already happened.

Document the recovery path for an unknown result. This is often the least visible part of the demonstration and the most important part of the eventual support runbook.

Make an approval understandable in a busy workflow

An approval request should help someone make a decision without reconstructing the entire conversation. Present the proposed action, its recipient or target record, the fields that will change and the evidence behind the recommendation. Where values are being updated, show the current value alongside the proposed value.

Do not rely on a vague button such as “continue” for an action with business consequences. The interface should make clear whether the reviewer is approving a draft, authorizing a database update or sending something outside the company. That distinction belongs in the action contract as well as the interface wording.

Consider an assistant preparing a supplier email. The reviewer approves the message and recipient, then a later model step rewrites the message. That new version has not been approved. Bind approval to an immutable representation of the action, or invalidate it whenever a meaningful field changes. The same principle applies to amounts, attachment lists and destination accounts.

Account for absence and disagreement

Approvals become a bottleneck when they depend on one person being available. Define an alternate reviewer with the appropriate authority, and make reassignment visible. Do not grant that authority to anyone who happens to receive a notification.

A rejection needs a supported outcome. The reviewer may request a correction, reject the business request entirely or ask for more evidence. Record those outcomes separately so the system does not automatically resubmit the same action until somebody accepts it. A repeated request with unchanged evidence should be easy to identify.

Conflicting approvals also need a rule. If two reviewers act at nearly the same time, the application must determine which decision is effective. Use a controlled state transition and preserve the history. A stream of chat messages is a poor substitute for an authoritative action state.

Rehearse the queue before enabling writes

Run a small operational exercise using deliberately incomplete requests. Include an approval that expires, a target record that changes during review and a user whose permission is revoked before execution. The expected behavior should be specified before the exercise, so a convenient result is not mistaken for a correct one.

Ask reviewers to work through the actual screen with representative volumes. Measure whether they can identify the consequence and supporting evidence. If every request looks urgent and contains several pages of generated explanation, the design encourages superficial review even if every action technically has a human approval.

The operating owner should also inspect the queue at the end of the exercise. Pending, rejected, expired and executed actions should be distinguishable without reading raw logs. Unresolved actions need an owner and an age, not just a status color.

When scoping an agent workflow, bring examples of decisions that already require managerial approval and the policy behind them. Those examples establish useful boundaries for automation. The aim is a review step that preserves accountable judgment while removing repetitive preparation work around it.

Questions about human-in-the-loop systems

Make the approval record useful after the event

An incident review should be able to answer what was proposed, what evidence supported it, who approved it and what actually happened. Design that record before building the button.