Approvals and human input

An agent may need a missing fact or permission to act. A user-input checkpoint records the question; a tool approval records a protected invocation. Both can outlive the process that created them.

Decide where the gate belongs

For a damaged-order agent, proposing a replacement can be a reversible preparation step. Executing the exact replacement is the consequential action. Bind policy and approval to that execution. Customer prose describing a desired outcome is not a verified approval receipt.

Use AlwaysRequireApprovalToolPolicy for named tools requiring a human decision. Compose application validation through supported guards when necessary. The policy must be registered in the application; prompt instructions alone cannot enforce authorization.

Resolve the owning action

Inspect the pending action’s session, round and call identities. Resolve it through the public approval or input APIs under authenticated authority. A foreground parent may point to a child’s action: follow discovery to the owning child rather than treating the parent reference as a separate approval.

An authorized resolution resumes the recorded invocation under its admitted contract. Unrelated user input should not be used to wake a protected tool call. A stale or mismatched approval must remain rejected.

Notify and verify

Use human attention to hand a durable question to your application notification sink. The sink’s delivery receipt and the actual approval are separate evidence.

Test a pause, a rejected decision, an accepted bounded decision and a repeated delivery. The support-agent recipe provides an installed executable example; durable operations supplies the complete lifecycle contract.