Human confirmation is one of the easiest safety controls to add to an agent, and one of the easiest to misuse. If every write produces a modal asking for approval, users stop reading. If no write requires approval, the system may create unwanted side effects. The solution is risk-based confirmation.
The most important distinction is that confirmation establishes intent. It does not grant authority. A user can say “yes” to an action that is still unauthorized or invalid.
1agent proposes action2 ↓3prepare action + deterministic validation4 ↓5persist pending_action_id6 ↓7user confirms intent8 ↓9revalidate current state + authorization10 ↓11execute idempotentlyRisk-tier the action
Useful dimensions include reversibility, financial impact, external visibility, blast radius, privilege level, sensitivity, and recoverability. A reversible internal note may execute automatically after policy checks. A CRM stage change may require conditional confirmation. A financial transfer or external mass communication may always require explicit approval.
1LOW RISK2reversible + internal + small blast radius3→ deterministic checks → execute4 5MEDIUM RISK6visible or material but recoverable7→ conditional confirmation8 9HIGH RISK10financial / irreversible / privileged / broad audience11→ explicit confirmation or human approvalReduce friction without weakening controls
Confirmation fatigue should be solved by moving mature decisions into explicit deterministic policy, not by letting the model auto-approve itself. You can batch related low-risk actions, give users narrow pre-authorization, or require confirmation only above thresholds. Historical data and evals can help tune those thresholds.
PFPLabs takeaways
- User confirmation establishes intent; it does not grant authority.
- Risk should drive confirmation policy.
- Automate policy, not approval theater.
- Revalidate before execution. State may change between proposal and confirmation.