Schedulers may retry an invocation after a timeout even when the first attempt partly succeeded. Give the run a stable identity based on schedule and intended window, then record stage receipts outside the model. A retry can recompute a read-only summary, but sending the same message or editing the same record twice may be harmful. The prompt should ask for the existing receipt before proposing another effect. Idempotency belongs in the application and destination API; a sentence saying 'do this only once' does not enforce it. After an ambiguous result, query the authoritative destination before retrying.
Make this comfortable
Recurring prompts: survive retries without duplicate effects
Operational case
North Pier's report is generated for window W-47. The first attempt saves the draft but times out before the scheduler gets a response. A retry with the same run identity finds draft receipt R-47 and continues from that artifact, rather than creating a second draft. If a notification send times out, the system checks the message destination for the idempotency key before attempting another send. The prompt may describe the uncertainty, but it cannot declare delivery based on its own prior text.
Run identity: north-pier / W-47 / review-v3.
Draft stage: receipt R-47 already exists -> reuse.
Notification stage: outcome unknown -> query destination by key.
Duplicate receipt found -> do not send again.
No authoritative result -> hold and escalate.Performance and operating cost
A keyed receipt lookup is O(1) average in an indexed store. A retry adds latency and possibly another model call, so resume from verified stages where possible. Stable run keys reduce duplicate side effects and make cost attribution easier. Keep an expiry rule for idempotency records longer than the maximum retry horizon; otherwise a delayed retry can bypass the deduplication window.
Common Mistakes
- Do not invent a fresh run ID for each retry of the same scheduled window.
- Do not assume a timeout proves the effect failed.
- Do not rely on prompt wording as the only duplicate-send control.
Connected lessons
- Production prompt engineering
- Prompt Engineering
- Tool effects: reconcile receipts before retrying
- Browser effect recovery: resolve ambiguous submissions before retrying
- Tool loops: set budgets, state checks, and a stopping condition
- 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: notify only on actionable changes
- 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