What would it take to let behavior drive Workflows? #215

Activity

1. Silthus

   added

   wayfinder:research

   on Oct 3, 2026
2. Silthus

   added a parent issue on Oct 3, 2026

   • Map: grow Workflows activation, from first visit to first delivered message #210
3. Silthus

   marked this as blocking on Oct 3, 2026

   • Rank the growth bets and choose which get their own map #219
4. Silthus

   self-assigned this

   on Oct 3, 2026
5. Silthus commented on Oct 3, 2026

   

   Silthus

   on Oct 3, 2026

   OwnerAuthor

   More actions

   Claimed by a Claude Code research worker (Opus 5.5)
6. Silthus

   removed their assignment

   on Oct 3, 2026
7. Silthus commented on Oct 3, 2026

   

   Silthus

   on Oct 3, 2026

   OwnerAuthor

   More actions

   Lane orphaned: the worker's temporary worktree was removed while its sub-agents ran. Unassigned; the conductor redispatches it in a persistent worktree.
8. Silthus

   self-assigned this

   on Oct 3, 2026
9. Silthus commented on Oct 3, 2026

   

   Silthus

   on Oct 3, 2026

   OwnerAuthor

   More actions

   Claimed by a Claude Code research worker (Opus 5.5), redispatch
10. Silthus commented on Oct 3, 2026

    

    Silthus

    on Oct 3, 2026

    OwnerAuthor

    More actions

    Resolution. Full findings with code citations: https://github.com/Silthus/posthog/blob/research/behavioral-triggers/research-behavioral-triggers.md

    Sizes are guesses (S about a week, M two to three weeks). Evidence is the code on master.

    Capability	Design option	Size	Main risk
    Behavioral cohorts as Broadcast audiences	Recalculate the cohort when the send starts, then pin that version for every audience page. Today the audience query reads precalculated raw_cohort_people, recalculated oldest-first at most every 15 min, so relative-time behavior drifts. Where realtime cohorts run, read the fresh cohort_membership store instead.	M	The send waits on a cohort calculation; a slow or failing calculation delays or blocks the broadcast
    Trigger on entering or leaving a cohort	New cohort trigger: a consumer on the existing cohort_membership_changed stream (realtime cohort pipeline already emits per-person entered/left), live changes only, builds invocations with the batch resolver's helper and trigger masking	M	Only realtime-eligible cohorts (performed_event/performed_event_multiple plus person properties) on teams the realtime pipeline covers
    Inactive for N days	A preset on the cohort trigger: realtime cohort "did not perform X in last N days", trigger on entered. The pipeline's sweep already moves people out when a window expires. Fallback without realtime: daily schedule trigger with an audience on persons.last_seen_at plus "One time" masking	S on top of the cohort trigger (fallback S–M)	Same coverage limit; the fallback depends on the opt-in person_last_seen_at_enabled setting
    Person-level feature flag condition	New feature_flag condition in conditional_branch, evaluated in the CDP by calling the flags service /flags for the run's distinct_id, lazily like cohort membership	S–M	A network call per evaluation on the run path, and the CDP needs a flags service credential

    Two traps found: a flag property filter compiles to constant true in property_to_expr, so a flag condition must not go through the normal filter path; and seed/reconcile membership changes must never fire the cohort trigger, or a new cohort enrolls every member at once.

    Suggested order: cohort trigger, inactivity preset, flag condition, then behavioral Broadcast audiences.
    Open questions for Michael: how far the realtime cohort pipeline reaches today, and how a flags service credential gets to the CDP.
11. Silthus

    closed this as completedon Oct 3, 2026