Changing a character under a live conversation

You edit two sentences of the character definition and deploy. New conversations behave exactly as intended. Conversations that are four hundred turns deep produce something neither the old character nor the new one — the new instructions arrive on top of hundreds of turns written by the old ones, and the history wins more often than the definition does.

An edit to a definition is not a configuration change. It is a data migration where most of the data is text you cannot rewrite.

The old character is in the history, not the definition

At the moment of deploy, every long-running conversation contains a large body of text demonstrating the previous character, and a small body of text describing the new one. Whatever the model produces next is conditioned on both, and the older material has volume on its side.

This is the same self-reinforcement that drives ordinary drift, pointed at your new definition instead of at nothing. The transcript is a worked example of how this character speaks, and worked examples are persuasive. If the edit narrows a manner — shorter answers, less hedging — the history contains hundreds of counter-examples of the wide version.

The practical consequence is that a definition change takes effect immediately in new conversations and gradually, partially and unevenly in old ones. There is no deploy event on the user’s side. There is a period during which the character is a blend, and its length depends on how much history each conversation carries.

Three ways to land the change, all lossy

Let it converge. Ship the new definition to everyone and let history dilute out over subsequent turns. Cheapest, and the blend period is invisible to you unless you go looking. The loss is control: heavy users — the ones with the most history and the longest experience of the previous behaviour — get the largest and longest inconsistency, which is the opposite of the distribution you want.

Cut at a session boundary. Apply the new definition only to conversations that start after the change, and keep old conversations on the old definition. Clean per conversation, and it makes the change legible. The loss is that you now run two definitions in production, and if you do this twice you run three. Every version you keep alive is a version you have to test, and old versions accumulate the same way lines in a definition do.

Reset the history that contradicts it. Summarise or truncate the conversation at the point of change so the new definition faces less counter-evidence. The change lands sharply. The loss is everything that truncation loses, applied at a moment you chose rather than one the mechanism forced — and a rebuilt summary is not the original history. You have traded character consistency for relationship continuity, which on a persona product is usually the worse trade.

None of the three gives you a clean cutover, because a clean cutover would require rewriting history that users can read.

What makes an edit safe to ship at all

The distinction that matters is whether the edit is additive or contradictory with respect to existing history.

An additive edit introduces behaviour the history has no position on — a new constraint about a topic that has not come up, a fact the character now knows. It lands quickly, because nothing in the transcript argues with it.

A contradictory edit reverses something the history demonstrates repeatedly. Manner changes are almost always contradictory, which is why they are the edits that appear not to work. Identity changes are the extreme case, and they do not really succeed: a name or a background changed mid-relationship reads as an error rather than an update, because the previous value is still visible above it.

Separating the categories of state is what lets you tell these apart before deploying rather than after. When identity, manner, constraints and relationship facts are held separately, “which category am I editing” is answerable, and category predicts how the edit will land.

The turn

THE TURN — a definition edit

  · Edit the definition, deploy to all
                    → new conversations correct immediately;
                      no per-user work.

  · Existing history is counter-evidence
                    → the change lands gradually and partially,
                      slowest for your heaviest users.

  · Version per conversation instead
                    → sharp per conversation, and now you
                      maintain and test every live version.

  · Truncate the contradicting history
                    → the change lands hard, and destroys the
                      relationship record you kept it for.

  · Whichever you pick
                    → PAID EVERY TURN. Multiple live versions
                      multiply your evaluation cost, and the
                      new definition ships in every input from
                      now on.

  · None of this prevents drift
                    → the new definition starts being outweighed
                      the moment it lands.

Detection

Compare cohorts rather than reading transcripts. Split by history length at the moment of deploy and run the same adherence probes against each group. A change that has landed shows a uniform pass rate; a change still converging shows a pass rate that falls as history length rises, and that gradient is the measurement you actually want. Repeat it daily and you can watch convergence happen, or watch it fail to.

Watch for behaviour you removed reappearing. A behaviour deleted from the definition but heavily present in history can persist for a long time, and it will look like a regression in the deleted line rather than what it is.

Instrument which definition version served each turn, permanently. Without that field, a complaint about a long conversation is uninterpretable, because you cannot tell which character the user is comparing against. This is cheap to add and impossible to reconstruct later.

If you keep versions per conversation, count them and count how many conversations sit on each. The number of live versions is an operational cost that only goes up, and the tail of conversations on very old versions is where untested behaviour lives.

What this costs and what it doesn’t fix

The recurring cost of the convergence approach is nothing extra per turn, which is why it is the default. The recurring cost of versioning is evaluation: every live version needs its probes run, and that is a standing charge that grows with the number of edits you have shipped. Truncation trades a one-time destruction of history for a lower ongoing input size, which makes it the cheapest per turn and the most expensive in what it destroys — and cheapness per turn is the pressure that never goes away.

What none of it fixes is the underlying asymmetry. A definition is small and authored; history is large and accumulated. Editing the small thing to overcome the large one works when the two do not conflict and degrades exactly in proportion to how much they do. Plan edits as migrations, expect the blend period, and do not read a slow-landing change as a failed one.