No data, stale data, and idempotent retries

A cheap, well-scheduled routine can still hurt you if it does the wrong thing when something goes sideways. Grok Bot's "design routines for trust" guidance gives three habits that cost nothing to add and save you real pain. Build them into every routine from the start.

1. A no-data and stale-data policy. The worst failure mode isn't a routine that crashes — it's a routine that quietly uses old data and reports it as current. Picture a "daily numbers" routine whose source is down one morning. Without instructions, a helpful Bot may fall back to yesterday's figures and present them as today's, and you act on a number that's a day stale. So tell it explicitly what to do when data is missing or old. The documentation's example says it cleanly: "If the source data is unavailable, report the failure instead of using old data." Decide this per routine — report and stop, or clearly label the data as stale — but never leave it unsaid.

2. Idempotent retries. "Idempotent" just means safe to run more than once with the same result. Routines re-run — on a retry, after a hiccup, sometimes twice in quick succession. If a routine posts "Daily summary" every time it runs, a double-run gives you two posts. If instead it updates the daily summary (one per day, overwritten), a double-run is harmless. Design actions so repeating them doesn't pile up duplicates: update-in-place instead of append, check "did I already post today?" before posting, key records by day. Grok Bot's own guidance is to "make retries idempotent where possible" — take it literally.

3. Tell it where to report partial completion. A routine that gets halfway and stops should say so, somewhere you'll see it, rather than failing silently. "If you complete some accounts but not all, post which ones succeeded and which were skipped, and why." A half-finished run you know about is a minor annoyance; a half-finished run you don't know about is a landmine.

There's a fourth habit that spans all of these: re-test after things change. Websites, connectors, and data formats drift, and a routine that worked last month can start doing something subtly wrong when a page it reads gets redesigned. The docs advise pausing a routine when its source system or expected workflow changes, and re-testing before you turn it back on. Put differently: a routine is not "set and forget." It's "set, watch, and re-check when the ground moves."

None of this makes a routine more expensive. It makes a routine trustworthy, which is the only kind worth running on a timer while you're not watching.