Designing human approval steps people actually use

Gate on consequence, not on confidence

Model confidence is a poor trigger for human review because it is not calibrated against your business risk. We place gates by consequence: anything that moves money, changes a legal position, contacts a third party, deletes data or affects safety requires an explicit approval regardless of how confident the model is.

Everything else runs through, with sampled review after the fact.

Make the review cheap

A reviewer should be able to act in seconds. That means the interface shows the proposed action, the evidence with citations, what changed since the last version and a one-click accept, edit or reject, not a raw model transcript to read.

• Show the diff, not the whole document
• Link every claim to its source span
• Record who approved what, when, and any edit they made
• Let rejections carry a reason code that feeds evaluation

Rejections are the product

Every rejection is a labelled example of your organisation's standards. Captured properly, the approval queue becomes the training and evaluation pipeline for the next version of the system. That is why we treat reason codes as a first-class feature rather than a free-text afterthought.

Audit trails are a design constraint

In regulated settings the question is not whether the agent was right but whether you can show how the decision was reached. Immutable, queryable logs of agent actions, tool calls, approvals and edits should be designed in from the first sprint, because retrofitting them is significantly harder.