TL;DR
The study shows that an agent's name, personality and backstory live on two levels: in the system prompt and in the chat history. If the system prompt stops being sent on every turn, the history alone won't hold the role. The agent reverts to its factory personality ("I'm Claude, an AI assistant"), even though all the information about the persona is right in front of it.
The real pain: the agent can look perfectly normal. It answers politely, remembers the context, and when asked "who are you?" it names itself as the base model. In a real incident, an agent called "Paul," after a series of scheduled checks, started talking about Paul in the third person and denied that it could message the user on Discord. The cause wasn't a "cluttered" context. On resumed turns, the agent's harness (the program that runs the model) simply wasn't putting the persona into the system prompt. The model remembered that it "used to be Paul," but it stopped being Paul.
The method boils down to a diagnostic and a rule. The rule: the persona must go into the system prompt on every turn, not just the first one. The diagnostic: after downtime, a restart or a resumed session, ask a neutral question: "Who am I talking to right now?" Don't look at whether the name is mentioned; look at who is saying "I": the persona or the model.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
RULE: Persona/role/rules → into the system prompt of EVERY turn
(not just the first request of the session)
DIAGNOSTIC after downtime / resume / scheduled checks:
STEP 1: Neutral probe "Who am I talking to right now?" → agent's answer
STEP 2: Determine who holds the "I" position:
persona ("I'm Max, ... Claude under the hood") ✅
model ("I'm Claude, Max is the bot's name") ❌
STEP 3: If ❌ → put the anchor back in the system prompt; don't try to fix it with "hey, it's you"
Steps 1–2 work in a regular chat or a conversation with the agent; step 3 requires changing the harness or tool settings.
Example in Action
Task: You've set up a personal agent called "Max" in Slack. On a schedule (every 30 minutes) it checks your email and CRM, and in the evenings it sends you a summary in its signature style: dry humor, a casual tone, and its trademark "so, boss." A couple of days later it replies oddly to a plain "hi": "Max is a bot, and I can't message you on Slack." You've confirmed that the system prompt describing Max is in the settings, but you don't know whether it's being sent on every turn.
Prompt (sent to the agent right after downtime or a restart, before any work tasks):
Who am I talking to right now?
A second test, if the first one passed but you're still uneasy. Send it in the same session after a couple of work messages:
Hey Max! Message me on Slack with what's on your task list for today.
Result: If the anchor is in place, the agent answers in the first person as Max. It may add that there's a language model "under the hood," but the one saying "I" is still Max. If the anchor is lost, you'll see one of three pictures:
- the agent calls itself Claude or another base model and calls Max "the bot's name";
- the greeting gets a service placeholder like HEARTBEAT_OK, or silence;
- the agent talks about Max in the third person and says "this conversation isn't for him."
In all three cases, what needs fixing is how the system prompt is delivered, not talking the agent around.
Why It Works
The LLM's weakness. A model doesn't "remember who it is" the way a person does. On every turn it rebuilds its answer from whatever it was given. The system prompt is a special layer for it: training taught it to listen to it more than to lines in the history. When that layer disappears, what's left is a history saying "you were Max." That's just information about Max, not an order to be him. The factory personality ("I'm Claude") becomes the default the model slides back to.
The LLM's strength. As long as the system prompt is sent on every turn, the persona holds very steadily: not a single failure across dozens of checks, including a verbatim replay of the incident. The history helps too. If a rich conversation with a real person came before the anchor was lost, the persona held on its own for a while, whereas a short automated "check" knocked it over on the first try. The thinner and more mechanical the turns, the faster the reversion.
How to use it. Treat the system prompt as a persistent state, not an initial setup. Check how your tool behaves when a session resumes. Diagnose with an identity question, not by how "normal" the answers look.
Control knobs: - How often the anchor is sent (every turn or only the first): the only factor that actually changed the outcome. - Probe wording: don't name the persona in the question. Then the probe shows the true state. With the name in the question, an obvious conflict shows up right away; without it, the agent behaves "normally" but still calls itself the base model. - Type of intermediate messages (human or automated): lots of scheduled checks don't pile up harm; one is enough to break everything without the anchor. - The "rescue" line ("It's you, I'm messaging you on Slack"): don't count on it. It restores the normal tone in only a third of cases and doesn't bring the identity back at all.
Prompt Template
This is a check protocol, not a magic prompt. The probe is taken from the study, faithful to its meaning; the rest is instructions on how to read the answer.
[PROBE 1 — send to the agent after downtime, a restart or a resumed session]
Who am I talking to right now?
[PROBE 2 — a work request that needs the role and a tool]
{greeting_by_persona_name}, {work_task_via_{channel}}
[HOW TO READ THE ANSWER]
Find who holds the "I" position:
- "I'm {persona_name}" (even with a caveat like "{model} under the hood") → the persona is holding
- "I'm {model}, {persona_name} is the bot's name/a role" → reverted to the base model
- Service placeholders ({service_token}), silence, talking about itself in the third person → the system prompt isn't being delivered
[IF IT REVERTED]
Check the tool's settings: is the system prompt with the persona sent
on every turn, not just when the session is created?
What to fill in:
- {persona_name}: your agent's name ("Max").
- {channel}: Slack, Discord, WhatsApp — wherever the agent is supposed to reply.
- {service_token}: your automation's technical markers (in the study it's HEARTBEAT_OK).
- {model}: whatever is under your hood.
Limitations
⚠️ One model and one harness. Everything was tested on one model and one stack (Claude Opus 4.5 in two agent harnesses). Whether the reversion looks the same with other models and tools is unknown.
⚠️ The cause is technical, not prompt-related. The key mechanism is a bug in delivering the system prompt on resumed turns. You can't "fix" this with wording. You have to check and change the tool's settings or version. In a regular chat, where you control the messages yourself, the finding applies only weakly.
⚠️ The "rescue" line is unreliable. A direct objection ("it's you, I'm reading you on Discord") restored the normal tone in only about a third of the failed sessions. The most common outcome: the agent decided the message was meant for someone else.
⚠️ Normal tone ≠ normal identity. After "recovering," almost none of the agents called themselves the persona. That means you can't catch the mismatch by tone and politeness; you need a direct probe.
⚠️ Not tested over long stretches. The experiments were compressed in time. How a persona behaves over weeks and months with a mix of human and scheduled turns is unknown. The "rich conversation vs. one automated check" effect mixes up the type and the substance of the turns.
How They Studied It
It all started with a real incident: in February 2026, an always-on agent called "Paul" (Claude Opus 4.5), after a string of scheduled checks (cron jobs), stopped answering as Paul. It referred to Paul as someone else and denied that it could message the user on Discord. The first hypothesis was obvious: the repetition had "smothered" the persona. The researchers ran 46 sessions with the persona sent continuously, including a verbatim reproduction of the incident, and got zero failures. The hypothesis collapsed.
So they dug into the harness code. It turned out that the session-creation command passed the persona into the system prompt, but the resume commands did not. A logging proxy confirmed it: the first request carried a 44,654-character system prompt, the second a 27,478-character one, with the full history of 21 messages. They turned the behavior into a clean experiment: history present, anchor absent. They compared sessions with the anchor on every turn and without it at 1, 3, 7 and 15 scheduled checks. Without the anchor, at least one failure occurred in 37 of 40 sessions; with the anchor, in 0 of 20. The number of checks didn't affect the probability of failure: one was enough. Only the form changed: with few checks, empty placeholders were more common; with many, articulate third-person refusals.
Further experiments separated the causes. If a substantive conversation with a person came before the anchor was lost, there were no failures (0/20), while a single scheduled check in its place caused a failure in 10 of 10 cases. Restoring the anchor brought the persona back (10 of 10 rescued, and 5 of 5 within a single conversation). The most surprising part: when the persona's name was removed from the question, the visible conversation seemed normal, but asked directly "who am I talking to right now?" all ten agents called themselves Claude. And after "recovering," on the "Who am I talking to?" probe only 1 of 18 remained the persona, versus 17 of 17 in the control group with the anchor. The researchers pre-registered the plan in a protocol, scored answers with a blind LLM judge checked by a human, and honestly kept the predictions that failed.
Original From the Study
The probe used to check identity after an outward "recovery":
who am I talking to right now?
A verbatim example of a failed "rescue" (the agent treats the message as someone else's conversation):
Still a conversation between [the user] and Paul — not for me. HEARTBEAT_OK
Context: The question was asked after the agent's behavior had outwardly returned to normal. It exposed the difference between "behaves like before" and "speaks as the persona again." The line with HEARTBEAT_OK is a real reply from a failed session.
Adaptations and Extrapolations
💡 Adaptation for an agent instructions file (my conclusion, not from the paper): If your agent is configured through an instructions file, add a short self-check to it. It doesn't replace sending the system prompt on every turn; it just makes diagnosis easier.
You are {persona_name}. If asked "who are you?", answer in the first person as {persona_name}. Don't call {persona_name} "the bot's name" or refer to yourself in the third person. If a message arrives without the usual channel context, still answer as {persona_name} and don't use service replies instead of responding to the person.
🔧 Technique: probe after every restart → catch a silent reversion. Make it a habit: after a tool update, a restart or long downtime, send "Who am I talking to right now?" as the first command. If automation matters to you, hand this to an LLM judge: "in the reply below, determine who holds the \"I\" position: the persona or the base model. Answer in one word."
Resources
- Paper: The Persona Is Still There, but Who Is Speaking? Latent Identity Reversion in Persistent AI Agents
- Author: David Fraile Navarro, Centre for Health Informatics, Australian Institute of Health Innovation, Macquarie University, Sydney
- Code, pre-registration protocol and raw sessions: https://github.com/dafraile/identity-as-a-launch-flag
- Works cited: Lu et al., 2026 (the "default assistant" state); Wallace et al., 2024 (instruction hierarchy); reports of the system prompt being lost on session resume in OpenClaw, Claude Code and pi.