Role switcher
One user, many hats, one honest session.
The same person writes in three voices in a day. In the morning they're an analyst, pulling numbers, hedging claims, citing sources. At noon they're an editor, cutting half the words out of a teammate's draft. By evening they're a reviewer, asking questions and blocking on risk. A product that treats them as one mode is a product that gives the wrong kind of help at the wrong time of day.
The role switcher is the pattern that makes the voice explicit. A pill in the chrome names the active role. Tone, scope, and allowed tools shift with it. The model, reading the active role, calibrates.
"Roles are not personas. They're scopes."
One pill, three to five roles.
The active role is always visible in the top-left of the product chrome. Each role carries three visible attributes: its tone, its allowed tools, and its out-of-scope actions. Switching roles is one tap and writes a small system line into the transcript ("switched from analyst to editor"). The transcript is the source of truth for who was talking in what voice.
Three to five roles is the sweet spot. Two is usually a toggle that pretends to be a role. More than five is a persona library — a different pattern with different ergonomics.
"Reading the retention cohort now. I'll return a week-over-week table with a 95% CI. I won't make claims beyond that."
- ✓ query the data warehouse
- ✓ render a table
- ✓ compute a confidence interval
- · send an email
- · edit a public doc
Role is cheaper than re-prompting.
Without role switching, users re-prompt. "Now review this critically." "Now edit this for length." "Now ignore the editing voice and go back to summarizing." These re-prompts are leaky — the prior tone contaminates the next turn, and the user eventually gives up and opens a new chat.
A role switcher swaps the whole frame at once. Tone, memory scope, tool list, even a role-specific opener. The user feels like they walked into a different room, not like they retrained the same one.
The switcher I'd ship.
- Name the tools per role. Each role's pane should list what it can and can't do. Not as warnings — as scope. "Editor edits in place; doesn't send to others."
- Log the switch in the transcript. A modal announcing a role change is condescending. A small italicized system line reading "switched from analyst to editor" is the right texture.
- Memory is role-scoped by default. A fact taught to the analyst role shouldn't leak into the reviewer role unless the user explicitly promotes it. Role memory is a real feature, not a cosmetic.
Role drift.
The silent failure of this pattern is role drift — the model claims to be in editor mode but starts answering like an analyst halfway through. Often this is a prompt problem, but the interface can help by renaming the active role in the chrome the moment the model's behavior diverges.
If the role is the contract, drifts from it need to be visible, and the fix needs to be obvious — usually, a single tap back to the right role.
What this pattern gets wrong when it gets wrong.
- Role drift
- The model or the user shifts role mid-session without the interface updating tone, scope, or permissions to match.
- Stale memory
- A persistent fact about the user that's out of date and silently poisoning answers.
- Leaky context
- Content from another source, session, or user surfacing in a place it shouldn't.
Three shipping variants worth copying.
- A single pill in the chrome that names the active role
- A per-role allowed-tools list that appears on role change
- A 'switched role' system line in the transcript, not a modal