AI Automation Design Cheat Sheet
Triggers, idempotency and what to do when the model is wrong at 3am
An automation runs without you. That single fact decides every design choice — above all what happens when a step fails unobserved.
Category: AI Automation Difficulty: Intermediate Version: 1.0 Updated: January 14, 2026 Author: Sabir
Triggers
| Trigger |
Fires on |
Watch for |
| Schedule |
A clock |
Overlapping runs when one is slow |
| Webhook |
An external event |
Duplicate deliveries — they are guaranteed, not rare |
| Polling |
A change you detect yourself |
Missing changes between polls |
| Queue |
A message |
Poison messages retried forever |
| Manual |
A person |
The only one where someone is watching |
Non-negotiables
- An idempotency key on every side effect — Retries are certain; double-charging must not be
- Exponential backoff with jitter — Fixed retries turn one outage into a synchronised stampede
- A dead-letter path — Something must catch what fails every retry, or it is simply lost
- Validate model output BEFORE the side effect — The schema check is what stands between a bad parse and a sent email
- A confidence threshold that routes to a human — Low confidence should queue for review, not proceed quietly
- Alert on silence, not only on errors — A workflow that stopped triggering raises no error at all
- Log the prompt, the response and the version — Without them a wrong output cannot be reproduced
FAQs
What is the most commonly skipped safeguard?
Alerting on silence. Every team alerts on errors; far fewer notice when a workflow simply stopped triggering, which raises no error at all.
Do I really need idempotency keys?
Yes. Webhooks are delivered more than once by design and retries are certain, so every side effect must be safe to attempt twice.