Agentic AI Engineering · Module 08 of 16

Human Approval

Human-in-the-loop is an execution control. The agent can propose a change, but the application pauses and asks a person to approve the exact action, target and arguments before anything consequential happens.

Engineering focus: Risk-based human approval, exact action binding and safe resume

In plain English

What problem are we solving?

Human-in-the-loop is an execution control. The agent can propose a change, but the application pauses and asks a person to approve the exact action, target and arguments before anything consequential happens.

Framework names come later. First understand what the application is doing and where its control boundaries belong.

Running case · Operations Investigator

Across the course, imagine an assistant that investigates operational problems using narrow tools. The design progressively adds plans, specialist agents, approvals, reliability controls and MCP while keeping model output separate from execution authority.

Learning objectives

By the end of this module, you should be able to:

  • Classify read, change and high-consequence actions by risk.
  • Bind an approval to the exact proposed action instead of a vague permission.
  • Resume only after approval is current and the request is revalidated.

Approval is not a polite prompt

Writing 'ask the user before deleting' in a system prompt is helpful instruction, but it is not a hard execution boundary. The application must refuse to execute protected actions until an approval record exists.

Risk should determine the gate

Read-only inspection can often proceed automatically. Changes such as restart or scale may require approval depending on environment. Destructive, financial or security-sensitive actions should require stronger controls or may be prohibited entirely.

Approve the exact action

An approval should identify tool, target, arguments, environment, requester and expiry. 'Approved to fix production' is too broad. If arguments change after approval, the old approval should not silently carry over.

Revalidate before execution

State can change while a human is deciding. Re-check authorization, policy and current target state immediately before execution so an old approval cannot be replayed against a changed request.

Worked examples

Approval card

Action: restart_service
Target: prod-web-03 / nginx
Reason: failed health checks
Risk: brief service interruption
Expires: 10 minutes

[APPROVE] [REJECT]
  • The person can see the exact side effect.
  • The approval is narrow enough to audit and expire.

Risk tiers

get_logs        → READ      → usually automatic
restart_service → CHANGE    → approval by policy
delete_database → HIGH      → strong approval or prohibited
  • Risk is based on side effects and business consequence.
  • Environment and identity can raise or lower the required control.
Try it · core lab · account-free

Gate a side-effecting action with exact approval

Goal: Allow a read automatically, pause a restart for approval, reject changed arguments, and refuse an explicitly denied destructive action.

Before you start

  • Python 3 only. All actions are simulated; the lab performs no real service restart or deletion.
STEP 1

Run the approval lab

python3 public/labs/agentic-ai/08_human_approval.py
STEP 2

Inspect the approval fingerprint

The approval is bound to tool, target and arguments rather than a vague task description.

STEP 3

Watch changed arguments fail

After approval, the lab changes the target and proves the old approval cannot authorize the new request.

Verify

  • Read-only activity proceeds without a change approval.
  • The restart executes only with matching, unexpired approval.
  • A modified or rejected request does not execute.

Expected outcome

  • The model can propose an action but cannot grant itself authority.
  • Approval and execution are separate auditable events.

Break / fix · diagnose

  • If changed arguments still execute, verify that the approval fingerprint covers all consequential fields.
  • If rejected actions execute, check the policy gate before the simulated tool handler.
Production view

Human approval is strongest when it is implemented as durable application state with identity, exact parameters, expiry and audit—not as conversational wording alone.

Avoid these traps

Common mistakes

  • Treating 'please ask first' in a prompt as the approval mechanism.
  • Approving a broad goal instead of the exact action and arguments.
  • Reusing an approval after the target or parameters change.
  • Showing a human too little context to understand the consequence.
Knowledge check

Explain the control decision, not just the vocabulary.

Open every answer only after committing to your own answer. Opening all four answers records knowledge-check activity in My Learning.

1What actually prevents a protected tool from running before approval?

Application-enforced execution gating — a prompt can request good behavior, but the runtime must refuse the action without valid approval.

2What should happen if tool arguments change after approval?

Require a new approval — the original approval was for a different action.

3Why revalidate immediately before execution?

Authorization, policy or target state may have changed while approval was pending.

4Should every read-only tool always require human approval?

Not necessarily — approval should be risk-based; low-risk reads can often run automatically under normal authorization and policy.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.