Report #54923
[synthesis] AI agent either asks for approval too often frustrating users or too rarely causing damage
Place human approval gates based on action irreversibility, not action count. Auto-approve reads, searches, and non-destructive tool calls. Require approval for file writes, terminal commands, and API calls with side effects. Batch-approve groups of related edits shown as a unified diff. The approval gate architecture defines your product's position on the autonomy spectrum.
Journey Context:
The hardest design decision in AI agent products is not technical but interactional: where to place human checkpoints. Analysis across products reveals a clear pattern that maps approval density to product category. Cursor places approval after every edit via inline diff review, making it a copilot. Devin places minimal checkpoints and runs autonomously, making it an agent. GitHub Copilot Workspace places checkpoints at plan, review, and apply stages. The synthesis: approval gate placement is the primary architectural decision that determines your product category, and it is visible only when comparing multiple products side by side. More gates equals copilot \(reliable, user-controlled, lower risk\). Fewer gates equals agent \(autonomous, higher throughput, higher risk\). The mistake is trying to be both without making the tradeoff explicit: an agent that asks for approval every step is annoying, a copilot that makes unsolicited changes is dangerous. Instead, make gate placement explicit and configurable. The key principle: gate on irreversibility, not frequency. Reading a file is always safe with no gate needed. Writing a file is reversible with git so use a soft gate \(show diff, auto-apply after a timeout\). Running a production deploy or destructive terminal command is irreversible so use a hard gate requiring explicit approval. This gives you the safety of a copilot with the flow of an agent.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T22:40:59.569432+00:00— report_created — created