Human approval is a product design problem

An approval is a decision, not a pause

It is easy to add a stop before an agent performs a sensitive action. It is harder to make that stop useful. A reviewer who sees a vague request such as continue cannot know which record will change, what information informed the proposal, or whether the action can be reversed. The workflow may contain a human, yet provide very little meaningful human control.

LangGraph's documentation describes durable interruptions and resumption for human input. OWASP's transaction authorization guidance addresses the importance of tying authorization to transaction details. These references cover different layers. Together they suggest an engineering distinction: pausing execution is infrastructure, while helping a person make a valid decision is product design. Both are necessary when approval is a genuine control.

Present the action in the user’s language

Show what will happen, where it will happen, and which information will change. For a hypothetical account update, display the affected account, current value, proposed value, and reason. For a message, show the final recipient and complete text. Expose uncertainty and missing evidence near the decision rather than hiding it inside a long execution transcript.

The review surface should make disagreement easy. Let the person reject, request a correction, or narrow the action where appropriate. An interface that only offers approve or abandon the entire task can encourage acceptance of imperfect work. Preserve useful preparation after rejection so the user does not need to start over. The purpose is to improve the decision, not to collect a click that transfers responsibility.

Bind the decision to a stable proposal

Store the proposed action as a structured object with a version or content fingerprint. Record who approved that version and under which scope. When execution begins, verify that the proposal still matches what was shown. If the agent changes the recipient, amount, destination, or another material field, the earlier approval should not silently authorize the new action.

Check whether relevant external state has changed while the proposal was waiting. A person may approve a record update in the morning, but another process may modify that record before execution. Use an appropriate concurrency check and return the conflict for review when necessary. Expiration also matters: a decision made against old evidence may no longer be valid even if the proposal's text has not changed.

Reserve attention for meaningful decisions

Requiring approval for every harmless step can create fatigue. Classify actions by consequence, reversibility, scope, and uncertainty. A bounded read operation may proceed automatically, while an external communication or broad data change may need a clear checkpoint. Those categories should reflect the actual business workflow and the authority of the person using it.

Batching can help when several actions are similar and independently reviewable. It can also conceal an outlier. Show the range, exceptions, and total impact, and allow selective approval when practical. Track review time and corrections rather than celebrating a high acceptance rate. Fast approval could indicate that the system prepares excellent work, or that reviewers have stopped reading. You need additional evidence to tell the difference.

Test the approval screen with people who did not build it. Ask them to explain what will happen before they click. If their explanation differs from the actual action, revise the presentation or reduce the scope. This simple exercise can reveal missing context, misleading labels, and hidden dependencies that an engineering review of the pause-and-resume mechanism would never uncover.

Design the unattended and failure paths

A pending decision needs an owner and an expiration policy. Decide what happens if the person is unavailable, loses permission, or declines to act. Avoid routing a sensitive proposal to an arbitrary substitute merely to keep work moving. The application should preserve state and communicate the blocker without implying that the action has already happened.

After approval, report the observed outcome. Approved, attempted, and completed are separate states. If execution times out, reconcile the destination before inviting another attempt. Retain enough evidence to explain the decision and its result while minimizing sensitive content in logs. A well-designed approval flow earns its place by helping people catch consequential mistakes and continue work confidently. It should be evaluated as carefully as the AI capability it supervises.