Human-in-the-loop approval for AI agents: why a click isn't enough

The manager approved one proposal. The system executed another.

An agent reviews a supplier renewal: the contract, usage history, pricing schedule, security assessment and privacy addendum. It proposes a three-year renewal worth $480,000 for a European legal entity, with an EU-only data-residency commitment that has already passed privacy review.

The responsible vice president can approve up to $500,000. She reviews the proposal, its terms, evidence and risk summary, and approves it.

The case then waits for the supplier to countersign. The supplier sends back a revised agreement: the value rises to $620,000 and the residency language changes in a way that needs a new privacy review. The system re-reads the document, updates the contract and recalculates the purchase order.

One value doesn't change: approved = true.

A background worker resumes the case, sees an approved case, generates the final agreement and sends it for signature. The contract takes effect at $620,000, above the approver's limit and with a residency clause she never saw.

Every component can explain itself. The model extracted the new terms. The manager genuinely approved. The workflow resumed correctly. The failure is architectural: the system treated the existence of a human decision as ongoing permission for a proposal that kept changing.

A click is an interaction. An approval is durable state.

Process standards already treat human work as a lifecycle: tasks are created, assigned, claimed, delegated, completed, escalated or made obsolete, with owners and deadlines. That's the foundation. Agent systems need one more step, because a task lifecycle tells you who did the work. It doesn't prove that the decision still applies to the exact proposal and action that happen later.

The goal isn't to make every approval a ceremony. It's to make consequential approvals part of the system's state instead of a passing interface event.

Define approvals before they happen

Approval requirements belong in the workflow definition, not in a notification template or a custom callback. Decide up front:

Approval isn't a boolean

A boolean can't tell approval from conditional approval, expiry, withdrawal, reassignment or invalidation. Durable execution needs typed outcomes. An approval moves from REQUIRED to IN_REVIEW to a decision, and then to PENDING_COMMIT, which ends as COMMITTED, EXPIRED, INVALIDATED or REAPPROVAL_REQUIRED.

Typed states also help operations. A queue backlog, an absent reviewer, an expired approval and a policy denial have different owners and different fixes. They shouldn't all surface as a generic timeout.

The reviewer's authority has to be current

A reviewer can be authorized when a task is assigned and not when it's decided. Roles change, delegations expire, and limits vary by amount, entity and purpose. Separation-of-duty conflicts appear when the same person touched the case earlier.

So check reviewer authority at assignment, at decision and, where policy requires it, again at commit. A task appearing in someone's inbox is not proof they could still approve it.

For high-consequence decisions, require fresh, deliberate authentication at the moment of sign-off. NIST's identity guidance distinguishes holding a session from actively taking part in an authentication event. An approval from an old or unattended session shouldn't carry the same weight as one confirmed with a passkey just now.

What the reviewer saw is part of what they approved

What you show the reviewer is part of the decision, not decoration. A useful review package includes:

• the proposal and its material fields: amount, counterparty, terms, record and intended effect
• the supporting evidence and where it came from
• the model's uncertainty, disagreement or known limits
• the policy obligations and why a person is being asked
• what changed since any earlier version
• the conditions, the deadline and the action approval will allow

An AI-generated summary can help a reviewer navigate a large case. It shouldn't be the only thing they see when omitted detail could change the decision. The exact payload that will be executed must stay inspectable.

When does a change require re-approval?

When it changes the proposal, the risk, the authority, the obligations, the evidence or the effect. Not every technical change counts. A logging update doesn't. A new beneficiary does. Declare the rules in advance instead of deciding after an incident:

More than one approver

Some decisions need finance and legal, two independent approvers, a quorum or a veto. Separation of duties isn't only a role assignment. It's a relationship between actions over time: the person who started a proposal shouldn't become its "independent" second approver because the task was reassigned. Keep the full history of assignment, claim, delegation and decision with the approval.

Approve an action, not a case

An approval should authorize one declared action, not a whole case in the abstract. A payment approval authorizes one payment, to one beneficiary, up to a stated amount. A contract approval authorizes signature of one document version. An access approval authorizes one set of entitlements for one resource and time window.

This matters most during retries and recovery. A technical retry of the same unchanged operation can rely on the same approval. A changed payload, a new operation or a compensating action can't inherit it silently. (See retries and idempotency for AI agents.)

How do you avoid approval fatigue?

Send fewer, better cases: let rules decide which actions need a person, and put the whole case in front of them when one does. Adding a person to the loop doesn't automatically create oversight. Reviewers may get an incomplete summary, lack authority to change the outcome, face too many requests, or approve a proposal whose real effect is hidden. Gartner warns that human approval weakens under time pressure and approval fatigue. Deloitte finds that most organizations lack clear boundaries for which decisions need a person at all.

Meaningful review requires that the person:

• is authorized and accountable for this decision
• sees the proposal, evidence, uncertainty and policy context
• understands exactly which action approval will allow
• can approve, reject, add conditions, request changes or escalate
• isn't bypassed by a timeout, retry, fallback or an agent changing its plan
• isn't asked to make up for missing validation or missing policy

The answer to approval fatigue is fewer, better approvals. Rules decide which actions need a person. Routine actions go straight through, and the cases that matter arrive complete. Agents can prepare the case, compare versions and flag missing evidence. They can't decide that required review is unnecessary.

Common anti-patterns

Ten rules for human-in-the-loop approval

1. Define approvals in the workflow, not in a notification convention.
2. Bind the decision to the exact proposal, material fields and evidence.
3. Check reviewer authority and separation of duties at decision time.
4. Use typed outcomes: approved, conditional, expired, invalidated, re-approval required.
5. Record the versions that shaped what was reviewed.
6. Recheck for material change before resuming or committing after a wait.
7. Bind approval to one action, with a ceiling and an operation identity.
8. Don't let retries, replanning, replay or fallbacks bypass or reuse approval.
9. Keep a record linking every approval to the effect it allowed.
10. Treat human judgment as accountable state, not as a substitute for deterministic controls.

The result: judgment that survives the workflow

Human approval matters because some decisions need accountable judgment that rules can't capture and agents shouldn't own. That value disappears when the system only records that someone clicked. A durable design keeps what the person actually decided, notices when the world changes, asks again when it must, and links the decision to the outcome it produced.

That doesn't make work slower. It lets you use human review selectively and with confidence, because you can say exactly what each approval covers and prove it was honored.