Introduction
When you run /personality teacher mid-session, something visibly changes: the voice. Plenty of things do not change, and the things that do not change are often more important than the things that do. Understanding what carries across switches lets you use the command confidently without worrying you are erasing state you cannot afford to lose.
Key Concepts
- Conversation buffer: The live history of the session, what the model re-reads each turn.
- Persistent memory snapshot:
MEMORY.mdandUSER.mdloaded at session start, frozen for the session. - Tool state: Open file handles, partial tool call results, captured environment.
- Identity slot (slot #1): The piece that does change when you swap personas.
Real World Context
A developer is mid-debugging session, has already pasted three pages of logs and walked the agent through the architecture. They want a more conversational voice for the next ten minutes to talk through ideas. They worry that /personality creative will reset the agent's understanding of the codebase. It will not. The buffer is preserved. They get the new voice and the old context.
Deep Dive
Here is what does change when you run /personality <name>:
- The identity slot (slot #1 of the system prompt) is replaced with the new persona's identity content.
- The next response is generated under the new voice.
Here is what does not change:
- The conversation buffer. Everything the user and assistant have said remains visible. The new persona reads the whole history.
- Persistent memory (
MEMORY.md,USER.md). These were frozen at session start; the switch does not refresh them. - Project context files (
AGENTS.mdand friends). Same as memory: frozen at session start. - Tool state. Tools that maintain state across calls (e.g., a long-running background task) keep that state.
- Skills loaded into the session. If you activated a skill earlier, it is still active.
This is exactly the right design. You almost always want the new persona to inherit everything the old one knew. Resetting the buffer would mean re-pasting the logs, re-walking the architecture, re-establishing the task. Resetting memory would mean losing your user profile and environment facts.
There is a subtle implication for transcripts. If you read back a session transcript after switching personas, you will see the voice change midway: terse for the first ten turns, warm for the next ten. The buffer faithfully records this. Readers of the transcript can see exactly when the persona changed.
One thing to be careful about: very different personas can produce small factual shifts because their structural framing differs. A persona that prefers lists may rank facts differently than one that prefers prose. The information is the same; the emphasis can change. This is rarely a problem in practice, but it explains why a teacher-flavored explanation of the same bug may surface a different-looking root cause than a concise one. The truth has not changed; the spotlight has.
Common Pitfalls
- Hesitating to switch because you fear losing context: You will not. The buffer survives.
- Expecting persona change to refresh memory: It will not. Memory is frozen at session start regardless of how many persona switches you run.
Best Practices
- Switch boldly mid-session: The cost is one command. The state survives.
- Read transcripts with persona changes in mind: When skimming a long session, note the persona switches; they explain shifts in voice or framing.
Summary
- Persona switches change only the identity slot; everything else carries over.
- Conversation buffer, persistent memory, project context, tool state, and active skills all survive.
- The new persona reads the full history and continues from where the old one stopped.
- Switch boldly: state is safe.
Code Examples
// turn 8 (under /personality concise)
user: Why does this query do a seq scan?
agent: Missing composite index on (user_id, created_at). Add it.
// turn 9 - persona switch happens here
user: /personality teacher
// turn 10 (now under /personality teacher; SAME conversation buffer)
user: Walk me through why the planner picked seqscan.
agent: Right. Postgres considers two options on every query: scan the
table sequentially, or use the index. The decision is based on
cost estimates. Looking at the EXPLAIN output we already saw...
(the agent still sees the EXPLAIN output and the earlier diagnosis)