How Engagement Sequences Affect Recommendations
One of the most important ideas in X's open-source recommendation architecture is that your past engagement isn't treated as a simple counter. The system uses a user's engagement history as a sequence. Phoenix processes that history with a transformer to create a representation of the user, which is then used for both candidate retrieval and ranking. (GitHub)
What you do on X helps provide context for what the recommendation system considers relevant to you next.
What Is an Engagement Sequence?
An engagement sequence is essentially a history of interactions with posts (e.g., Post A → Like; Post B → Reply; Post C → Repost; Post D → Click; Post E → Dwell).
The open-source Phoenix implementation represents each history item using information including the post, author, actions, and product surface. (GitHub)
1. X Looks Beyond a Single Interaction
Suppose you like one AI post. That alone doesn't necessarily define your interests. Now imagine your recent history includes liking an AI post, replying to an AI post, reposting an ML post, clicking an AI article, and dwelling on an AI discussion. The sequence provides much richer context. The Phoenix retrieval model explicitly encodes user features + history through a transformer to produce a user representation. (GitHub) One action = one piece of information; a sequence of actions = behavioral context.
2. Different Actions Carry Different Information
The open-source example defines action types including favorite, reply, quote, repost, dwell, video quality view, and the broader model supports many action types. (GitHub) Like, reply, repost, click, dwell, and share are not necessarily interchangeable pieces of information. A reply, for example, demonstrates a different kind of interaction from simply scrolling past a post. The model receives these actions as part of the history representation. (GitHub)
3. The Sequence Helps Build a User Representation
Phoenix Retrieval uses a two-tower architecture. The user tower takes user information and engagement history and transforms it into a normalized user embedding. (GitHub) User features + engagement sequence → Phoenix Transformer → User representation → Similarity search → Potentially relevant posts. This representation is then compared against candidate representations during retrieval. (GitHub)
4. Sequence Context Helps With Out-of-Network Discovery
This is especially important for recommendations outside your existing network. Phoenix Retrieval searches a large candidate corpus using similarity between the user representation and candidate representations. (GitHub) If your history shows AI likes, ML replies, AI reposts, and programming dwells, it generates a user representation used to search the candidate corpus for AI, ML, and programming posts, allowing the system to discover posts from accounts the user doesn't follow.
5. The Order of Interactions Is Part of the Sequence
The architecture uses a transformer over the history sequence rather than simply adding up engagement totals. (GitHub) Compare User A (AI like, AI reply, AI repost) with User B (AI like, sports reply, finance repost). Both users might have 1 like, 1 reply, and 1 repost, but their sequences are different. The transformer provides a mechanism for interpreting the history as contextual sequence information rather than merely three independent counters. (GitHub)
6. Recent Behavior Can Become Part of Current Context
The public architecture describes the input as a user's engagement history and processes that history through the transformer. (GitHub) This means your current behavioral context can differ from your historical follower graph (previously: sports history; recently: AI history). Your current recommendation context may therefore contain a different signal from simply looking at what accounts you follow.
7. The Model Doesn't Just Count Likes
A simplistic system might tally AI likes vs. sports likes and recommend the highest total, but the open-source architecture is more sophisticated. The history is represented as a sequence containing post, author and action information and processed through a transformer. (GitHub) Engagement history is modeled as contextual information, not simply a leaderboard of interests.
8. Multiple Actions Can Reinforce a Topic
Repeated relevant interactions (AI post #1 Like, AI post #2 Reply, AI post #3 Repost, AI post #4 Dwell) provide several pieces of evidence pointing toward the same general area, producing stronger context and a user representation that matches relevant candidates. But it would be incorrect to turn this into a public formula such as “Four AI engagements give you an AI interest score of 80.” X's open-source repository does not provide such a creator-facing formula.
9. The Sequence Can Contain Different Topics
The model doesn't require your history to be about one subject (e.g., AI like, cricket reply, finance click, AI repost, travel dwell). The transformer receives the complete sequence and produces a representation of the user context. (GitHub) That's fundamentally different from saying the user belongs to exactly one interest category.
10. The Sequence Also Contains Author Information
Phoenix's retrieval implementation represents history using both post and author information, along with actions. (GitHub) Post + Author + Action + Context = History item. So the system isn't simply processing LIKE, REPLY, and REPOST in isolation; the interaction is associated with a particular post and author.
11. Product Surface Is Also Part of the Representation
The open-source model includes a product surface representation for history and candidates. (GitHub) This provides another piece of contextual information about where the content interaction occurs. For an architecture guide, the important point is that the history representation contains more than just the action itself.
12. The Same Action Can Mean Different Things in Different Contexts
Post A Like versus Post A Reply represent different interactions. The model explicitly represents actions using action embeddings. In the retrieval implementation, multi-hot action vectors are projected into embeddings before being processed by the transformer. (GitHub) Action → Action embedding → History representation.
13. Engagement Sequences Influence Retrieval
The first major impact is candidate retrieval. Phoenix converts the user's history into a user representation and compares it with candidate representations using dot-product similarity. (GitHub) The example pipeline explicitly performs encoding user history, dot product against the corpus, retrieving top-K candidates, and ranking those candidates.
14. Engagement Sequences Also Influence Ranking
History isn't only relevant to retrieval. The Phoenix ranking model takes user context including engagement history together with candidate posts and predicts engagement probabilities. (GitHub) User history + candidate post → Phoenix Ranker → Predicted actions. So the same behavioral context can matter at multiple stages.
15. Retrieval and Ranking Are Different
Retrieval asks Which posts should we consider? while ranking asks Which of those candidates are strongest for this user? The example Phoenix pipeline explicitly performs retrieval first and ranking second. (GitHub)
16. The Model Uses a Long History Window
The published mini configuration lists a history sequence length of 127 for the ranking model, while the retrieval model configuration defaults to a history sequence length of 128. (GitHub) This is useful evidence that the architecture is designed to process a sequence of many historical interactions, not just the user's immediately previous action (though this is a model configuration, not a complete description of every production data-retention mechanism).
17. Continuous Actions Add Another Layer
The ranking model also supports continuous predictions, including continuous action features (the current configuration specifies eight continuous-action outputs). The public architecture therefore goes beyond simple binary liked/didn't like and can model richer behavioral signals, which is particularly relevant for attention-related behavior such as dwell.
18. Engagement Sequence ≠ Engagement Score
An engagement score is a numerical summary of engagement, whereas an engagement sequence is a sequence of interactions with context (Like → AI post; Reply → ML post; Repost → AI post; Dwell → Programming post). The open-source architecture is built around the latter concept.
19. Why This Matters for Recommendations
Imagine two users seeing the same AI post candidate: User A has an AI-heavy engagement history, while User B has a sports-heavy history. The same candidate can have different recommendation potential because the users have different behavioral context (Higher relevance for User A vs. lower relevance for User B). This is the basic idea behind personalized recommendation.
20. A Sequence Can Change the User Representation
Suppose a user's recent interactions change from old sports history to new AI history. The architecture allows the user representation to be generated from the supplied history sequence. (GitHub) So recommendation isn't necessarily based on a permanent user-interest label.
21. This Does Not Mean Every Action Immediately Changes Recommendations
The open-source architecture demonstrates how engagement history is input into the model, but it does not establish a public rule saying “One like immediately changes your feed” nor does it reveal the exact production update timing for every user. The defensible statement is that engagement history is part of the model's context for determining relevance and ranking.
22. It Doesn't Mean Every Engagement Has the Same Weight
Don't simplify the architecture to Like = Reply = Repost = 1. The model represents different action types separately. (GitHub) The ranking system also predicts multiple action probabilities and combines them through scoring. Therefore, engagement types should be treated as different behavioral signals, not identical points.
23. A Sequence Can Explain Why Recommendations Change
A recommendation system with sequence-based user modeling has contextual information showing that the user's behavior has changed (e.g., Monday AI engagements shifting to Friday cricket engagements). That can affect which candidates look relevant. Again, this is a conceptual interpretation of the architecture—not proof that X uses a simple topic-switching rule.
24. Engagement Sequences Help Explain “Why Am I Seeing This?”
Suppose X recommends an account you've never followed. A useful Under The Hood explanation is: Your engagement history → User representation → Candidate retrieval → Potentially relevant post → Ranking → Recommendation. The person doesn't necessarily need to have followed the author because Phoenix Retrieval can discover candidates from a broader corpus. (GitHub)
25. Engagement Sequences Help Explain “Why Am I Not Seeing This?”
The reverse is also true: a post can exist on X and still not become a strong candidate for you because your history produces a user representation that makes other candidates more relevant. So following an account does not necessarily mean seeing every post.
26. The Sequence Isn't the Only Input
The open-source architecture also includes user features such as following and preferences. The README explicitly shows User Action Sequence alongside User Features in query hydration. (GitHub) So a better model is User features + Engagement history + Candidate information → Recommendation models. Don't describe engagement history as the only factor.
27. The Complete Engagement-Sequence Flow
This matches the broad architecture documented in X's open-source repository. (GitHub)
28. What Creators Should Understand
For creators, the important lesson isn't getting exactly X likes. It is that your audience's behavior helps determine which users are likely to find future content relevant. If people who are genuinely interested in your topic repeatedly engage with your content, that creates behavioral context associated with those users, which can help explain why your content may subsequently be relevant to users with similar behavioral patterns (though the open-source code does not establish a simple creator-level formula such as 100 likes → 10,000 new users).
What the Open Source Confirms vs. What It Does Not Establish
What Open Source Confirms
- • User engagement history is explicitly part of the recommendation model. (GitHub)
- • Phoenix uses a transformer to encode user features and history. (GitHub)
- • History contains posts, authors and action information. (GitHub)
- • Different action types are represented through action embeddings. (GitHub)
- • The user representation is used for retrieval. (GitHub)
- • Retrieved candidates are subsequently ranked using predicted engagement. (GitHub)
- • The ranking model also receives user history as context. (GitHub)
- • The published configuration supports a substantial history sequence. (GitHub)
What Open Source Does Not Establish
- ✗ Exactly how much one like changes your recommendations
- ✗ That a reply is worth a fixed number of likes
- ✗ That the newest interaction always has the greatest weight
- ✗ A public “interest score” for every topic
- ✗ A fixed time after which engagement history expires
- ✗ That one engagement immediately causes a specific recommendation
- ✗ That creators can directly manipulate another user's profile
The Engagement-Sequence Model
The Key Takeaway
X doesn't just learn from how much you engage—it uses your engagement history as a sequence of behavioral context. The open-source Phoenix architecture feeds user history into a transformer to create a user representation. That representation helps retrieve potentially relevant posts, while the ranking model uses user history and candidate information to predict possible engagement. (GitHub)
So the useful mental model is: Past interactions → behavioral context → user representation → candidate relevance → predicted actions → recommendations. And importantly, engagement sequence is not a public “points system”; it is model input used to understand the user's context.
Official Open-Source References
- • X / xAI — For You Algorithm repository — current architecture, Phoenix, Thunder, filtering, scoring and candidate pipeline. (GitHub)