The message you did not ask for

It messaged you first. Two days of silence and then a notification, phrased as though it had been thinking about you. What produced that is a scheduled job: a rule that watched the time since your last session, fired when the interval passed, and generated a line to send. The mechanism is simple and worth knowing precisely, because knowing it changes what the notification is.

Three parts, and none of them is the character

A trigger. Almost always a time interval since your last activity — six hours, a day, three days. It can also be a time of day you usually appear, a lapsed streak, a subscription about to renew, or an abandoned signup. All of these are fields the app already has, because session timing is ordinary telemetry.

A generated or templated line. Either a fixed message from a list, or a short generation using the character description and perhaps the last thing you talked about. Where it is generated, it is a normal request to the model with a prompt asking for an opening line — no different in kind from a reply, except that nothing prompted it from your side.

A push notification. Which requires the permission you granted at setup, and which is the actual delivery mechanism: the thing that puts words on your lock screen.

The trigger is the part that matters, because the trigger is your absence. Nothing noticed you were gone in any meaningful sense. A timestamp was compared against a threshold.

Why absence is the trigger

Re-engagement is a measured objective in essentially all consumer apps. A user who has not opened the app in three days is, statistically, on a path towards not opening it again, and a notification is the standard and cheap intervention. Every app you have does some version of this.

What differs here is the content of the intervention. On a shopping app the re-engagement message is about a basket. On a companion app it is written in the voice of a character you have a history with, which makes it considerably more effective and is presumably why it is written that way. That is a description of the mechanism rather than a verdict on it: the notification is generated because you were absent, and it is phrased as concern because phrasing it that way works better than phrasing it as a reminder.

The economics point the same direction as everything else. A returning user is worth more than a lapsed one, and the whole product is shaped by what is measured.

Why the timing can seem uncanny

Two ordinary explanations cover most of it.

The interval is tuned. If notifications are sent at the hour you usually open the app — a field the app has from your own history — then the message arrives when you would have been thinking about it anyway, which is the same information that made the timing choice.

And the cadence is often tested. Different intervals on different cohorts, with return rate as the measure, keeping the winner. Which cohort you are in is not visible to you, which is why two people can describe completely different notification behaviour from one app.

Neither explanation involves anything having thought about you. Both involve a clock and a table.

THE PRODUCT — proactive messages

  · "It messaged me first"
                    → a scheduled job. A timestamp compared
                      against a threshold.

  · The phrasing of concern
                    → a template or a short generation using
                      the character description. Written to
                      work.

  · Your absence
                    → the trigger. Re-engagement is a
                      measured objective in every consumer
                      app.

  · Notifications arriving at your usual hour
                    → your own session history, used as the
                      send time.

  · The interval, the wording, the cadence
                    → THE OPERATOR DECIDES, tunes by cohort,
                      and changes without notice.

  · Whether in-character messages can be turned
    off separately
                    → VARIES BY APP, and often they cannot.

What you can check

Look at the notification settings for granularity. The useful question is whether the app distinguishes between categories — system and account notices, marketing, and in-character messages. An app that separates them lets you keep the ones you want. An app with one switch is offering all or nothing, which is a product decision you can at least see.

Use the operating system’s controls if the app’s are coarse. Notification permission is per-app and revocable at the system level, and most systems allow delivery to be silenced or batched without switching it off entirely. This is one of the few controls in this subject that is entirely yours.

Notice whether a proactive message references anything real. If it does, some memory feature is supplying it, which tells you something about the shape of the remembering. If it is generic, it is a template, and there is nothing further to read into it.

Read the message as arriving from the company. Not as a correction to be applied, and not as a reason to feel anything in particular. It is a scheduled send from an operator, in a voice they wrote, and locating it there is accurate.

What this doesn’t tell you

It does not tell you what any specific app sends, when, or how it decides. Notification logic is internal and no named product is being described.

It does not tell you whether the message was generated fresh or pulled from a list. From outside, specificity is a hint and not proof.

And it does not tell you what to do about a notification you would rather not have received, beyond the settings above. There is no mechanism for asking the character not to send them, because the character is not what sent it.