Skip to main content

What we’re building

A refund-monitoring job that watches for anomalies and uses User.Inbox.push() to reach the user proactively — the three card kinds working together:
  1. A notice when a refund spike appears (revised in place as numbers change),
  2. An approval when the agent has drafted a response and wants a go-ahead,
  3. A connection fix when the data source it depends on disconnects.
Along the way it handles every receipt outcome — including being capped — so the skill degrades gracefully instead of erroring.

The monitor

Run it again while the incident is live and the same card updates silently:

Asking for a go-ahead

When the agent has done the work and needs one human click, push an approval — approve without options becomes an Approve / Decline pair, and the user’s pick resolves the card:
Or offer real choices:

When the data source breaks

If the integration your monitor depends on disconnects, don’t fail silently — push the fix. The card deep-links the user straight into reconnecting:

Design notes

  • Key everything that recurs. A monitor without a key mints a new card per run and burns its daily budget by lunch. With a stable key, the whole incident is ONE card that stays current.
  • Let capped be boring. Five pushes per day per user per card class is the contract; your skill should have a summary-shaped fallback ready, not a retry loop.
  • Don’t lean on urgent. It’s capped at 2/day (the excess lands as high), and inside the user’s quiet hours even urgent sends no notification at all — the card still lands, and that’s what you should count on.
  • Test in lua dev. Pushes from dev runs land in your own Inbox, so you can watch the full loop — card, notification, revision, resolution — before your users ever do.