Design an AI agent approval workflow people can actually review

Start where the governance policy becomes work

A broad governance policy establishes accountability and boundaries. An approval workflow turns those boundaries into a practical queue: who reviews which action, what they see, how long the decision applies and what happens when conditions change. This article focuses on that operating layer. It complements our guide to agent governance rather than replacing the wider policy discussion.

Consider an illustrative sales workflow. An agent prepares a proposed follow-up for an account owner, drawing on an approved offer and recent CRM context. The owner may approve the exact message, request changes or decline it. Preparation, approval and sending remain distinct states. The design must prevent a draft or a completed review from being reported as a message already delivered.

Use a worked proposal instead of a general permission

Here is a fictional review packet a team can adapt. Proposal: follow up on account A-104, version 3. Action: send the displayed message to the named account contact. Evidence: the contact's request and approved offer record, with their timestamps. Fixed parameters: recipient, exact body, attachment and offer terms. Reviewer: account owner. Expiry: the earlier of the offer deadline or the team's specified review window.

The reviewer compares the proposed message with the evidence and selects approve, return for revision or reject. Approval applies only to version 3. A changed attachment creates another proposal version. The packet also identifies the owner who will investigate an uncertain delivery result. These fields form a reusable specification for discussion with engineering; their presence in a document does not establish that a system enforces them.

Build a review packet with enough context

A reviewer should see the proposed change and its basis in one place. For a customer message, include the intended recipient, exact content, relevant source facts and any proposed attachment. For a record edit, show the current and proposed values. Highlight unresolved conflicts and explain why the action was escalated. Avoid burying the deciding information in a long agent transcript.

The packet should be concise enough for the actual workload, with access to supporting detail when needed. Test it with the people who will review the queue. Ask them to explain what they believe they are authorizing before they click. If their answers differ from the action specification, improve the packet and labels before expanding use.

• What exact action will happen, and in which destination?
• Which customer, record or offer will be affected?
• What evidence supports the proposal, and how current is it?
• Which parameters are fixed by this approval?
• What uncertainty or exception remains for the reviewer?
• What happens if the reviewer declines or does not respond?

Bind the decision to the action that was reviewed

Approval should identify the specific proposal version and the conditions under which it remains valid. If the recipient, offer, content or relevant source record changes, determine whether a new review is required. Set an expiry appropriate to the workflow. A price exception approved yesterday may no longer apply after a promotion ends or inventory conditions change.

Define how the execution system checks those conditions before acting. Do not let an agent reinterpret “approved” as permission for adjacent tasks. If a connection fails after the destination accepted an action, a blind retry can create a duplicate. Ask the technical owner how completion is confirmed and repeated requests are handled. An uncertain result should become an exception to investigate, not an automatic claim of success.

Define the queue states and the next permitted action

Use this proposed state model as a working specification. Assign a named person to each ownership role and agree which events cause a transition. The names are less important than ensuring that every item has an accountable owner and a permitted next step.

Monitor time in each state, returned proposals and repeated ambiguity. Define backup reviewers and an escalation route for stalled items. Sampling completed records helps reveal whether the workflow preserves the state model in practice. A high approval rate alone cannot show that reviewers understood what they authorized.

• Pending — reviewer owns the decision; inspect, return or reject the proposal. Execution is not permitted.
• Approved — execution owner checks version, expiry and conditions; perform only the approved action while those checks hold.
• Rejected — proposal owner records the reason; stop this version. A materially revised proposal enters a new review.
• Expired — proposal owner refreshes the evidence; request a new decision. The previous approval cannot authorize execution.
• Ambiguous result — operations owner inspects the destination; reconcile before retrying to avoid a duplicate.
• Verified complete — operations owner records destination evidence; close the item without treating completion as a commercial outcome.

Test the exception paths before expanding

Use a bounded test environment and a written expectation for each scenario. Include a valid approval, a rejection, an expired decision, changed evidence, an unavailable destination and an ambiguous completion response. Verify the receiving system as well as the review interface. A log entry that says “done” is insufficient if the intended record or message does not exist where it should.

Anthropic's agent-building guidance discusses human checkpoints and stopping conditions as part of agent design. Its evaluation guide explains the value of testing behavior across trials. These are useful technical references; the concrete queue design here is our proposed operating practice. Agent-building guidance, evaluation guidance.

Keep a usable record, then revisit the boundary

Retain enough information to reconstruct the proposal, reviewer decision and observed destination result. Define access and retention according to the data involved; a review record should not become an unnecessary copy of sensitive customer information. Preserve identifiers and relevant versions so that a disputed action can be investigated. Stopping future execution does not automatically reverse an action already completed elsewhere.

Start with one workflow and review what the evidence shows before increasing scope. NIST's voluntary AI Risk Management Framework offers broader risk-management context, but following this article is not certification. NIST AI RMF. When evaluating AIOS with Nextriad, bring a real action, an approval rule and one failure scenario. Request a demonstration of what is enforced, what the reviewer sees and how the final result is verified in the proposed environment.

Sources and review date

• Anthropic — Building effective agents · 2024-12-19
• Anthropic — Demystifying evals for AI agents · 2026-01-09
• NIST — AI Risk Management Framework · 2023-01-26

Sources reviewed: 2026-09-15.