Why the habit streak forgives, and what that cost us
A habit streak usually works by making people feel bad. We built Grace Tokens, Flare Mode and a Bereavement Hold instead, and week-six retention improved.
The defect nobody logs
Notification timing is not a delivery detail. A reminder to stand up, delivered while you are driving, is not a neutral event. It is a small tax on attention and a slightly larger one on trust, and after enough of them the person turns notifications off — at which point the product is finished, however good the recommendation engine is.
So the context agent runs before every send, and returns one of three verdicts: deliver, defer with a retry window, or block with a named reason. A block is recorded as a successful decision, not a failure to deliver.
What blocks a send
Driving, detected from motion state rather than location. An active call. Do-not-disturb. The daily cap, which is per person and per mode. A minimum gap since the last one. Quiet hours. A calendar block marked as focused, which we read structurally — the titles never leave the device.
When a send is blocked, the API returns it as a success with `held: true`, the blocking reasons, and a retry window. It is not an error, and treating it as one is how you end up with a client that retries into the same wall.
The awkward growth conversation
Held rate as a headline metric makes every growth review slightly uncomfortable, because the obvious lever for weekly active users is to send more. We have the number in front of us specifically so that lever is visible when somebody reaches for it.
What we measure instead is completion rate per delivered message. Sending fewer and better moves that number in the direction that actually correlates with people still using the product in month six.
Timing is a bandit, not a language model
Notification timing is decided by a contextual bandit with a sub-second budget. It is not an LLM and the architecture notes say so explicitly, because "upgrade it to a model" is a suggestion that arrives about twice a year and is wrong every time.
How a calendar is read without reading it
The most useful signal for when somebody can move is their calendar, and the calendar is also the single most sensitive thing on a work device. Titles contain client names, medical appointments, disciplinary meetings and resignations.
So the calendar is read structurally. Start time, end time, busy or free, accepted or tentative, number of attendees, whether it recurs. The title is never transmitted, never logged and never sent to a model — it is in the redaction list the AI Gateway enforces before any external call, alongside names, clinical notes and free-text responses.
This costs accuracy. A meeting called "1:1 with Sam" and one called "quarterly board review" look identical to us, and the second is a much worse moment to interrupt. We accept the worse recommendation, and the notification a person receives says "calendar titles never left your device" so the trade is visible rather than assumed.
What a held nudge actually returns
The response is a success with `held: true`, an array of blocking reasons, and a retry window in seconds. Not a 4xx, not an empty body, not a silent no-op.
That shape matters more than it looks. A client that receives an error retries, logs an exception, and eventually shows the user something is broken. A client that receives an explicit hold with a retry window waits, and can tell the person why if they ask.
The metric we watch instead
Completion rate per delivered message, split by mode. It is the number that moves when the timing model improves and the number that falls when somebody quietly raises a daily cap to hit a weekly target.
Held rate sits next to it, unexplained and deliberately prominent. If it drops sharply without a corresponding change to the context model, something has been loosened and somebody should have to say what.