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.
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
Frequently asked questions
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.
Was this cheat sheet useful?
Comments
No comments yet — be the first.
Need a different cheat sheet?
Tell us what you would like to see and we will build it — free.
Request a cheat sheet
