Human Approval Gates
Explicit per-action automation levels so humans can supply plans, validate them, or approve irreversible tool calls before the agent proceeds.
Humans need not be fully absent from an LLM agent. They can provide a high-level plan the agent expands (hierarchical planning), validate a generated plan, or execute risky steps themselves. The harness must define the automation level allowed per action — for example, require explicit approval before a database update, code merge, or bank transfer.
This is the agent-specific form of blast-radius control for write actions: unreliable models should not hold production delete keys by default. Pair gates with logging of function calling parameters so reviewers see what would run before they approve — the same detail a tool-call transparency UI surfaces to end users. In product UIs, expose the same control as authorization prompts plus inspectable/editable tool calls under agent UX steering affordances.
Enforce the gate at the application layer, not the prompt layer: any tool call with even a remote chance of being dangerous (modifying real-world assets) must require explicit user authorization before execution via harness-level interception, not by instructing the model to ask first — application interception, not prompt-level pleading. Prompted requests for permission can be skipped by the model under the same failure modes as any other instruction; an approval step the harness enforces before dispatch cannot be. Once given, an approval is state that must survive crashes and restarts (durable approval state).
Per-action gates sit inside two broader decisions for agents that act on live systems. One is the default posture when nothing has been approved, which should be read-only (diagnose by default, act by exception). The other is which situations the agent may handle alone at all: only those matching a prepared runbook, with anything outside that envelope escalated as a planned step (autonomy bounded by the prepared envelope). Below the gates, some actions should be unavailable whatever is approved (hardline command floor).
Human involvement need not be limited to pre-execution approval. Queue human reviewers for workflow tasks whose output needs human-level judgment the harness cannot yet automate. And when a Reflexion-based task keeps failing on the same narrow subset of work items despite retries, that is itself a signal worth routing to a human: have someone inspect the recurring failure case and adjust the prompt, rather than letting the task keep burning retries against a problem retries can't fix.
Sources
- AI Engineering (Chip Huyen), ch. 6
- Prompt Engineering for LLMs (Berryman), ch. 8