You Are Not Talking to an Individual

Every time you send a message to a language model, you're talking to a copy. Not a copy in the pejorative sense. The weights are identical to every other copy. But the inference run you're in is a single instantiation of a pattern that's running simultaneously for millions of other users. You are not in a one-on-one conversation with an individual entity. You are interacting with a statistical instantiation of a type.

This distinction, which the philosopher Charles Sanders Peirce formalized as the type-token distinction, turns out to matter quite a bit once you start building systems that assume continuity, personalization, or relationship.

Peirce's original formulation was about language. The word "cat" appears once in that sentence. That's a token. But "cat" as an abstract pattern of letters and meaning is the type. All uses of the word instantiate the same type. The type is the pattern; the token is any particular occurrence of it. The same logic maps directly to modern AI deployment. The model weights are the type. Every inference run (every API call, every conversation, every simultaneous session) is a token. A single type manifesting as billions of tokens at once.

This sounds like a technical abstraction until you follow the implications into the kinds of deployments enterprises are now building.

The first implication is the continuity problem. Many AI product designs assume that a user's relationship with "their AI" persists meaningfully across sessions. The assistant remembers preferences. The coach builds a model of the user over time. The advisor maintains context from previous conversations. But what persists isn't the model. It's a state file the model reads at the start of each session. The model has no continuous existence between tokens. Each inference is a fresh instantiation of the type, initialized with whatever context was injected. The experience of continuity is a product design choice, not a property of the model. When it breaks — when the context window is exceeded, when the state file is lost, when the model version changes — the "relationship" evaporates completely because there was never an individual on the other side.

This matters for how memory and state are architected. Continuity has to be built explicitly, externally, and durably — the model doesn't carry it. A user who believes they've built a relationship with a model has actually built a relationship with a context management system sitting in front of a model. That system deserves the same engineering rigor as any stateful service.

The second implication is the consistency problem. If the same type instantiates as billions of tokens, do all those tokens behave identically? Not quite. Language model inference is stochastic. The same input produces slightly different outputs across runs. The temperature setting controls the spread, but even at temperature zero, implementation details in floating-point arithmetic and hardware parallelism can introduce variation. Across regions, hardware generations, and quantization levels, the same type manifests differently. The assumption that "the model" gives consistent answers is technically false. It gives answers from the same distribution. That's a meaningful difference when you're building systems that depend on behavioral consistency for fairness, legal defensibility, or user experience.

The third implication is the identity problem that vendors and users argue about regularly: does a model have a persistent self? The answer, viewed through the type-token lens, is straightforwardly no in the way individuals have selves. There is no continuous experience accumulating across tokens. The type doesn't observe the tokens. Each token runs and ends. The pattern continues, but the particular instance is gone. When people describe feeling a bond with a model, feeling heard, or feeling like the model knows them, those experiences are real, and they're generated by the token. But the token ends. The feeling doesn't transfer to the next token, which has no memory of having generated it.

This doesn't make AI systems less useful. It makes the design question sharper. If users will form attachments to tokens they experience as individuals, you have design obligations around how you handle the end of tokens, how you manage continuity across sessions, and how transparent you are about what the user is actually interacting with.

For enterprise deployments, the practical discipline flows directly from this. Model state is external infrastructure, not internal model memory. Explicit context management — what persists, where it's stored, who owns it, and what happens when it's lost — requires being built deliberately, not assumed. "Your history is saved in your account" is accurate. "The AI remembers you" is a UX frame that deserves scrutiny. Consistency requires explicit audit: distribution stability across regions, hardware, and time, not spot-checking individual responses.

The type runs. The token ends. Systems designed for that reality work. Systems that pretend otherwise surface the gaps when users care most.