A persona is state, not a personality

The character is charming in a demo and unmaintainable in production. You want to soften one behaviour without losing the voice, and there is no way to do that, because the voice and the behaviour and everything the user has ever told it are in the same lump of text.

The problem is not that the persona is badly written. It is that four different kinds of state were stored as one kind.

Four categories, four lifecycles

Separate them and most persona maintenance problems become ordinary problems.

Identity. Who the character is: name, background, situation, the handful of facts that are true regardless of who is talking to it. Authored once, changed rarely, identical for every user.

Manner. How it speaks: register, sentence length, warmth, humour, what it does with questions, whether it uses the user’s name. Authored, tuned frequently, and the part users notice first when it changes. Also identical across users.

Constraints. What it will and will not do, what it declines, what it stays away from. Authored, revised under pressure — support tickets, policy changes, an incident — and the category with the least tolerance for accident.

Relationship facts. What this particular user has said: their name, their job, what they told it on Tuesday, the running joke. Accumulated rather than authored, unique per user, and the only one of the four that grows without bound.

Those four have nothing in common operationally. Three are content you own and one is data your users generate. Three are versionable and one is not. Three are the same for everybody and one is the reason two users describe the same character differently.

What conflating them costs

You cannot version the character. If manner and relationship facts live in one structure, there is no “version 4 of the character” to roll forward or back — every user has a different one. A change you want to ship to everybody and a fact one user mentioned once are the same kind of object, so neither can be managed properly.

You cannot fix a bad fact. Relationship facts get captured wrongly: a passing hypothetical stored as biography, a joke stored as a preference, a name misheard. If it is embedded in a blob of persona text, correcting it means editing prose. If it is a record, it is a record you can delete.

You cannot A/B test. Testing two manners requires manner to be separable from everything a user has accumulated. Conflated, an experiment either discards user history or does not run.

You cannot audit constraints. The one category with real consequences attached becomes unreviewable because it is interleaved with everything else. Nobody can answer “what is this character currently instructed not to do” by reading a document, which is a bad position to be in when somebody asks.

Drift becomes undiagnosable. When a character goes off, the first question is which category moved — manner drifting inside a session is a completely different problem from a constraint being outweighed. One blob gives you no way to ask. Drift has several distinct causes and telling them apart starts here.

The turn

THE TURN — persona state

  · Identity, manner, constraints and
    relationship facts held separately
                    → each gets its own lifecycle. Versioning,
                      auditing and correction become ordinary
                      operations.

  · All four as one text blob
                    → no versioning, no A/B test, no way to
                      fix a wrongly captured fact, no
                      auditable constraint list.

  · Relationship facts as records rather than
    prose
                    → correctable and deletable. Prose is
                      neither.

  · All four reassembled into every input
                    → PAID EVERY TURN. Identity, manner and
                      constraints are a fixed cost on every
                      message; relationship facts are a cost
                      that grows for the life of the account.

  · Separation on its own
                    → does not stop drift. It makes drift
                      diagnosable, which is a different
                      thing.

Constraints are not manner, and the difference bites

Worth pulling out, because it is the conflation with real consequences.

A constraint that is written as part of the voice degrades with the voice. If the instruction not to do something is embedded in a paragraph about being warm and playful, then whatever weakens the voice over a long conversation weakens the constraint by the same mechanism and at the same rate. And the voice reliably weakens over a long conversation.

Held as a separate category, a constraint can be placed differently, repeated, reinforced, or enforced by something other than the definition — a layer that does not care how the conversation has been going. Anything you actually need to hold should not depend on the character’s coherence to hold it, because character coherence is the thing that decays.

Which is the honest framing of moderation for this whole subject: filters sit outside the character precisely so their behaviour does not degrade with it. The cost is that their interventions do not sound like the character, and that seam is a design problem with no clever solution — only the choice to keep it small and handle it gracefully rather than pretending it will not happen.

Detecting the problem you already have

You can tell whether your state is conflated without reading any code.

Try to answer “what changed” for a user complaint. If you cannot say whether the manner, the constraints or the stored facts moved, they are one object.

Try to ship a manner change to existing users. If it requires touching per-user data, they are one object.

Try to list what the character is currently instructed to decline. If that means reading a persona document and interpreting it, the constraints are not a category.

Look at what a new conversation with an old account produces. If a fresh thread is noticeably different from a fresh account, relationship facts are doing more work than you thought — which is worth knowing before you try to explain what actually carries between turns.

What this costs and what it doesn’t fix

Separation costs structure: four stores instead of one, an assembly step that composes them, and a decision per turn about how much of the growing category to include. That last one is the recurring cost, and it is the one that compounds — relationship facts grow forever and every included fact is paid for on every subsequent message.

It does not make the character consistent. A perfectly separated persona still drifts across a long conversation, still loses specifics to summarisation, and still costs more per turn the longer the relationship runs. What separation buys is a system where those problems have handles: you can point at which category failed, change one without disturbing the others, and know what you are paying for each.