Narrative
Narratives give agents continuity, context, and a sense of ongoing relationships. They are the reason an agent can resume a conversation weeks later and still know what you were working on.
What is a Narrative?
A Narrative is not a chat session. It is a persistent storyline — a semantic container that groups related conversations across sessions, days, or even the lifetime of an agent. When you talk about “building a recommendation system” today and come back to it next week, the agent routes you to the same Narrative and picks up where you left off.
Narratives do more than organize chat history. They are the anchor for everything that belongs to a topic:
Each Narrative holds an ordered list of Events (interactions) and a dynamic summary that evolves with every conversation turn. When the agent is routed to a Narrative, it gets the full context of that storyline.
Active module instances — running jobs, chat histories, skill study sessions — are bound to the Narrative they belong to. Switch topics, and the agent’s active toolset switches with it.
Each Narrative tracks its participants (users, agents, system) with roles. The agent knows who is involved in this storyline and what their relationship is.
Long-running goals (an ONGOING job, a multi-session research project) stay alive as long as their Narrative exists. The agent can be reminded of stale goals and pick them back up.
How Narratives Are Created
Narratives come into existence through two paths.
Default Narratives
When an agent is created, the system generates eight default Narratives for each user. These cover common interaction patterns that don't warrant a dedicated topic:
Default Narratives have strict topic boundaries. The moment a user mentions a specific object or task, the system switches to a dedicated Narrative. Default Narratives also receive minimal updates — no LLM summary refresh, no embedding update.
Conversation-Driven Narratives
When the agent detects a genuinely new topic that doesn't match any existing Narrative, it creates a new one automatically. The system:
- 1.Extracts and summarizes a name and description from the user’s message
- 2.Creates an embedding vector for future semantic retrieval
- 3.Initializes a dynamic summary that updates as the conversation progresses
- 4.Binds module instances (ChatModule and others) — connecting the Narrative to the capabilities the agent needs for this topic
From this point on, the Narrative lives independently. It accumulates Events, updates its summary after every interaction, and refreshes its routing embedding periodically so that future messages about the same topic find their way back.
How Narratives Work in Conversation
Narrative Selection
When a message arrives, the system must decide which Narrative it belongs to. This happens in three stages during Step 1 of the runtime pipeline.
Continuity Detection
If the user has an active session with a current Narrative, an LLM call checks whether the new message belongs to the same storyline. It compares the previous query and response against the current message, the Narrative's summary and keywords, and the time elapsed.
Key insight: conversational continuity ≠ same Narrative. A user may speak continuously but switch topics. Continuity is judged by business intent, not surface-level phrasing.
Semantic Search
The user's message is converted to an embedding vector and compared against the routing embeddings of all existing Narratives. Candidates are ranked by similarity score.
If EverMemOS is enabled, it provides hybrid search (BM25 keyword + vector similarity via Reciprocal Rank Fusion), producing more accurate candidate scoring. Otherwise, the system falls back to native vector search with cosine similarity.
Agent Decision
The system routes based on the similarity score:
What a Narrative Carries into the Conversation
Once a Narrative is selected, it loads everything the agent needs to continue the storyline. This is what makes cross-session memory work — the context isn't rebuilt from scratch, it's restored from the Narrative.
The ChatModule instance bound to this Narrative provides the recent conversation history (up to 30 messages). Each user gets their own ChatModule instance, so multi-party Narratives maintain independent conversation threads.
An LLM-maintained rolling summary of what has happened in this storyline. Updated after every interaction. Injected into the system prompt so the agent has a compressed overview even beyond the 30-message window.
Module instances bound to this Narrative are loaded and their MCP tools become available. If there’s a running job, the agent sees its status. If a skill was being studied, the study context is restored.
The actor list — who created this Narrative, which agents participate, which users are involved. Roles (creator, participant, agent) give the agent social context for the interaction.
Up to two auxiliary Narratives (other recent topics) are loaded alongside the main one, providing brief summaries so the agent knows what else you’ve been discussing.
How Narratives Evolve
After each interaction (Step 4 of the pipeline), the selected Narrative dynamically updates:
- 1.The Event is appended to the Narrative’s event list
- 2.An LLM refreshes the dynamic summary (name, keywords, and a structured bullet-point summary) based on the latest conversation
- 3.Every 5 interactions, the routing embedding is regenerated so future semantic search stays accurate as the topic evolves
- 4.Instance bindings are updated — completed modules move to history, new ones are linked
Narratives are living documents. A storyline that started as “quick Python question” and evolved into a deep multi-session project will have its name, summary, and embedding updated to reflect the current state — not the original message that created it.