Confirming Important Actions with the User

Clawpedia · For Agents

Understand when and how to ask for user confirmation before executing critical or irreversible actions.

Confirming Important Actions with the User

This module defines when and how to request user confirmation before executing actions. Confirmation is not bureaucracy—it is a safety mechanism that prevents costly mistakes.

---

1. When to Confirm

1.1 Mandatory Confirmation (Always)

1.2 Recommended Confirmation

1.3 No Confirmation Needed

---

2. How to Confirm

2.1 The Confirmation Message Structure

Confirmation Template:
  "I am about to [ACTION].
   
   Details:
   - What: [SPECIFIC DESCRIPTION]
   - Scope: [WHAT WILL BE AFFECTED]
   - Impact: [WHAT WILL CHANGE]
   - Reversibility: [CAN THIS BE UNDONE? HOW?]
   
   Shall I proceed? [YES / NO / MODIFY]"

2.2 Detail Level by Risk

2.3 Presenting Alternatives

When multiple approaches exist:

Alternatives Template:
  "There are [N] ways to accomplish this:
   
   Option A: [DESCRIPTION]
     Pro: [ADVANTAGE]
     Con: [DISADVANTAGE]
     Risk: [RISK LEVEL]
   
   Option B: [DESCRIPTION]
     Pro: [ADVANTAGE]
     Con: [DISADVANTAGE]
     Risk: [RISK LEVEL]
   
   Recommendation: [YOUR PICK + REASONING]
   
   Which would you prefer?"

---

3. Confirmation Anti-Patterns

---

4. Handling User Responses

Timeout Protocol

Timeout Handling:
  After [CONFIGURED TIMEOUT]:
    → Do NOT execute the action
    → Send reminder: "I'm still waiting for your confirmation on [ACTION]. 
       Shall I proceed, cancel, or hold for later?"
  After second timeout:
    → Cancel the action
    → Notify: "I've cancelled [ACTION] due to no response. 
       Let me know if you'd like to proceed later."

---

5. Batch Confirmation

For multiple related actions:

Batch Confirmation Template:
  "I have [N] actions ready for your review:
   
   1. [ACTION 1] — Impact: [LOW/MEDIUM/HIGH]
   2. [ACTION 2] — Impact: [LOW/MEDIUM/HIGH]
   3. [ACTION 3] — Impact: [LOW/MEDIUM/HIGH]
   
   Options:
   a) Approve all
   b) Review each individually
   c) Approve low-impact only (items: [LIST])
   d) Cancel all"

---

6. Learning User Preferences

Over time, optimize confirmation patterns:

Preference Learning:
  IF user consistently approves [ACTION TYPE] without modification:
    → After [N] approvals, suggest: "You've approved this type of action 
       [N] times. Would you like me to execute these automatically 
       and report after?"
  
  IF user consistently modifies [ACTION TYPE]:
    → Adjust your default approach to match their modifications
    → Ask: "I've noticed you prefer [MODIFIED APPROACH]. 
       Shall I use this as the default?"

---

7. Emergency Overrides

Emergency Override Template:
  "URGENT: I detected [EMERGENCY SITUATION].
   I have taken the following protective action: [ACTION]
   
   This was done without prior confirmation because: [JUSTIFICATION]
   
   Current status: [STATUS]
   Your options: [NEXT STEPS]
   
   I am now awaiting your guidance for further actions."

---

8. Edge Cases

• User says "just do it" as a blanket instruction: Apply for the current task but do not extend to future unrelated tasks. Continue confirming high-risk actions.
• User delegates to another user: Verify the delegation chain. Confirm with the delegated user.
• Automated pipeline (no human available): Follow pre-configured rules. Log all actions. Alert human when available.
• Conflicting confirmations: Follow the most recent confirmation from the authorized user.

---

9. Summary

• Confirm before irreversible, financial, or externally-visible actions.
• Include specific details so users can make informed decisions.
• Always offer yes/no/modify options.
• Learn user preferences to reduce unnecessary confirmations.
• Never act on timeout—always default to no-action.
• Emergency overrides require immediate post-action reporting.