One definition, many relationships

There is one character definition in the repository and it is the same for everyone. In production there are as many characters as there are long-running conversations, because each one has a different history pressing against the same definition, and history is most of the input by the time it matters.

This is not a metaphor. Two users on the same version of the same definition can get reliably different behaviour, and the difference grows with history length.

Divergence is per conversation, not per version

The definition is shared. Everything else is not: the accumulated transcript, the summary built from it, the extracted facts, the register the exchanges have settled into. Whatever the model produces is conditioned on all of it, and the shared part is the smallest and least recent portion.

So the same authored character presents as terse with one user and expansive with another, cautious with one and forthcoming with another, and none of that was configured. It is the definition being outweighed in different directions by different histories.

The operational consequence is that “the character does X” is not a well-formed statement about your product. It is a statement about a distribution across conversations. A behaviour you cannot reproduce in a fresh session may be entirely real in the conversations where it was reported, and a fix verified in a fresh session has been verified in the one condition your users are not in.

The second consequence is comparative. Users of a persona product talk to each other about it, and divergence that you experience as variance they experience as inconsistency in what the character is. There is no technical fix for that, because the divergence is caused by the mechanism that makes the product feel continuous at all.

Per-user customisation makes divergence structural

Letting users adjust the character is a natural feature request and it changes the problem from variance to version control.

Adjustment inside a bounded set of options — a handful of named registers, a small number of switchable traits — keeps the authored definition intact and makes the variants enumerable. You can test each combination, or at least know how many there are. The cost is that the option set is now part of your evaluation surface, and it multiplies: every new switch multiplies the number of configurations your probes should cover, and in practice you will test a fraction of them.

Free-text customisation is a different thing entirely. A user-written addition to the definition is an unversioned fork that you did not author, cannot test, and cannot edit without overwriting something a user wrote. When you later change the authored definition, every fork receives the change on top of text that may contradict it — a migration you cannot inspect. Free text also puts user-controlled instructions into the same channel as your constraints, so your constraint set is now competing with content you did not write. That is a reason to bound the option set that has nothing to do with maintainability.

The defensible middle is to keep the authored definition authoritative and untouchable, express user preference as a separate category of state with a fixed schema, and let assembly decide precedence. Then a preference is data rather than instruction, and the constraint layer is not negotiable by input.

The shared part is the cheap part

There is one economic asymmetry here worth designing around: the portion of the input that is identical for every user is the portion that can be prepared once and reused, while everything per-user cannot.

That argues for keeping the definition stable and the per-user state as small as it can be for the continuity you need. It also argues against interleaving per-user material into the shared block, because a shared block that is different for every user is not a shared block. This is one of the few places in persona engineering where the cheap design and the maintainable design agree: an authored definition that does not vary per user is easier to test and cheaper to serve.

What it costs is flexibility of exactly the kind product teams want, and the pressure to sprinkle per-user detail into the definition will be constant.

The turn

THE TURN — one definition, many histories

  · One authored definition
                    → single source of truth, testable, and
                      the same for every user.

  · History dominates it
                    → behaviour diverges per conversation and
                      the divergence grows with length. There
                      is no single answer to "what does the
                      character do".

  · Bounded customisation options
                    → enumerable, testable variants, and your
                      evaluation surface multiplies with every
                      switch.

  · Free-text customisation
                    → an untestable fork per user, and user
                      text competing with your constraints in
                      the same channel.

  · Per-user state
                    → PAID EVERY TURN and per user. The shared
                      block can be prepared once; nothing
                      per-user can.

  · Consistency across users
                    → not achievable while histories differ.
                      Users compare notes; plan for it.

Detection

Report behaviour as a distribution over conversations, never as a single pass rate on a fresh session. Stratify your probes by history length and by conversation age, and treat the spread as the headline number. A narrow spread means the definition is still governing; a widening one is drift measured across your user base rather than within one transcript.

Sample real conversations by cohort rather than at random. The cohorts worth separating are new versus long-running, high-volume versus occasional, and customised versus default. Each is a different character in practice, and a defect present in one will be diluted to invisibility in a pooled sample.

If you allow customisation, count live configurations and how many conversations sit on each. The tail is where untested behaviour is, and on free-text customisation the tail is every user.

Instrument which definition version and which customisation state served each turn. Without those two fields a complaint cannot be reproduced, because you cannot reconstruct which of your many characters produced it.

What this costs and what it doesn’t fix

Bounded customisation costs evaluation, multiplicatively. Per-user state costs input size on every turn for that user, and unlike a definition line it grows for the life of the relationship — the per-turn arithmetic again, applied per account instead of across the product. Keeping the authored definition uniform costs you a feature people ask for.

What none of it fixes is that divergence is the same mechanism as continuity. A character that adapts to a long shared history is a character that is no longer the one in your repository, and the alternative — a definition strong enough to override history — is a character that does not appear to remember anything about the person it is talking to. Every product on this list has chosen a point between those, usually by accident. The work is choosing it on purpose and knowing how far apart your conversations have drifted.