Many agentic-system diagrams contain a box labelled “human approval.” That box can create confidence without creating control.

If the reviewer sees only a generated summary, if the proposed action can change after approval, or if the interface makes rejection harder than acceptance, the human is present but not meaningfully in the loop.

Approval should be treated as an engineering contract.

Decide what requires approval

Review effort is limited. Put approval where consequences justify it:

  • irreversible or difficult-to-reverse actions;
  • changes to production systems;
  • financial, legal, personnel, safety, or access decisions;
  • disclosure of sensitive information;
  • low-confidence or conflicting evidence;
  • requests outside the proven operating envelope;
  • policy-required accountability.

Low-impact, reversible steps may use automated policy checks. High-impact steps may require more than one role or an independently authenticated action.

Do not require approval for every harmless intermediate output. Review fatigue turns a control into a habit.

Show the exact proposed effect

A reviewer should see:

  • the target system and object;
  • current relevant state;
  • exact fields, files, messages, or commands that will change;
  • before-and-after difference;
  • expected downstream effects;
  • evidence and source references;
  • uncertainty, conflicts, and failed checks;
  • whether the action can be reversed.

“Approve agent response” is too vague. “Change ticket LF-184 from In Review to Approved and notify the named project channel with this exact message” is reviewable.

For generated communication, show the final recipient list and content. For a data change, show the exact record diff. For a deployment, show version, environment, checks, and rollback path.

Separate recommendation from decision

The agent can recommend an action and explain why. The reviewer remains responsible for the decision.

Avoid interface language that implies the system has already decided. Present alternatives where they exist:

  • approve;
  • edit and resubmit;
  • reject with reason;
  • request more evidence;
  • delegate to an authorised role.

Record the reviewer’s choice and reason. The feedback becomes useful evaluation data and creates an accountable workflow trace.

Freeze the proposal

At review time, create an immutable proposal object containing:

  • action type;
  • normalised parameters;
  • target identity;
  • relevant source and state versions;
  • workflow and policy version;
  • expiry;
  • evidence references.

The approval should bind to that object. A simple approach is to approve a stable identifier and cryptographic digest generated from its canonical representation.

The execution service accepts only the approved proposal. It does not ask the model to recreate the action after approval.

This prevents subtle changes in wording, recipients, values, or targets between review and execution.

Revalidate current state

Even a frozen proposal can become unsafe if the world changes.

Before execution, recheck:

  • target still exists;
  • expected current state still matches;
  • reviewer remains authorised;
  • approval has not expired or been revoked;
  • policy version still permits the action;
  • dependent conditions remain true;
  • the operation has not already completed.

If a material condition changed, return the proposal for review. Do not silently adapt it.

Use optimistic concurrency, expected-version fields, or idempotency keys where connected systems support them.

Make rejection safe and useful

Review interfaces should not punish rejection with lost work or vague error states.

Capture structured reasons such as:

  • insufficient evidence;
  • wrong target;
  • incorrect proposed change;
  • policy conflict;
  • unsafe timing;
  • duplicate action;
  • requires another role;
  • request itself is invalid.

The workflow can then route appropriately. It should not repeatedly generate a cosmetically different proposal without addressing the reason.

Prevent rubber-stamp approval

Useful interface choices include:

  • place risk and changed fields near the action;
  • make source evidence easy to inspect;
  • avoid preselecting approval;
  • require an explicit action;
  • add stronger confirmation for high-impact operations;
  • rate-limit review queues;
  • show repeated or unusual proposals;
  • measure approval time and correction patterns for fatigue signals.

The goal is not friction for its own sake. It is sufficient attention for the consequence.

Design delegated and multi-role approval

Enterprise workflows may require:

  • technical review;
  • data-owner approval;
  • security approval;
  • business-owner decision;
  • separation of duties.

Model these roles explicitly. The agent should not choose a convenient reviewer based solely on name matching. Resolve identity and authority through the organisation’s access model.

An approval from the wrong role is not valid merely because a person clicked the button.

Verify the executed result

After execution, read back the final state and compare it with the approved proposal.

Record:

  • execution identifier;
  • tool and credential identity;
  • resulting state;
  • difference from the proposal;
  • errors, retries, or partial completion;
  • rollback result if used.

If an API times out after applying a change, verify before retrying. Approval does not make duplicate execution safe.

Evaluate the approval system

Measure more than approval rate:

  • percentage edited or rejected;
  • reasons for rejection;
  • review time by consequence;
  • actions returned because state changed;
  • execution mismatches;
  • duplicate-action prevention;
  • reviewer-reported clarity;
  • incidents or near misses;
  • automation value after review effort.

A workflow that saves generation time but creates a large opaque review queue may not reduce total effort.

Keep people in control of consequence

Human oversight is strongest when the system makes the decision surface clear. The reviewer should not need to reconstruct intent from raw model traces or trust that a general “approve” button covers the real operation.

A meaningful gate binds an authorised person to one exact, evidenced, current, and executable proposal. If any of those properties changes, approval changes with it.

Source notes for review