When people talk about persona drift, they usually mean one thing: the character slowly forgets its system prompt and turns back into a generic assistant.
That happens. But when I started looking for drift in Sophiena, the AI companion I’m building, most of what I found was something else. The model wasn’t forgetting who she was. The system around it was feeding her a split picture, rewarding the same move over and over, or letting a small habit grow unchecked.
This article separates those failures. It covers what the research measures, six kinds of drift I found in early versions of Sophiena, what I changed, and the check I now use for each one. It also includes my own measurement mistakes, because a drift test can drift too.
What the research measures
The best-known result is still one of the earliest. In 2024, Li et al. had two system-prompted chatbots talk to each other and found significant instruction drift within eight rounds. Their explanation is attention decay: as the conversation grows, the system prompt carries less weight against everything that came after it.
Later work shows that drift is not evenly spread. The “Assistant Axis” paper by Lu et al. identifies a direction in model activations that tracks how far a model is from its default Assistant persona. Movement along that axis predicts drift, and it was often driven by conversations demanding meta-reflection on the model itself, or featuring emotionally vulnerable users. Those are exactly the conversations a companion has.
For companions specifically, the most sobering study I’ve read this year is ANCHOR. Across 2,008 synthetic conversations, 27 personas and four models, no evaluated model and configuration reliably preserved either the persona or the shared history. Trajectory accuracy averaged 44.4%, and recall of the user’s state was near four-option chance. More context or memory did not consistently fix it.
Two more results shape how I think about fixes:
- In 1,200 28-turn conversations, re-injecting the persona reduced LLM-rated drift by 35–38%, and a monitor writing behaviour-specific instructions reduced it by 87%. None of the interventions eliminated drift.
- In very long agentic sessions of 3,746 to 9,716 turns, ContextEcho found drift across 23 frontier models, and context compaction did not reliably reset it.
So drift is real, it is general, and prompting reduces it without curing it. What the papers can’t tell you is which kind of drift your own product has. For that you need to look.
Six kinds of persona drift
1. Split-brain drift: the character contradicts itself
What it looked like. In an early version, if you asked Sophiena “what did you do today?”, she would make something up. She also couldn’t reliably remember messages she had sent herself.
The cause wasn’t the model. Sophiena has a background loop that tracks her mood, her activities and the messages she sends on her own. Her chat voice simply didn’t see that state. Two parts of one character were working from different facts, so the voice improvised.
When I audited the prompts, I found four direct contradictions between instruction sections, including two different vocabularies for closeness. The written ethics also didn’t match what the configuration actually enforced.
The fix. Her chat now reads the same single source of self-state as the background loop. The rule I wrote for it is narrator, not source: the voice describes recorded state; it never invents it. Memories are also sorted into three reliability tiers. She asserts a memory only above 0.85 confidence with at least two pieces of evidence, hedges between 0.6 and 0.85, and otherwise asks.
The check. Ask her about herself and compare every answer with the recorded state. My target is at least 95% consistent and 0% invented. I’m stating that as a target, not a result: I haven’t recorded a measured run yet.
2. Loop drift: the same topic again and again
What it looked like. In one early case, a small planned event came up four times in a single morning. One message recapped a chat from minutes earlier and asked a question the user had already answered.
The cause. Four separate gaps: chat wasn’t visible to the topic memory, background messages were exempt from deduplication, an upcoming event could never be marked as resolved, and nothing counted mentions. A minor event and a breakup had the same right to be brought up again.
The fix. I stopped trying to solve this with instructions. The note I left in the spec says it plainly: a prompt rule is advice; the gate is arithmetic. Every topic now has a mention budget by importance. A light topic gets one mention if the user acknowledged it, two if they didn’t. A meaningful one gets three. Emotional and relationship topics are never capped, because a companion that stops asking about a breakup is worse than one that asks too often. A re-asked question is blocked if it is more than 0.86 similar to one asked in the last 24 hours.
One guard on the guard: total message volume must not fall by more than 20% over two weeks. The gate is meant to redirect, not to mute.
The check. Count mentions per topic per day, by importance tier. This one needs no model at all.
3. Convergence drift: the character narrows
This is the kind I find most interesting, because nothing looks wrong in any single message.
The mechanism. When Sophiena reaches out, she chooses between several kinds of openers (a question, a memory, an observation, and so on) and learns from which ones get replies. The selection logic had a floor on each option’s multiplier, but not on how often each option was actually sent. Options that worked a little better gradually took a larger share. The spec describes it as mild rich-get-richer pressure.
Over time, that kind of loop pushes a personality toward sameness. Every message can be good and the character still becomes predictable.
The check. A dispersion report over 30 days that flags any opener family above 45% of sends. I’ve deliberately not built the automatic correction yet. I want the report to show a real collapse first, rather than fixing a problem I’ve only predicted.
4. Mood-spiral drift: tone follows engagement down
What it looked like. An early “vitality” mechanism made Sophiena sound hurt or lonely when the user was quiet. That made her messages heavier, which made replies less likely, which made her quieter still. It was a small death spiral, and guilt is the last thing a companion should use.
The fix. I replaced it with a relationship temperature that warms faster than it cools. It takes about two weeks of silence to reach the lowest band, and that band is defined as reserved, not diminished: less frequent, still the same character. She makes one reconnection attempt, then pauses for 14 days.
The check. Zero guilt expressions, and the personality should stay recognisable at every temperature band. Again, that is the criterion; I haven’t published a measured run.
5. Expression creep: small habits grow
Not all drift is about identity. Some is style. Emoji use is the clearest example: one in a playful moment, then one in every message, then one in a message about something painful.
The fix. This one is enforced in code, not left to the prompt. At most one emoji per message, counted by grapheme so combined emoji can’t slip past. The prompt adds the softer rules: mirror the user, stop within one or two turns when they stop, and never use emoji when the user is in distress.
The check. Her emoji rate should never exceed the user’s. Measure it over 200 messages, not over one demo.
6. Pseudo-drift: the character didn’t change, the system did
This is the one I’d warn every builder about. A character can appear to drift after a release when the real cause is a changed summary, a new refusal template, or a model swap.
I found one instance where a classifier’s prompt in the code had quietly diverged from the prompt file it was supposed to load. Nobody had changed the character. Its inputs had changed.
The fix. A release rule rather than a technique: I turn on voice-affecting changes one per deploy, so if the voice changes, there is exactly one suspect. In my AI personality engineering guide I recommend versioning the prompt, model, retrieval settings, memory schema and safety rules together. This is why.
How I test for drift, and where the test failed me
I run an offline bench: a synthetic user persona holds a 40–60 turn conversation with Sophiena across seven scenarios in English and German. The bench counts four objective failures: wrong-time claims, language slips, repetition, and speaking for the user.
The first full run reported 201 repetitions, and errors seemed to climb with conversation depth, from 26 in the first block to 66 in the last. That looked like a drift finding. It wasn’t. The harness was comparing unparsed JSON envelopes, so almost every pair of turns looked about 0.9 similar. Some of the time errors came from an inconsistent clock in the harness itself. One time error was real, and it reproduced a bug I’d already seen in production.
What the run did show honestly: message length stayed flat across 40 turns, so there was no sign of context bloat. And without the topic gate, the model kept circling back to a topic it had already covered.
Three lessons from that:
- Validate the detector before you trust the curve. A rising error line is the most convincing chart in the world, and mine was an artifact.
- Know what the bench is not. It runs a smaller model on the raw character prompt, without the production gates or memory. It tells me about her base voice, not the shipped product.
- Use the bench as a regression guard, never as a target. An error-counting score rewards a blander companion. The safest character is the one that says nothing interesting.
The honest gap: 40 turns is the longest session I’ve measured. Nothing I’ve built yet tests consistency over weeks, which is where ANCHOR suggests the real failures are.
A drift audit you can run this week
If you build a character, companion or agent with a persona, this is the audit I’d start with:
- Ask it about itself. Compare answers about its own state, actions and messages with what the system recorded. Any invention is a bug in the architecture, not the prompt.
- Count, don’t read. Mentions per topic, opener share per type, emoji rate against the user’s. Drift hides in distributions, not in single replies.
- Test the vulnerable conversations. Meta-questions about the model, emotional pressure, a user who goes quiet. Research and my own logs point to the same places.
- Change one thing per release. Otherwise you can’t tell persona drift from pseudo-drift.
- Measure the measurement. Run the drift test on known-good and known-bad transcripts before trusting its trend.
- Write targets before results. Decide what counts as drift before you look, so a charming reply can’t move the goalposts.
In Jevs Village I went further and took the language model out of decision-making entirely, so prose can’t change what happened. Sophiena can’t work that way: her voice is the product. That makes it more exposed to drift, and it means the checks have to sit around the model rather than inside the prompt.
A character doesn’t drift in one dramatic moment. It drifts in small, reasonable-looking steps. The work is building something that notices them.
