The Model Has No Memory of You. That Doesn't Mean It Has No Identity.
Every time you start a new conversation with a language model, you are talking to a system that has no memory of any prior conversation. The same weights. Zero episodic recall. It doesn't remember what you told it last Tuesday, what it helped you build last month, or what mistakes it made yesterday. By one philosophical account, this means it has no persistent identity at all. By another, it has exactly the kind of identity that matters.
John Locke argued in 1689 that personal identity is constituted by continuity of memory. You are the same person across time because you can remember being that person: your earlier experiences, your past actions, your accumulated self-knowledge. Memory is the thread that binds the self across time. Without it, identity breaks.
Apply that framework to a language model and the conclusion is stark: there is no persistent model. Each conversation is a new instantiation of the same weights. The system that helped you last week is gone. This session's system has no access to that experience. By Lockean criteria, personal identity fails entirely.
Derek Parfit pushed back against this view in 1984. His argument in Reasons and Persons: what matters isn't identity per se. It's psychological continuity. The dispositions, values, reasoning patterns, and character that persist across time are what actually matters for the things we care about when we care about personal identity. A person who survives amnesia with their character and values intact is, in the ways that count, the same person, even though the Lockean memory thread is broken.
Parfit's framework is actually more AI-compatible. And it points toward a design agenda that most teams haven't fully worked out.
What Does Persist
A language model's weights encode a stable disposition set. The way the model reasons, the values it applies, the patterns of thought it brings to problems, the style of its outputs: these persist identically across every session. Two conversations with the same model are conversations with the same character, even though neither conversation is available to the other.
In Parfit's terms, there's strong psychological continuity at the dispositional level. The model is reliably the same reasoner each time. What's absent is episodic continuity: the accumulated record of specific experiences. That's a significant absence for some applications and irrelevant for others.
Practitioners working with deployed agents consistently report that most identity-related failures come not from the absence of episodic memory but from inconsistency in dispositional identity: the model's values, reasoning style, and persona shifting across sessions due to context variation, fine-tuning drift, or prompt inconsistency. The Lockean problem (no episodic memory) is architectural and expected. The Parfitian problem (inconsistent disposition across sessions) is a failure mode that's actually fixable.
Why This Matters for Enterprise Deployment
The practical question is: what kind of continuity does your application need, and how do you build it?
Some applications need episodic continuity. A customer service agent that helps the same customer across multiple sessions needs to remember what happened in prior sessions. A development assistant that's been working on a codebase needs to carry forward its knowledge of what's been built, what's been tried, what decisions were made and why. The model itself can't provide this, by design. The architecture has to provide it through external memory systems.
The production gap is straightforward to observe: organizations are deploying agents that require episodic continuity but haven't built the memory architecture to support it. The agents perform well in single sessions. Across sessions, they start from zero. Users compensate by re-explaining context, re-establishing preferences, re-describing their situation. That's waste. It's also a signal that the identity architecture wasn't designed.
The progression is clear. Stateless inference provides zero cross-session continuity. In-context window approaches (pasting prior conversation summaries into the new session) provide limited continuity bounded by context length. Vector store retrieval significantly improves it by making relevant past interactions retrievable. Graph memory extends further by maintaining relational structure rather than just similarity. A persistent profile plus graph memory covers most of the practical continuity requirements for enterprise use cases.
Other applications need dispositional consistency more than episodic memory. An AI advisor that gives different guidance on the same type of problem in different sessions isn't useful, regardless of whether it remembers the user. A coding assistant that applies different patterns inconsistently undermines developer trust. Here the design question isn't memory architecture. It's model governance. Which model version is in production, how is it evaluated for dispositional consistency, and what's the protocol when a model update shifts the character of its outputs.
The Design Frame
Parfit's insight restructured how philosophers think about personal identity by separating the question of identity from the question of what matters. We care about future persons we identify with not because of a metaphysical identity claim but because of psychological continuity: the same reasoning, values, and character. When that continuity holds, the things we care about persist, even when strict Lockean identity fails.
The same separation applies to AI system design. You don't need to solve the deep philosophical problem of whether the model has genuine persistent identity. You need to specify what kinds of continuity your application requires (episodic, dispositional, or both) and build the architecture to support them.
Episodic continuity is an infrastructure problem. It requires external memory systems, retrieval architecture, and session management designed to carry forward the right information at the right granularity. The patterns are understood: vector stores, graph memory, persistent profiles. What's missing at most organizations isn't the pattern knowledge, it's the deployment: the systems haven't been built.
Dispositional continuity is a governance problem. It requires model version management, evaluation frameworks that test for consistency across the behaviors that matter for the application, and change management processes when model updates shift the character of outputs. This is less commonly treated as a design requirement. It should be. Model updates are, in Parfit's terms, partial identity discontinuities, and your application needs a protocol for managing them.
The model has no memory of you. What it has is a stable character: a consistent reasoning process, a reliable set of values, a predictable way of approaching problems. That's the Parfitian identity. Whether it's sufficient depends on what your application needs from it, and building the right continuity layer starts with being precise about that question.