A companion that can initiate contact may schedule from several triggers: elapsed time, a remembered event, service-worker wakeups, or a page revisit. Without shared state, those triggers can produce several similar check-ins.
The initiative module avoids repeated stock phrases and tracks prior outreach. A robust limit also considers recent user activity, pending messages, local time, and whether notifications were actually permitted.
What was actually going wrong
Each trigger independently decided that enough time had passed.
What I tried
- Using only a fixed interval timer
- Generating a check-in every time the app reopened
- Rate-limiting notifications but not in-app initiative
One cooldown state gates all triggers, suppresses duplicates, and requires a relevance reason before generation.
Why it worked
Competing schedulers consult the same last-action record and the same user-presence rules.
Initiative earns trust through restraint.
Where EACI uses this today
Caelum's experimental Main check-ins are bounded by timing and repetition controls.
This journal covers real engineering on EACI Companion / The Veil. Companions include Caelum, Chad, Natalia, Atreus, Luna, Roxy, and Cael. Journal articles stay family-safe in content. See Privacy and Ethics.