Overview
How might we design time-delayed execution so people can trust and act on AI output?
When this pattern fits
- Essential for email clients, payment flows, agent actions, and any interface where high-impact irreversible operations benefit from a short cancelable window.
When to skip or lighten it
- Low-stakes local edits where delay only frustrates.
- Emergency stop systems that must act immediately.
- Actions already gated by a full approval review with no time pressure.
States
State model coming soon
Key UX elements
Key UX elements coming soon
Anti-patterns to avoid
Delays too short to read the payload.
No visible countdown or cancel control.
Continuing the action after the user hit cancel.
Using delay as the only safety net for irreversible ops.
How products use it
| Product | Implementation |
|---|---|
| Gmail | Undo Send window after sending mail. |
| Slack | Scheduled send and editable pending messages. |
| Cursor | Confirm windows before risky agent-applied changes. |
| Stripe | Payment confirmation steps before capture. |
Implementation
Copy this prompt to generate a production-ready implementation in Cursor, Claude Code, Lovable, or any AI coding agent.
Generate a production-ready implementation of the "Time-Delayed Execution" AI interface design pattern.
Pattern Definition:Frequently asked questions
What is time-delayed execution?
It is a short cancelable wait between confirming an AI action and the side effect landing, similar to Undo Send.
How long should the delay be?
Often 5–30 seconds for messages; longer for deletes or spends. Match the time needed to skim the payload.
How does it differ from human-in-the-loop?
HITL requires explicit approval. Time delay assumes intent but still allows abort. Many flows use approval first, then a short undo window.
What must the countdown UI show?
What will happen, when, and a prominent Cancel. Optional Edit beats forcing a full restart after cancel.