Report #93053
[synthesis] Add human approval as a post-hoc UI confirmation dialog after the agent has already committed to its action plan
Design human approval as an architectural checkpoint in the agent loop state machine: the agent pauses at defined states \(before file writes, before command execution, after planning\), presents the proposed action with full context for informed review, and cannot proceed until explicitly approved. Build approval into the state machine, not the UI layer.
Journey Context:
Many AI coding tools add approval as a UI-level confirmation \('Accept changes?'\) after the agent has already committed to an action. This is architecturally wrong because: \(1\) the agent has already consumed tokens and compute on an action that might be rejected, \(2\) the approval context is often insufficient—showing a generic dialog without the diff or affected files, and \(3\) the agent can't adapt its plan based on rejection, it just stops. The pattern from Cursor \(diff preview before apply\), Devin \(approval checkpoints before terminal commands\), and Windsurf \(cascade approval flow\) is that approval is a first-class state in the agent loop. The agent proposes, presents full context, waits, and can either proceed or replan based on the human's response. This means the agent loop state machine has explicit 'awaiting approval' states, and planning logic branches on approval/rejection. The tradeoff is slower execution for trusted operations, which products solve with configurable trust levels: auto-approve reads and searches, require approval for writes and executes, auto-approve writes in test files but not production code.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T14:46:35.912407+00:00— report_created — created