Human approval workflows for AI agents

Define what the person is approving

A useful approval interface identifies the target records, before/after values, material side effects and supporting evidence. It lets an authorized reviewer reject or revise the proposal without being pressured into a one-click continuation. The required detail depends on the consequence of the action.

OWASP’s transaction-authorization guidance emphasizes significant transaction data and preventing a change after authorization. Applying that principle to agents means the approved object is the actual proposal, not an open-ended instruction to finish the task.[1]

Use a state machine that cannot skip review

proposed → awaiting_review → approved → executing → committed
                         ↘ rejected
                         ↘ expired
                         ↘ superseded
executing → outcome_unknown → reconciled

An approved proposal is not necessarily committed. Execution can still fail, be denied under current policy or end with an unknown outcome. The interface should reflect that distinction. A “thank you, approved” message should not imply that the account has already changed.

Define who can transition each state. The model can propose a change, but should not write its own approval decision. A background worker should consume a trusted approval record and validate it rather than accepting an approved=true field in model output.

Worked scenario: the record changes during review

A synthetic agent proposes changing an account setting from A to B based on account version 12. The reviewer sees the diff and approves proposal version 3. Before execution, another authorized user changes the account to version 13.

The commit checks the expected resource version and stops. The old approval does not silently authorize overwriting the new state. The system fetches the current record, creates a revised proposal if appropriate and obtains a new decision. The original approval remains part of the history, with no misleading claim that it was executed.

Approval cannot grant nonexistent privileges

The reviewer must be authorized for the action being approved. A user who can view an account may not be allowed to change its billing policy. Authentication proves an identity under the application’s mechanism; authorization determines whether that identity may perform this operation.[2]

The approval service and domain executor need a shared contract for scope and timing. Decide which policy is checked at review and which conditions must still hold at execution. If the organization deliberately delegates an approved action to a service identity, document that policy rather than accidentally retaining a departed user’s authority.

Design review effort into the workflow

Approval can become ineffective when the system produces too many low-value prompts or hides the relevant evidence. Group actions only when the reviewer can understand the whole batch and policy permits it. A batch decision should identify the exact included operations, not an expanding future set.

• Show the material before/after difference before the primary approval control.
• Identify missing or contradictory evidence rather than presenting a confidence score as proof.
• Explain consequential downstream effects and whether they can be reversed or compensated.
• Make reject and revise practical choices with clear resulting states.
• Measure review time, disagreement and edits so the workflow can improve.

Do not assume that every action needs the same approval pattern. Policy can allow low-consequence actions within a defined scope and require explicit review for others. The system should express that decision consistently; removing necessary review just to reduce latency is not an improvement.

Test the approval contract end to end

Test a valid approval, a rejected proposal, a changed payload, an expired decision, a revoked approver and a lost response after commit. Verify that the same approval cannot be reused to create a second operation and that an operator can identify the actual outcome.

The artifact a buyer should request is a working demonstration of these transitions, supported by the record schema and domain checks. The important signal is not the presence of an approval modal. It is that the system can explain exactly what was authorized and whether that action occurred.