One person, many handles
The platform separates the customer (a person) from their identities (one per channel handle) and from leads (a conversation record).Merges are conservative
Identities merge only on a verified contact detail: a phone number the platform actually received a message from, or a confirmed email. Never on a name, never on similarity, never probabilistically.This is deliberate. A wrong merge hands one customer another customer’s
conversation and order history — the kind of mistake that cannot be
apologised away.
buyer_ref
Your tools receive a stable reference for the person in the conversation. Use
it as the key for their cart, their tier and their history.
What you should not ask for
Do not require a phone number or email as a tool argument to identify someone. The platform already knows who is talking; asking again makes the assistant interrogate a customer it has already recognised, which reads as forgetting them.When your product has its own users
Everything above describes a buyer — somebody who arrived through a channel and whom the platform recognises across handles. That is the right model when the assistant faces the public. It is the wrong model when the assistant faces your own users: learners, staff, account managers, parents. Those people are already identified by your product before they ever reach a conversation, and they have records that must not be readable by whoever is standing next to them. For that, the platform has principals — registered by your id, carrying roles and explicit grants, with retrieval filtered to what each one may see.End users
Principals, session tokens, and asking about somebody else.