Where should human approval be required in agent-enabled delivery?

“Human in the loop” is often presented as a complete control. It is not. A person may click approve without understanding the action, face so many prompts that attention collapses, or be asked to accept a decision outside their authority.

Useful human approval is deliberately placed. It interrupts an agent when judgement, accountability or permission must change, while allowing bounded and observable work to proceed without ceremonial confirmation.

Identify consequential transitions

Begin by mapping the agent's workflow from task assignment to operation. Mark transitions where the potential effect changes materially. Common examples include accessing sensitive data, connecting a new tool, broadening repository scope, introducing a dependency, changing a security or architecture boundary, merging protected code, deploying to a customer environment, performing a destructive action or accepting unresolved risk.

Consequence depends on context. A reversible change in a temporary environment may be pre-approved, while the same command against production data requires explicit authorisation. Novelty, uncertainty, blast radius and the strength of detection and recovery all influence the decision.

Do not rely only on a fixed list of commands. The meaning of an action matters. A routine configuration edit could change public access or remove a recovery control even if the command itself looks ordinary.

Design an approval that supports a decision

An approval request should state the goal, proposed action, affected systems and data, expected effect, checks completed, unresolved risks and recovery route. Show the actual change or a trustworthy summary with links to evidence. The approver must be able to reject, request revision or narrow the authority.

Use evidence that is sufficiently independent of the generation process. Tests created by the same agent are useful, but they may repeat its assumptions. Add existing regression checks, static analysis, peer inspection, environment policy or targeted testing according to the risk.

Prevent approval fatigue by grouping related low-risk steps and escalating only exceptions or material transitions. Set expiry and scope so one approval cannot silently authorise future work. A well-designed control makes the important choice visible without turning every tool call into a judgement exercise.

Match the approver to the accountability

Different decisions require different authority. Product approves changes to intended outcome, customer impact or priority. Engineering accepts implementation quality, technical risk and operability. Architects own material boundary and design trade-offs. Security, privacy, data or operational specialists participate where their domain is affected. Local role names may vary, but the decision must reach someone able and authorised to understand it.

Approval does not transfer all responsibility to the final reviewer. The person assigning the task, the engineers shaping the environment and the organisation enabling the agent retain their accountabilities. Record who approved what evidence and which version or action was authorised.

For high-consequence work, separation of duties can prevent the agent or person who created the change from being its sole acceptor. The aim is independent judgement, not an arbitrary number of signatures.

Earn automation through evidence

Teams can remove a manual checkpoint when the step is bounded, repeatable, observable and recoverable, and when automated controls have demonstrated reliable detection. Define the conditions for automatic progression and the events that restore human review, such as an unexpected diff, failed control, new dependency, scope change or anomaly.

Measure intervention frequency, rejection reasons, escaped defects, reversals, approval time and the effort needed to understand the evidence. High approval rates do not necessarily prove safety; they may indicate rubber-stamping. Frequent rejection may expose a weak agent workflow, poor context or an approval placed too late.

Revisit checkpoints as system criticality, agent capability and engineering controls change. The objective is not maximum autonomy or maximum human involvement. It is a delivery path in which consequential choices remain deliberate, accountable and recoverable.

Example

An agent updates infrastructure code in a sandbox, runs policy checks and prepares a plan without individual approval. The plan proposes changing public network access, which matches a defined escalation trigger. The agent stops and presents the affected resources, policy results, rationale and rollback steps.

A platform engineer reviews the technical effect and a security owner approves the boundary change. Their approval applies only to that version of the plan and expires after the deployment window. If the plan changes, the agent must request approval again. A routine sandbox update that stays within policy can continue automatically.

FAQs

• Should a human approve every action an AI agent takes?

  Usually not. Constant prompts dilute attention and obstruct useful automation. Require approval at material changes in scope, authority, consequence or reversibility, with automated guardrails for bounded steps.

• Is clicking approve enough to make an action safe?

  No. The approver needs appropriate authority, understandable context, credible evidence and a real ability to reject or revise the action. Approval cannot compensate for missing controls.

• Can a team remove a human approval point later?

  Yes, when representative evidence shows the step is reliably bounded, detected and recoverable. Define exception triggers and continue monitoring rather than treating automation as permanent.