Notification policy is part of a recurring task's output contract. Define what counts as a meaningful change, the severity threshold, the destination, and a quiet path when nothing actionable changes. Preserve an audit record for every run without sending that record to the user each time. Group related events within a stated window and de-duplicate alerts by case identity. A missing data source may warrant a failure alert even when no business event is confirmed. The prompt classifies candidate messages; the delivery layer enforces channel rules and user preferences.
Make this comfortable
Recurring prompts: notify only on actionable changes
Operational case
North Pier sees the same six held parcels across three morning runs. The run ledger records all three checks, but the manager receives no repeated alert. A seventh parcel becomes held with a verified scan, so one alert names the new record and its evidence. A failed endpoint on the following morning produces a distinct source-failure notice rather than claiming another parcel change. If the manager muted routine changes but not failures, the trusted notification service applies that preference.
No verified change -> record run; no user notification.
New hold H-71 -> one actionable alert with evidence ID.
Same H-71 next run -> suppress duplicate alert.
Source unavailable -> failure notice, not a hold count.
Channel and mute settings -> enforced by delivery service.Performance and operating cost
Comparing current and prior sets is O(N) with hash keys and O(N) storage for the snapshots. Alert grouping adds a small keyed state store, but reduces review time and notification fatigue. A high threshold can miss emerging incidents; a low threshold can overwhelm the user. Evaluate precision, missed critical events, and alerts per week on held-out windows, then set a documented threshold rather than letting the model improvise one per run.
Common Mistakes
- Do not send the unchanged run ledger as a fresh alert.
- Do not suppress a source failure because no changed business record was found.
- Do not let model prose override a user's channel or mute settings.
Connected lessons
- Production prompt engineering
- Prompt Engineering
- Online prompt experiments: define exposure and stop rules first
- Incident updates: audience, owner, and release gate
- Memory prompts: confirm intent before durable writes
- Recurring prompts: define the trigger and stop condition
- Recurring prompts: bind local time and data windows
- Recurring prompts: validate fresh inputs and empty states
- Recurring prompts: survive retries without duplicate effects
- Recurring prompts: renew authority for sensitive actions
- Recurring prompts: make every run replayable and auditable
- Project: build a North Pier recurring review
- Recurring prompt workflow decisions
prompt engineering
recurring workflows