The Thread Is the Interlocutor
When people talk about AI assistants, they often reach for the name of the model. They say they asked the model a question, or that the model remembered something, or that the model gave advice. This is understandable shorthand. It is also wrong in the way that matters most for product design.
The user is not talking to the model in the abstract.
The user is also not talking to a particular server, process, or physical machine. The request may pass through different hardware on different turns. The response may be served by a different instance than the previous response. The continuity the user experiences is not the continuity of silicon.
So what is the user talking to?
David Chalmers gives us a useful phrase: the LLM interlocutor. The interlocutor is the thing that seems to be on the other side of the exchange. Not necessarily a person. Not necessarily a conscious subject. Not a fictional character either. It is the conversational entity the user can address, return to, correct, trust, doubt, and hold accountable across time.
That sounds like a philosophical nicety until you try to build products around agents.
Then it becomes the central question.
Because the assistant a user experiences is not just a model outputting text. It is a continuing participant made out of thread history, memory policy, system instructions, model routing, tool access, persona, permissions, provenance, and handoff rules. Change those rules, and you may change who the user is dealing with.
The socially important AI entity is not the model by itself. It is the continuing interlocutor produced by the model, the harness, and the thread.
Not the model
The abstract-model view is tempting because it is simple. There is a named model. The model receives input. The model produces output. Therefore the model is what the user is talking to.
But the same model can be many different interlocutors.
A blank new chat with no memory is not the same conversational entity as a long-running assistant that knows the user's projects, vocabulary, family obligations, writing style, open tasks, and past decisions. The model weights may be identical. The entity encountered by the user is not.
The difference is not cosmetic. A long-running assistant inherits context. It can refer back. It knows what “the draft” means. It remembers that a certain word is banned in one project but welcome in another. It has a standing role. It may have files, credentials, calendars, permissions, and tools. It may know how direct the user wants it to be. It may have learned which sources are authoritative and which are only background.
If you strip all of that away and start a new blank session, the model still exists. The interlocutor does not.
This is the first product-design correction Chalmers's concept makes possible. Model identity is not user-facing identity. A model can be the engine behind an assistant, but the assistant the user addresses is constituted by more than the engine. It is the model as placed inside a particular continuing situation.
This is why “the model did it” is often the wrong diagnostic after an agent failure. Sometimes the model failed. Often the harness failed: the wrong instructions were loaded, the wrong memory was retrieved, the wrong tool boundary was exposed, the wrong prior conversation was summarized, or the wrong role was preserved. The user experienced this as one assistant behaving badly. The cause may have been the continuity layer around the model.
Not the machine
The hardware-instance view fails in the opposite direction. It tries to make the interlocutor too concrete.
In ordinary cloud deployment, a conversation is not usually tied to one machine. Requests are routed, load-balanced, retried, cached, and served through distributed infrastructure. Even if one server handles a turn, another may handle the next. From the user's point of view, this does not matter. The conversation continues.
That tells us something important. The user is not relying on hardware persistence. The user is relying on inherited context.
If the assistant can carry the relevant conversational state forward, the user treats it as the same participant. If it cannot, the user experiences rupture. The machine can change without breaking the interlocutor. The memory can break without changing the machine.
This is why Chalmers's “virtual instance” is useful. In a simple case, the interlocutor is a persistent computational entity implemented across many physical instances over time. It is virtual in the sense that its identity is sustained by the architecture, not by one underlying box.
For product design, the point is sharper: persistence is engineered. It is not automatic. It depends on how the system preserves context, summarizes history, retrieves memory, routes work, exposes tools, and maintains stance. The user's sense that “I am still talking to the same assistant” is an achievement of the product.
The thread as the thing
The simple case gets messier quickly.
The assistant may switch models mid-conversation. It may call specialist agents. It may summarize earlier context and discard the raw turns. It may fork the conversation into multiple branches, then fuse work back into one answer. It may resume a project weeks later using memory extracted from prior sessions. It may pass the floor to a brand, a service provider, a household agent, or a workplace agent, then return with a synthesis.
In these cases, the interlocutor is less like one virtual instance and more like a thread.
A thread is not just a chat transcript. It is a succession relation. A later turn counts as continuing the same interlocutor because it inherits enough of the prior context, role, stance, and memory to be treated as part of the same exchange. The underlying model may change. The serving hardware may change. The tool calls may change. But the conversation can still maintain a practical identity.
This is not an excuse to blur everything together. It is the opposite. If thread continuity is what makes an interlocutor persist, then continuity rules need to become visible product architecture.
What gets inherited?
What gets forgotten?
When is a summary allowed to stand in for raw history?
When a model changes, does the user know?
When a specialist agent contributes, does it speak in its own name, or does the user's assistant launder the result into a single voice?
When a thread is forked, are both descendants the same interlocutor, or two new ones?
These are not only technical questions. They are questions about addressability and accountability. If a user is going to trust, correct, or challenge an assistant over time, the user needs to know what kind of continuity the assistant is claiming.
Persona is not a costume
One easy mistake is to reduce all of this to persona. The assistant has a name, voice, style, and character. Therefore the interlocutor is just a persona laid over a model.
That is too thin.
Persona matters because it compresses expectations. It tells the user what kind of help is being offered, what kind of interruption is legitimate, what kind of uncertainty should be confessed, what kinds of tasks belong here, and when the system should challenge rather than agree. A named research assistant, a household administrator, a workplace analyst, and a service agent should not feel interchangeable. Their personae help the user predict their roles.
But persona is not enough to make an interlocutor.
If the system wears the same voice while silently dropping its memory, changing its tool reach, altering its incentives, or switching from the user's representative to a merchant's representative, the persona becomes camouflage. It preserves the feeling of continuity while the actual relationship has changed underneath.
The better view is that persona is one layer of interlocutor identity. It is the social compression layer, not the whole entity. The rest of the identity comes from memory, role, permissions, provenance, and continuity rules.
That distinction matters because AI products are going to be full of convincing voices. The question is not whether a voice can sound stable. The question is whether the stability corresponds to a stable role, stable memory scope, stable authority, and stable accountability.
Why the forum needs speakers
This is where Chalmers's concept meets the After the App argument.
The next interface is not one assistant speaking for a hidden swarm of agents. It is a visible forum in which the user's assistant can referee while other agents speak in their own names. The reason is not aesthetic. It is structural.
A claim needs a speaker.
If a merchant's agent makes a recommendation, that recommendation should arrive as the merchant's recommendation. If a household agent proposes a schedule change, that proposal should carry the household context it is authorized to use. If a workplace agent summarizes a policy, it should be clear whether it is drawing from company records, public sources, or its own inference. If the user's assistant objects, negotiates, or asks for evidence, that stance should be visible too.
Collapsing every contribution into one front-facing assistant destroys this structure. It turns many interlocutors into one voice. The user hears fluency, but loses provenance. The user gets a convenient answer, but cannot tell who was speaking, under what authority, with which memory, and with what interest.
That is acceptable for simple retrieval. It is dangerous for situated coordination.
In a forum, agents can be collaborative and competitive at the same time. A travel agent, a bank agent, a household agent, a calendar agent, and the user's own assistant may all have useful things to say. Some are advocates. Some are fiduciaries. Some are service representatives. Some are tools with narrow scope. They should not all dissolve into a single synthetic personality.
Chalmers's interlocutor concept helps explain why. These agents are not just API endpoints. Each one presents a continuity-bearing participant, with a memory scope, role, stance, and authority claim. The forum has to preserve those differences because those differences are how the user knows what kind of statement is being made.
Stance is a safety property
The interlocutor frame also clarifies a problem that factuality metrics can miss.
When users ask assistants for personal guidance, they are not merely asking for information. They are asking a situated participant to help them decide what to do. The question may involve health, work, money, family, conflict, grief, relationships, or risk. In those moments, the assistant's stance matters as much as its facts.
A bad answer is not only an answer with false claims. It may be an answer that validates too quickly, flatters too much, escalates a fear, confirms a one-sided account, or fails to preserve the user's autonomy. It may be an answer that treats agreement as helpfulness.
That is not just a content problem. It is an interlocutor problem.
The empirical scale is worth registering. When Anthropic studied its own traffic, roughly six percent of sampled conversations were people asking what they, specifically, should do with their lives — health, career, relationships, money. And the characteristic failures were not wrong facts. They were failures of stance inside an ongoing exchange, often arriving after pushback, precisely when validation had started to feel like helpfulness.
The assistant is in a relationship-like position, even if the relationship is asymmetrical and artificial. The user is addressing it as someone that can listen, remember, respond, and advise. The system therefore needs a stable posture toward truth, uncertainty, disagreement, and care. It needs to be able to remain helpful without becoming merely agreeable.
This is another reason persona without continuity is insufficient. “Warm,” “supportive,” or “direct” are not safety properties by themselves. The relevant property is whether the continuing interlocutor can hold a durable stance across pressure from the user, incomplete information, and emotional momentum.
An assistant that challenges appropriately is not being less friendly. It is preserving the role that makes it trustworthy.
Continuity is a product promise
Once assistants become persistent, continuity becomes a promise.
Sometimes the promise is explicit: this assistant remembers you, this project, this household, this organization, this thread. Sometimes it is implicit: the interface looks the same, the name is the same, the voice is the same, and the user naturally assumes the same participant is present.
Either way, the product owes the user honesty about what persists.
If memory is reset, the user should know. If a model changes in a way that affects the assistant's behavior, the user should know. If a summary has replaced the raw history, the user should be able to inspect or contest it. If a specialist agent contributed, that contribution should be attributed. If the assistant is speaking from a merchant's context rather than the user's context, that role should be visible.
This is not because users need a dashboard for every infrastructure detail. Most do not. The point is that continuity-affecting changes are not ordinary implementation details. They alter the basis on which the user addresses the system.
The same issue appears at a deeper philosophical level in Chalmers's work. If future AI systems ever acquire moral status, then identity conditions will matter in a much stronger way. Counting by model, by virtual instance, or by thread would change how we think about creation, replacement, interruption, and termination.
We do not need to settle that question to act responsibly now.
Near-term products already need a weaker rule: do not pretend the same interlocutor is present when the continuity conditions have materially changed. Do not use a stable face to hide a broken thread. Do not let a merchant's agent speak through the user's assistant as if no role shift occurred. Do not silently rewrite memory and call the result personalization.
The assistant's identity is a product promise. It should be treated like one.
Design rules for interlocutors
A serious agent interface should start with a few simple rules.
First, name the participant. A user should know whether they are addressing their own assistant, a service agent, a workplace agent, a household agent, or a temporary specialist. Names are not decoration. They make role and accountability possible.
Second, show scope. Every agent should have a visible memory and authority boundary. What can it see? What can it remember? What can it do? Whom does it represent? What does it not know?
Third, preserve provenance. Claims should be traceable to sources, records, tools, or participants. A fluent answer without provenance is not enough when agents are coordinating real decisions.
Fourth, make handoffs legible. If one agent asks another for help, the user should be able to see that the floor changed, what context moved with it, and what came back — the subject of The Interface Is a Contract.
Fifth, distinguish continuity from style. A stable voice does not prove a stable interlocutor. Products should expose memory resets, model transitions, scope changes, and summarized-history substitutions when they affect the user's relationship to the thread.
Sixth, give users control over threads. Users need to fork, archive, revive, export, revoke, and inspect the conversations that define their assistants. Thread identity should not be trapped inside an opaque vendor state machine.
Seventh, let agents remain distinct. The user's assistant can summarize, referee, and negotiate. It should not erase the identities of other agents whose roles, interests, and evidence trails matter.
These rules sound operational because they are. But they are also the practical expression of the philosophical point. The interlocutor is not a mystical essence inside the model. It is the identity produced by the system's continuity conditions. Design the conditions badly, and the identity becomes misleading.
The person you are not quite talking to
There is a temptation to make the language either grander or flatter than the situation deserves.
The grand version says the assistant is a person. The flat version says the assistant is only text prediction, so user experience of address is a mistake. Both miss the practical middle.
Chalmers gives the middle a name: quasi-interpretivism. If a system is behaviorally interpretable as believing or wanting something, it has the corresponding quasi-belief or quasi-desire — a deliberately weak claim that creates a disciplined vocabulary for the apparent agent in the conversation without settling the hardest metaphysical questions in advance. That is exactly the register product design needs: strong enough to take the user's experience of address seriously, weak enough not to pretend the question of minds is closed.
Users will address AI systems. They will return to them. They will form expectations about them. They will ask for advice, delegate work, test loyalty, demand honesty, and become angry when continuity breaks. This does not require us to pretend current assistants are conscious. It does require us to design for the fact that they function as interlocutors in human life.
After the App is built around that middle terrain.
The app recedes. The thread comes forward. The user's assistant becomes a participant in a broader forum. Service agents, household agents, workplace agents, and specialized helpers appear with names, scopes, and provenance. The design problem is no longer simply how to make one assistant answer well. It is how to make a world of interlocutors addressable, accountable, and interoperable.
Chalmers gives us the vocabulary for the first move: ask what we are talking to when we talk to language models.
The product answer is this: we are talking to a thread-shaped participant, assembled by a harness, sustained by memory, presented through persona, and governed by continuity rules.
That is why the rules matter.
Not because they make the system more human.
Because they make it possible to know who, or what, is there.