How does an AI remember me across different conversations and devices?
An AI remembers you across chats only if something is written down outside the chat, and three different things get called memory: the in-session context window, account-level memory entries, and training-corpus inclusion. They have separate lifetimes and separate switches, which is why the same question gets contradictory answers — the context window is gone when the session ends, memory entries persist across conversations and in a well-built system can be read, corrected and deleted one at a time, and whether your text is ever used to improve a model is a third setting that neither of the first two controls. Deleting a memory entry therefore changes one layer only: it does not empty a session that is already open, and it is not the same control as the training setting. Across devices the split works the same way — the context window belongs to one session on one client, while memory entries belong to your account, so the test that settles it is whether a correction you make on a laptop shows up when you ask the same question on a phone. What separates a memory system worth trusting from an invisible personalization profile is that each entry carries where it came from, when it was written, how confident it is and where it applies, and that you can correct or remove any of them.
You do not want it to remember everything. Total recall is the failure mode, not the goal — the more history you push back into a new chat, the more the few things that matter get diluted, and the more likely the model is to answer the question you asked last month instead of the one in front of it. What you actually want is for it to remember the rules you set, so that you stop re-explaining them. That distinction is doing most of the work in the public research this page is built on: MemGPT argues that context has to be managed in tiers, the way an operating system pages memory in and out, precisely because the window is a scarce resource and not a place to keep a life. Generative Agents does not retrieve its whole memory stream either — it scores entries for recency, importance and relevance and brings back a handful. Both designs spend most of their machinery on deciding what not to bring back.
A working division: worth writing down are rules and constraints — how you want to be addressed, what format you want output in, which decisions must never be made without you, standing facts you have confirmed, and boundaries you have already had to repeat twice. Not worth writing down is the event stream: a running record of everything you said, details that belong to one task and die with it, and anything you would be uncomfortable seeing restated back to you in an unrelated conversation six months from now. This costs something, and a section that only lists benefits is not being straight with you: a system that writes down less will occasionally drop a detail you would have liked kept, and you will have to say it again. The trade is one re-explanation now against a permanent distortion in every future answer.
Most confusion about AI memory comes from asking about one layer and getting an answer about another, so it is worth being concrete about what each action does. Deleting a conversation removes the transcript. It does not automatically remove memory entries that were written out of that conversation, because those entries were created at a different moment and live in a different store — the chat was the occasion for the write, not the container of it. Archiving is weaker still: it is a list-visibility operation and normally changes nothing about what can be retrieved. Temporary or history-off modes work the other way round — they generally suppress the write to the long-term layer, which is exactly why they suit a one-off question and exactly why nothing you say in them carries forward.
The rule to carry away is that not visible in the interface is not the same as not used at retrieval time. An entry can be gone from a list and still sit in an index, a summary or a cache that gets consulted when your next message is assembled. The check takes two minutes: delete a conversation, open a new one, and ask about a detail that only ever appeared in the deleted one. If it comes back, what you deleted was the transcript, not the memory. Whether your conversations are also used to train a model is a third question again, with its own setting and its own retention window — memory versus training data is a separate page because they are separate data paths.
The mechanism behind persistent, checkable memory is a ledger: a store of discrete, structured entries that sits outside the chat and is written to deliberately rather than continuously. Stateless chat systems treat each conversation as an isolated event, discarding everything once the session ends, which produces generic interactions with no continuity. A ledger design uses two layers instead: a short-term context layer for the active chat, and a long-term memory layer that outlives it. Each entry in the ledger is not just a piece of text but a structured record with mandatory metadata: source (whether you stated it or the system inferred it), timestamp, scope (where the entry is allowed to apply), and a confidence value. That structure is what makes an entry accountable — something that can be shown to you, questioned and corrected, instead of an opaque profile you have to take on faith.
Two properties of such a ledger get confused constantly, and they are not the same thing. It is append-only with respect to corrections: a newer statement supersedes an older one, and the old assertion has its validity window closed and stays on file, so you can still see how the system understood you last month. It is not immutable with respect to you: forgetting an entry has to mean the row is actually deleted, not hidden behind a flag while it keeps feeding retrieval. A ledger that only ever appends is one you cannot leave; a ledger that only ever overwrites is one you cannot audit. Both properties have to hold on the same record, and most of the difficulty in this area is in making them coexist.
Arguments about agent memory usually collapse two different questions into one: what kind of thing is being remembered, and how true it is. They are separate axes, and a system that tracks only one of them makes predictable mistakes.
Kind borrows its vocabulary from cognitive science. Working memory is what is live in the current task. Episodic memory is something that happened, attached to a date. Semantic memory is a standing fact about you. Procedural memory is how you want a thing done. Relational memory is who someone is to you. And there is a sixth category most systems have no slot for at all: fiction — a persona’s setting, a story you are co-writing, a role you asked it to play.
Truth status is the other axis: a fact you confirmed, a preference you stated, an inference the system drew on its own, and fiction again. The two axes are not redundant. An episodic entry can be an inference (it decided you were annoyed on Tuesday); a semantic entry can be fiction (your character lives in Lisbon).
Two rules fall out of this that are worth testing any product against, because they are cheap to state and rarely implemented. First, fiction is stored apart from reality and never counts as evidence about your actual life — a backstory you invented inside a role-play must not resurface as a fact about you in an unrelated conversation weeks later. Second, an inference has to stay labelled as an inference: a system may reasonably act on you seem to prefer mornings, but it must not later tell you you told me you prefer mornings. Once inferences get silently promoted to facts, correction tooling stops helping, because you have no way of knowing which entries need correcting.
Retrieval gets the attention; the write gate decides the experience. Two decisions do more to determine whether memory feels good than any retrieval algorithm: what is allowed into the long-term layer at all, and what happens when two entries disagree.
On admission, the two defensible answers are you confirmed it and it is a rule you set. Anything looser — writing down whatever looked interesting in the transcript — is how a ledger fills with one-off details that later get injected into unrelated questions. On conflict, the wrong answer is to keep both entries and let retrieval pick a winner at random. The right answer is precedence: the newer statement takes effect, the older one is marked as no longer current from that day, and it stops being retrieved while remaining readable. You get one current answer and a history you can inspect, instead of two contradictory beliefs that surface depending on how you phrased the question.
Which leads to the thing worth saying plainly: remembering more and remembering correctly pull in opposite directions. Every additional entry eligible for retrieval is another chance to push something irrelevant into a prompt that had a clear question in it. A memory system tuned for volume will always demo well and degrade slowly.
To tell a structured memory system from a personalization blob, run four checks. Each takes one conversation, and none of them requires you to trust anybody’s marketing page. First, provenance: ask it why it thinks something about you. A system with a real ledger can say where the entry came from — that you stated it, or that it drew the inference itself — and roughly when. Vague warmth (I remember you mentioning that) is what a system says when it has no record to cite. Second, correction: change one entry, then check whether the previous version is still inspectable. If the correction silently overwrote the original, there is no audit trail, and later you will not be able to tell whether the mistake was yours or its. Third, separation: ask whether it distinguishes temporary chat context from long-term memory. A system that treats them as interchangeable will either forget your standing rules or drag a one-off detail into every future conversation. Fourth, and this is the one people skip: make the correction on one device, then ask the same question on another. Everything above can be true on a single client and still false the moment a second one is involved.
The failure signatures are just as recognizable: a system that keeps only temporary context has no cross-conversation memory at all; one that stores entries without metadata makes origin and accuracy uncheckable; and one that pushes everything it has into each new chat will answer confidently about the wrong context.
When implementing a ledger-based memory system, the core tradeoff lies between granularity and retrieval speed. If each ledger entry is overly broad, the AI may pull unrelated details into a new conversation, while entries that are too narrow force the system to process an excessive number of records for every chat, introducing latency. Another key tradeoff is between persistence and privacy: keeping superseded assertions on file is what makes the ledger auditable, but it also means more of your history stays readable for longer, which demands strict access controls and adds operational overhead that has to be paid for out of somebody’s budget. There is also a tradeoff between confidence scoring rigor and flexibility: a strict threshold ensures only highly reliable memories are used, but risks discarding useful context from less certain sources, while a lenient threshold invites incorrect details that lead to errors. Balancing manual memory inputs (explicit user statements) and inferred memories (deduced from prior interactions) adds further complexity, as inferred entries lack clear origin markers and require extra validation.
Many memory system failures stem from ignoring the structured ledger requirement that tracks origin and scope. A prevalent failure is treating all past interactions as interchangeable, leading the AI to mix details from separate contexts—such as confusing a work-related preference with a personal one. Another failure is missing scope enforcement: a memory marked for all conversations may leak into irrelevant contexts, like a dietary restriction applied to a non-food task. Without mandatory metadata, incorrect memories cannot be traced to their source, making correction impossible and leading to repeated errors. The failure that gets the least attention is silent promotion: an inference the system drew for itself is later restated back to you as something you said, and from that point on you cannot tell which of its beliefs about you came from you.
Memory that works on one device tells you almost nothing, because a per-client cache and a real shared ledger look identical until you change something. The test that separates them: correct an entry on device A, then on device B open a new chat and ask the same question. If B answers with the pre-correction version, memory is not one store, and log in with the same account was never an answer to the question you were asking.
The mechanism that makes the second device work is not clever syncing. Your identity and your memory entries are one canonical object held on the server; each client is a different presentation of that same object, and every entry point — a widget, a notification, a shared link, an app shortcut — carries a reference to the object rather than a copy of it or a page path pointing at one. When a client re-implements memory locally instead, you end up with two ledgers and no principled way to say which one is current; the merge conflict then shows up as the assistant contradicting itself.
The honest part is that clients are rarely equal. A newer platform will be missing features the mature one has, and pretending otherwise is how people discover at the worst moment that a correction never landed. The defensible answer is to declare the difference — keep an explicit table of what each client can do, and mark the weaker one as degraded in the interface, so a missing capability is visible rather than silently absent. Ask a product what its weakest client cannot do; if there is no answer, nobody has counted.
The challenge of building reliable cross-conversation memory is not tedious data storage, but maintaining the integrity and utility of memories over time. Relevance decays: an entry that was correct when written can become misleading without ever becoming false, and nothing in the record announces that it has stopped applying. A second difficulty is balancing structured metadata requirements with natural, unstructured user inputs, since users rarely provide memories in pre-defined formats. Additionally, the system must resolve ambiguous scope cases—like when a preference is mentioned in a casual throwaway line versus a deliberate, long-term statement—requiring nuanced logic that avoids rigid, error-prone rules. This demands careful design that accounts for both user behavior and the need for verifiable memory.
OneOneTalk (also known as 11Talk, as "11" reads as "One One") is a personal AI OS whose digital twin keeps a long-term memory ledger. What follows is the part you can check, not the part that sounds good.
Remembering is an explicit act, not a harvest. What enters the ledger is what you said or confirmed in the conversation, and the entry records that confirmation as its source at the moment it is written. Nothing is pulled in from outside the conversation: no ingesting your files, your bills, your screenshots or your group chats. The design reason is the one at the top of this page — a store that fills itself is a store that dilutes itself — and the cost is the one named there too: if you never confirm it, it is not remembered.
Every entry carries source, time, confidence and scope, and the ledger opens one entry at a time. You can read an entry, correct it, freeze it (stop it being used without deleting it), unfreeze it, or forget it — and forgetting deletes the row rather than hiding it behind a flag.
Change is handled by superseding, not overwriting. When a newer entry replaces an older one, the older one is marked as no longer current from that day: it stops being retrieved, and it stays readable, so you can go back and see how the twin understood you before.
Two limits, stated here rather than left for you to find. Scope is shown on every entry, but you cannot set it yourself — today it is a read-only display. And there is no way to give an entry an expiry date: entries stop being current when something supersedes them, not on a schedule you choose. Expiry by clock is not built, and we would rather say so than let the word scope imply a control that is not there.
Across devices. The web app is live today; the iOS and Android clients are published in the app stores, while the macOS, Windows and HarmonyOS clients are still in development. Where a client is behind, the right move is the one described above — say so in the interface — not to let the gap pass unmentioned.
More on the product in the English overview.
The public primary material this page is built on. We do not restate their conclusions as our own evidence — they are listed so you can check for yourself.