Overview
How might we route consequential agent actions through review so the right person can inspect, approve, or reject before anything runs?
When a peer or role must sign off
- Enterprise agents that publish, deploy, spend, or grant access on behalf of a team.
- Multi-step automations where one human gate is not enough: queues, roles, or SLAs apply.
- Products that need an audit trail of who approved what, when, and with what payload.
- Any workflow where rejecting must feed back to the agent or requester without silent failure.
When a single confirm is enough
- Low-stakes drafts where constant approvals slow teams without reducing real risk.
- Fully reversible local edits better served by undo than a formal approval queue.
- Solo consumer tools with no reviewer role; use a simpler confirm card instead.
States
Design the queue, the review card, and post-decision outcomes together, not only an Approve button.
Queued
An agent or automation submits a request. It enters the approval queue with status visible to reviewers.
Pending review
A reviewer sees the queue count and can open the next item. Nothing consequential runs until a decision.
Under review
The full payload is inspectable: action, target, content or diff, and who requested it.
Approved
Explicit sign-off is recorded. Only after this step may the product execute, publish, or deploy.
Rejected
Deny stops the action. The requester or agent gets a path to revise, not a silent drop.
Complete
The queue is empty or the approved action has finished. Audit history remains available.
Key UX elements
The parts that must be present for approval workflows to feel accountable.
Surface what is waiting and how many.
A count or ordered list so reviewers know backlog size and can triage without opening each item blind.
Show the exact action and scope.
The diff, email, amount, or deploy target, not a summary alone. People approve what they can inspect.
Attribute who asked for the action.
Agent, user, or automation name so accountability and escalation paths are clear.
Make sign-off explicit and primary.
One clear primary control that commits the reviewed action. Never use ambiguous “OK” or “Continue” for consequential work.
Keep deny first-class and low-friction.
Ghost Reject beside Approve. Optional reason field when the agent needs feedback to retry.
Record decisions for later review.
Who approved or rejected, when, and on what payload, kept separate from the live queue.
Anti-patterns to avoid
Approvals that hide the payload (diff, email, amount) being authorized.
Serial approvals that timeout with no escalation or cancel state.
Auto-approve after N seconds without an explicit user preference.
Reject with no feedback path, so the agent cannot learn what to change.
How products use it
| Product | Implementation |
|---|---|
| GitHub / Copilot Workspace | Human review of PRs or agent diffs before merge. |
| Enterprise IT / identity tools | Multi-step approval for access and agent permission grants. |
| ChatGPT / Gemini agents | Send and action gates before email or external side effects. |
| Zapier / workflow builders | Human approval steps mid-automation before continuing. |
Real-world examples
How shipped products implement approval workflows, from our teardown guides.
Implementation
Copy this prompt to generate a production-ready implementation in Cursor, Claude Code, Lovable, or any AI coding agent.
Generate a production-ready implementation of the "Approval Workflows" AI interface design pattern.
Pattern Definition:Frequently asked questions
What are approval workflows for AI agents?
Approval workflows are structured human review gates that must pass before an agent executes a consequential action. They define who reviews, what evidence is shown, and what happens on approve or reject.
How do approval workflows differ from a simple confirm dialog?
A confirm dialog is a one-shot, same-user pause. An approval workflow can involve roles, queues, SLAs, and audit history, useful when a peer, manager, or security owner must sign off.
What must an approval card include?
The exact action, target, content or diff, risk or reversibility, and clear Approve / Reject (optionally Request changes). Never ask users to approve a blank or summarized-only payload for high-impact steps.