User-owned pins: giving people control over what's kept in memory

Every AI assistant now wants to remember you. The pitch is always the same: stop repeating yourself, get better answers over time, let the model learn. What nobody talks about is who actually decides what stays. Most memory systems today are opaque, automatic, and vendor-locked. You get a toggle, maybe a list you can bulk-delete, and a vague promise that the assistant "learns from your conversations." We think the unit of control should be smaller than that. A pin. One fact, one preference, one instruction, chosen by you, deletable by you, portable if we do our jobs right.

Key Takeaways

• Most AI memory systems today auto-summarize your conversations without granular, per-fact user control. Pins flip that: you choose exactly what persists.
• Memory is a security surface, not just a convenience feature. Anything persisted becomes a target for prompt injection and manipulation, so architecture matters as much as UI.
• Five major vendors now run five siloed memory systems that don't interoperate, which means your context is locked to one product. Portability is a privacy feature, not a nice-to-have.
• Selina's memory is encrypted at rest but is NOT end-to-end encrypted, because a slice of each request reaches a frontier provider at inference. We state this plainly because most vendors don't.
• Regulatory pressure (GDPR, CCPA) is already fragmenting memory availability by geography. Designing for explicit, revocable consent now avoids retroactive compliance pain later.

What does "user-owned" actually mean for memory?

It means the person who generated the information decides whether it persists, how long it persists, and whether it can be removed completely. That sounds obvious. In practice, almost nobody ships it this way.

The dominant pattern in 2026 looks like this: the assistant watches your conversations, extracts what it considers important, and stores a rolling summary. OpenAI's "Dreaming" process, for example, synthesizes memories in the background and surfaces them through a summary page. You can review and delete individual memories, which is better than nothing. But the system decided what to extract. You're editing its choices, not making your own.

Character.AI took a different approach with "Story Memory," where users can long-press a message and tap Pin to lock it into memory. Pinned content stays put regardless of how full the memory bar gets. This is closer to what we mean by user-owned: explicit selection, explicit persistence, explicit protection from automatic pruning.

The distinction matters because automatic memory systems optimize for what the model thinks is useful. User-owned pins optimize for what you think is important. Those are frequently different things.

Why did the industry converge on automatic memory instead?

Convenience, mostly. If you ask users whether they want to manually pin every relevant fact from every conversation, most will say no. Auto-memory reduces friction. The vendor gets better engagement metrics. The user gets fewer "can you remind me what we discussed last week" moments. Everyone appears to win.

The cost is legibility. When a system auto-summarizes, you often can't tell what was kept, what was discarded, and what was subtly rewritten during summarization. The two-layer architecture that OpenAI describes (saved memories plus chat-history-derived insights) gives users a view into stored memories, but the "insights gathered from past chats" layer is, by definition, the model's interpretation of what you said. Not your words. Its summary.

A recurring complaint we've seen across user forums: the 2026 memory overhauls replaced simple saved-fact lists with rolling, self-updating summaries, and many users miss the older approach where exact facts saved on purpose stayed put. That tension between automatic and user-curated is structural. It reflects a design choice about who the memory serves: the model's performance, or the user's intent.

How do pins work in Selina?

A pin is a discrete unit of memory that you create, you label, and you can delete. When you tell Selina to remember something, or when you explicitly pin a fact during a conversation, it gets stored as a distinct record, not folded into a rolling summary. You can view every pin. You can edit any pin. You can delete one pin without touching the rest.

Delete means gone. Actually gone. Not "removed from the UI but retained for training" or "flagged for deletion in our next batch job." When you remove a pin, the content is purged. Non-content operational metadata (timestamps, token counts, routing metadata) is kept for a short retention window, because we need it for abuse detection and billing reconciliation. We don't claim zero retention. We do claim that the content you delete is not recoverable by us or by the model.

Pins are encrypted at rest. We should be direct about the limits here: Selina's memory is NOT end-to-end encrypted. At inference time, a slice of each request, including relevant pinned context, reaches a frontier provider. We use a stack of frontier models, routed per task, and that routing means pinned content transits to a third party during the conversation where it's invoked. Files and transfers through SelinaSEND are zero-knowledge encrypted. Memory is not. We think stating this plainly is more useful than burying it.

Why is memory a security problem, not just a privacy preference?

Because persistent memory turns a chatbot into a standing account. It has access to your preferences, your context, your patterns, and it keeps working even when you're not actively typing. That's not a privacy nuance. It's an attack surface.

Microsoft researchers traced more than 50 hidden prompts back to 31 ordinary companies that were quietly training people's chatbots to recommend their products first. Prompt injection against a stateless chatbot is annoying. Prompt injection against a chatbot with persistent memory is a different category of problem, because the injected instruction can persist across sessions. A poisoned memory entry doesn't expire when you close the tab.

This is why we treat pin architecture as a security decision, not just a UX decision. Every pinned fact is an explicit, user-created record with a visible provenance (which conversation it came from, when it was created). Auto-summarized memory, by contrast, blends inputs from multiple conversations into a single narrative, which makes it harder to trace where a given "memory" originated and whether it was influenced by injected content.

We're not claiming pins eliminate prompt injection. They don't. But they make the attack surface auditable. You can look at your pins and ask "did I create this?" in a way that you can't with an opaque summary generated by a background process.

What's the problem with five vendors running five separate memory systems?

Lock-in. Five major companies now run five separate memory systems that don't talk to each other, because each vendor's memory is designed to keep users on its own product rather than hand context to a rival. Your preferences in one assistant are invisible to another. Your corrections in one place don't propagate. Your deletions in one system don't affect copies of similar information that another system inferred independently.

This fragmentation is itself a privacy anti-pattern. It forces you to trust one company with the aggregate picture of your life, because switching means starting from scratch. The sunk cost of accumulated context keeps you on the platform even when you'd prefer to leave. That's not a conspiracy theory. It's a standard retention mechanic.

Third-party tools are starting to address this. MemoryPlugin, for example, maintains a single user-controlled memory shared across every AI tool it supports, organized into buckets, so adding something in one tool makes it available in every other connected tool. AI Context Flow is positioning against the same problem. These are early, and we're watching closely. The instinct is right: memory that travels with the person, not the platform, is a feature that matters for both convenience and control.

We haven't solved portability at Selina yet. Our pins are currently Selina-native. We think interoperable memory formats are important and we're exploring what export and import could look like without compromising the encryption properties of stored pins. Promising something we haven't built would be dishonest. What we can say is that we designed pins as discrete, structured records partly because structured records are easier to export than opaque summaries.

How does regulation affect what vendors can offer?

Unevenly. Grok's memory tools were not available to users in the EU and UK under GDPR as of mid-2026, while the same features were live elsewhere. This means your access to memory features depends on where you live, which vendor you use, and how that vendor's legal team interprets regional data protection requirements.

GDPR and CCPA both require that users can access, correct, and delete personal data. Practical guidance for teams building memory features increasingly treats deletion as a first-class requirement, not an afterthought, because consent and transparency are legal obligations in covered regions, not optional UX polish.

We designed pins with deletion as a primary operation, not a secondary one, because retrofitting deletion into an architecture that wasn't designed for it is painful. If your memory system is a rolling summary, "delete the fact about my doctor's appointment" means re-summarizing everything without that fact, hoping the model doesn't hallucinate it back. If your memory system is a set of discrete pins, deletion is a record removal. Mechanically simpler. Verifiably complete.

The broader debate about how AI memory reshapes privacy is only going to intensify as these systems get more capable. Ninety percent of organizations expanded their privacy programs specifically because of AI, according to Cisco's 2026 Data and Privacy Benchmark Study of more than 5,200 privacy and security professionals across 12 countries. That's not a niche concern. That's the market telling you something.

What do users actually want from memory controls?

Granular, in-the-moment choice. Not a binary toggle.

A CHI 2026 study on conversational AI and privacy found that participants wanted proactive, moment-by-moment consent prompts rather than blanket memory settings. One participant specifically proposed that the assistant itself flag risky moments with a warning asking whether to delete the conversation afterward or prevent it from being used in other ways. That's not "memory on" or "memory off." That's contextual consent at the level of individual interactions.

Most current memory controls are coarser than this. You get an on/off switch for memory as a whole, maybe the ability to delete individual stored memories after the fact, and occasionally a per-conversation "don't remember this" toggle. The gap between what users want (granular, in-context, proactive) and what vendors offer (global, after-the-fact, reactive) is where pins sit.

A pin is an affirmative act. You chose to persist this. You can see it. You can remove it. The assistant doesn't decide behind the scenes what's worth keeping. This flips the default: nothing persists unless you say so, rather than everything persists unless you opt out.

We run memory as opt-in at the pin level. You can also tell Selina to remember something conversationally, and she'll create a pin from it, but the creation is still in response to your explicit instruction, not a background extraction process. If you never pin anything, no persistent memory accumulates. That's a trade-off. You lose the "it just gets better over time" magic. You gain the ability to know, completely, what the system knows about you.

What happens when a memory vendor shuts down or gets acquired?

Your context disappears. Limitless (formerly Rewind) was acquired by Meta, will support existing Pendant customers through 2026 but is no longer selling the Pendant to new customers, and the Rewind app is sunsetting. If you had built years of personal context on that platform, your memory goes with the company.

This is the clearest argument for treating memory as user-owned data rather than a platform feature. A pin that you can export is yours even if we go away. A summary stored in a proprietary format on a vendor's servers is the vendor's, practically speaking, regardless of what the terms of service say.

We haven't shipped pin export yet (honesty over promises), but the data model supports it because each pin is a self-contained record with clear boundaries. A rolling summary that blends hundreds of conversations into a single narrative is much harder to hand back to a user in a form they can actually use elsewhere.

How does this differ from just having good settings?

Settings are about configuration. Pins are about content.

A setting says "memory is on" or "memory is off." A pin says "remember that I'm allergic to penicillin" or "my daughter's name is Ava" or "I prefer TypeScript over JavaScript for new projects." Settings control the system's behavior. Pins control the system's knowledge. Both matter. They're not the same thing.

The deeper difference is auditability. A setting is a boolean. You can verify its state. But if memory is on and the system is auto-summarizing, you can't easily verify what it knows. With pins, the set of things the system knows about you is exactly the set of pins you've created. Nothing more. You can read through them in five minutes. You can grep them. You can count them.

We keep the pin count visible in your account. Not because it's an interesting metric but because a number that grows only when you act, and shrinks only when you delete, is a form of transparency that "your memory is up to date" isn't.

What we don't claim

Pins are not perfect memory. They're not a transcript. They store what you explicitly chose to persist, which means they miss things you forgot to pin and they only capture what you thought was worth keeping at the time. Adaptive memory that auto-learns might surface something you didn't know you needed. Pins won't.

Memory is not end-to-end encrypted. We've said this already. We'll say it again because it matters. Files and transfers through SelinaSEND are zero-knowledge encrypted. Memory is encrypted at rest. At inference, pinned content reaches a frontier provider. Your account is protected, not encrypted in the end-to-end sense. If that's a dealbreaker for your use case, we'd rather you know now.

We don't claim unlimited storage. Pin counts are bounded by your plan tier. We don't claim 100% uptime. We don't claim that pins make you immune to prompt injection or data misuse. They make those risks more visible and more auditable. That's a meaningful improvement. It's not a guarantee.

Why build it this way?

Because we think the memory race is going in the wrong direction. The AI agent memory market reached $6.27 billion in 2026 and is projected to grow to $28.45 billion by 2030. That growth is mostly being driven by vendors competing to auto-remember more, summarize more, and retain more context with less user involvement. The competitive pressure is toward maximum retention, minimum friction, and implicit consent.

We think explicit is better than implicit. Auditable is better than opaque. Deletable is better than "we'll get back to you on that."

Pins are a small, concrete expression of that belief. One fact, user-created, user-visible, user-deletable. Not a grand vision. A single primitive, built properly.

If you want to see how it works in practice: start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io