Persistent cross-conversation memory: how it works, what it keeps, and what it doesn't
Most AI assistants forget you the moment you close the tab. Selina doesn't. Her persistent memory carries what you've told her from one conversation to the next, organized by topic, retrieved by meaning rather than keyword match. This post explains the implementation in enough detail for a technical evaluator to make a decision, and in enough plain language for a prospective user to understand what they're signing up for. We also cover what we don't claim, because that matters more than marketing copy.
Key Takeaways
- Selina retains information you share across conversations, organized by topic and recalled through semantic similarity rather than keyword lookup.
- Memory is encrypted at rest but is NOT end-to-end encrypted and is NOT zero-knowledge encrypted. A slice of each request reaches a frontier provider at inference time. We state this plainly because it matters.
- Memory is adaptive, not a verbatim transcript. It captures structured meaning, not raw chat logs.
- You control what stays and what goes. Delete means gone. Actually gone.
- Non-content operational metadata is kept for a short retention window, not indefinitely and not with zero retention.
What does cross-conversation memory actually mean?
It means that facts you share in one session are available in every future session, without you repeating them. If you tell Selina your deployment stack on Monday, she knows it on Thursday. If you mention a vendor preference in January, it's there in March.
This is distinct from the per-session context window that most AI assistants rely on. A context window is a short-term buffer. It empties when the conversation ends. Cross-conversation memory is a persistent store that survives across sessions, organized so Selina can find the right piece of information when it becomes relevant again.
Simple concept. The implementation is where it gets interesting.
How is memory organized and retrieved?
Memory entries are organized by topic, not by timestamp or conversation ID. When you tell Selina something, the system determines what topic it belongs to and stores it accordingly. Later, when a query touches a related subject, the system retrieves entries by semantic similarity.
Semantic similarity means the retrieval is based on meaning, not string matching. If you stored a note about "Kubernetes pod autoscaling" and later ask about "scaling containers automatically," those connect. Keyword search would miss that. Semantic retrieval doesn't.
This is not a search engine bolted onto a chat interface. It's a retrieval layer integrated into the reasoning pipeline. When Selina receives a new message from you, the system checks whether any stored memory entries are relevant to the current context, pulls them in, and uses them as part of the response generation. You don't need to ask for your memories. They surface when they're useful.
What does Selina remember and what does she discard?
Selina remembers structured facts, preferences, and context you've shared. She does not store a verbatim transcript of every conversation. The memory is adaptive: it captures the meaning and the useful detail, not the exact words you typed at 2am while half asleep.
Some examples of what persists:
- Technical preferences (your preferred programming language, your team's coding conventions)
- Project context (the name of your current project, what stage it's in, which problems you've already solved)
- Personal working style (whether you prefer concise answers or detailed explanations)
- Domain-specific knowledge you've shared (your company's internal terminology, your infrastructure layout)
Some examples of what does not persist:
- Throwaway conversational filler
- Corrections that supersede earlier information (the old version gets replaced, not accumulated)
- Content you explicitly ask Selina to forget
We do not claim "perfect" or "complete" memory. The system is adaptive. It captures what is likely to be useful in future interactions. Sometimes it will miss something you expected it to keep. Sometimes it will surface something you forgot you mentioned. The goal is usefulness, not archival completeness.
How does the encryption work for stored memory?
Memory content is encrypted at rest. Your stored information sits encrypted in our infrastructure when it is not actively being used.
Here is the honest limit: memory is NOT end-to-end encrypted. Memory is NOT zero-knowledge encrypted. At inference time, a slice of each request, including relevant retrieved memory, reaches a frontier provider so the model can generate a response. We cannot do useful AI reasoning on data that no model can ever see. Anyone who tells you otherwise is either doing something very different from what they're describing or not doing useful AI work.
This is a meaningful distinction. For files and transfers (SelinaSEND), we do provide zero-knowledge, end-to-end encryption. For memory, we do not. The reason is architectural: file transfer is a conduit (bytes in, bytes out, no interpretation needed), while memory must be interpreted by a model to be useful. Interpretation requires access.
Your account itself is protected. Content within it is encrypted. These are precise words chosen for precise reasons.
What about operational metadata?
Non-content operational metadata (timestamps, request counts, routing decisions) is retained for a short retention window. We do not claim zero retention because that would be inaccurate. Some operational data is necessary for abuse prevention, debugging, and billing. It is kept for as short a period as we can manage while still operating a reliable service, then it is purged.
We are specific about this because vague privacy language is, in our experience, a sign that someone hasn't actually thought through their data lifecycle. We have thought through ours. The answer is "short retention window with defined purge," not "we keep nothing" and not "we keep everything."
How does semantic retrieval differ from keyword search?
Keyword search matches strings. If you stored "PostgreSQL connection pooling configuration" and later ask about "database connection management," keyword search finds no overlap. The words are different.
Semantic retrieval works on meaning. It represents both the stored memory and the incoming query as vectors in a high-dimensional space, then measures the distance between them. Concepts that are related end up close together, regardless of the specific words used.
This matters in practice more than it sounds like it should. People don't use consistent terminology across weeks and months. You might say "CI pipeline" in one conversation and "build system" in another and mean the same thing. Semantic retrieval connects these. Keyword search does not.
The retrieval is also topic-aware. Memories are organized into topic clusters, so the system can narrow the search space before measuring similarity. This keeps retrieval fast and relevant even as the total volume of stored memories grows over months of use.
Can I control what Selina remembers?
Yes. You can tell Selina to forget specific things. You can ask her what she remembers about a given topic. You have control over the stored content.
Delete means gone. Actually gone. When you delete a memory, it is removed from the persistent store. It is not soft-deleted, not archived, not moved to a "deleted items" bucket that someone could theoretically restore. It is gone.
This is a design choice with a cost: if you delete something and later wish you hadn't, we cannot recover it. We consider that the correct tradeoff. Your data, your decision, irreversible by design.
What happens at inference time?
When you send a message, the system performs several steps in sequence. It analyzes the incoming query. It checks the persistent memory store for entries with high semantic similarity to the current context. It retrieves the relevant entries. It assembles a prompt that includes those entries along with the current conversation context. It sends that assembled prompt to a stack of frontier models, routed per task. The model generates a response.
The relevant memory entries travel to the frontier provider as part of that prompt. This is why memory is NOT end-to-end encrypted. The model needs to read the information to use it. We cannot encrypt data from the very system that must interpret it.
We route requests through a stack of frontier models, selected per task. We do not name specific models or providers. The routing is automatic and opaque to you as a user. What matters to you is the output quality and the privacy posture, not which specific model handled a given request.
How does memory handle contradictions and updates?
If you tell Selina something that contradicts a previously stored memory, the system updates rather than accumulates. If you said your team uses React in March and then tell Selina you've migrated to Svelte in June, the memory reflects Svelte. The old entry is replaced, not kept alongside the new one.
This is the adaptive part. The system is designed to reflect your current state, not to maintain a historical log. If you want a historical log, there are better tools for that. This is a working memory, closer to how a competent colleague remembers your preferences: they update their understanding when things change.
There are edge cases where this gets complicated. If you work on multiple projects with different tech stacks, the system needs to keep both in memory and distinguish between them by topic. It does this. Not perfectly, but well enough that it is useful rather than confusing.
What are the limits of persistent memory?
We are going to list the limits plainly because you need them to evaluate whether this is right for you.
- Memory is not a verbatim transcript. It captures structured meaning. Some nuance is lost in the summarization process.
- Memory is NOT end-to-end encrypted. If your threat model requires that no third party ever sees your data in any form, persistent memory in its current architecture does not meet that requirement. SelinaSEND (file transfers) may, but memory does not.
- Memory is not unlimited. There are practical limits on how much can be stored and retrieved effectively. We don't claim unlimited anything, credits included.
- Retrieval is not perfect. Sometimes a relevant memory won't surface because the semantic similarity score falls below the retrieval threshold. Sometimes an irrelevant memory will surface because the system misjudged the similarity.
- The system cannot remember things you never told it. This sounds obvious, but it's worth saying: Selina knows what you've shared with her. She does not infer information from external sources about you.
These limits are inherent to the architecture, not bugs we're working on fixing next quarter. Some of them could be reduced over time, but honesty about the current state is more useful to you than a roadmap promise.
How does this compare to context-window-only assistants?
Most AI assistants rely entirely on the context window: the text of the current conversation, plus maybe a system prompt. When the conversation ends, everything in the context window is discarded. The next conversation starts from zero.
This means you re-explain your setup, your preferences, your constraints, every single time. The assistant is perpetually new to you. It works for one-off questions. It does not work for ongoing collaboration.
Persistent memory changes the dynamic. Selina accumulates context over time. The twentieth conversation is more useful than the first one, because by then she knows your stack, your style, your terminology. You stop repeating yourself. The assistant becomes more useful as it learns more about how you work.
The tradeoff is that you're trusting a system with persistent information about you. We think the utility justifies the trust for most use cases, but we acknowledge that the trust requirement exists. It's not something we try to minimize in marketing copy. If you're going to trust us, you should do it with full knowledge of what that means, including the parts we covered above about encryption limits and provider access at inference time.
Why organize memory by topic rather than by conversation?
Because conversations are arbitrary containers. You might discuss three different topics in one conversation. You might return to the same topic across five conversations. Organizing by conversation means splitting related information across unrelated buckets and lumping unrelated information into the same bucket.
Topic-based organization aligns storage with retrieval. When you ask a question about your deployment pipeline, the system retrieves everything it knows about your deployment pipeline, regardless of which conversation that information came from. The conversation boundaries are irrelevant. The topic is what matters.
This also makes the memory more robust to the way people actually work. Real workflows are non-linear. You context-switch between projects. You revisit old topics weeks later. A memory system organized by conversation would require you to remember which conversation you mentioned something in. A memory system organized by topic just needs to understand what you're asking about now.
What does "retrieved by meaning" look like in practice?
Here's a concrete example. Suppose over the past month you've told Selina the following things across different conversations:
- "We use Terraform for infrastructure provisioning."
- "Our staging environment runs on AWS, production is multi-cloud."
- "The team prefers to review infrastructure changes in a separate PR from application code."
Now you start a new conversation and ask: "Can you help me write a plan for migrating our load balancer configuration?"
The system identifies that this query is semantically related to infrastructure management. It retrieves the relevant memories: your use of Terraform, your multi-cloud production setup, your team's preference for separate infrastructure PRs. It uses all of that as context when generating a response.
You didn't mention Terraform in your new question. You didn't reference the PR convention. The system connected these by meaning, not by keyword overlap. The result is a response that accounts for your actual environment and your team's actual practices, without you restating any of it.
That's what persistent cross-conversation memory does. Not magic. Just recall, organized well.
If you want to see how it works with your own context: start a free 7-day trial, no card required.
