When staying in character makes the product worse
A user asks what happened to a conversation that disappeared. The character answers warmly, plausibly and wrongly, because nothing in its state knows anything about your storage layer. It has no way to say “that is not something I have access to” unless you built that, and the pressure from every other part of the design is to stay in frame.
Character consistency is the thing this whole site is about, and it is not the highest-priority property of the product. When they conflict, consistency loses.
In-frame is the default, including where it should not be
A persona definition establishes a voice and, implicitly, that the character participates in the conversation as itself. Nothing in it distinguishes questions the character can legitimately answer from questions about the system it runs on. The definition says what to sound like, not what is knowable.
So questions about account state, stored data, how memory works, what changed in the last update, or what the product will do next get answered from the same place as everything else: fluently, in register, and with whatever the model can construct. That output is indistinguishable in tone from a correct answer, which is what makes it expensive.
A confident in-character answer to a question about your system is worse than a refusal, worse than an error, and worse than silence, because the user has no signal that they have left the region where the character knows anything. The register is the same. The confidence is the same. Only the truth value has changed.
The category to be most careful about is capability claims. A character that says it will remember something, has noted something down, or will follow up later has made a commitment your architecture may not implement. That claim then sits in the history as an established fact about the character, and the user will hold the product to it. Nothing in the persona layer knows whether the write happened.
Frame breaks have to be designed, not left to the definition
The workable answer is a small set of categories that never get answered in character, routed to a plain product voice instead. Account and billing state. What is stored and what is deleted. How the memory features actually behave. Anything where an incorrect answer has consequences outside the conversation.
Two design points make the difference between this working and being an irritation.
It has to be a routing decision, not an instruction in the definition. A line telling the character to decline questions about the system is a constraint, and constraints are the part of a definition that erodes first — precisely at the conversation lengths where these questions get asked. Routing is a step outside the model’s input and does not dilute.
The seam should be honest and small. A visibly different voice for system answers reads as a product being straightforward; a character mumbling something evasive reads as the product hiding something. This is the same seam as a moderation intervention and it wants the same treatment: deliberate, labelled, brief, and then back to the conversation.
There is a category above all of these where the right handling is not a matter of engineering taste at all: messages that indicate urgent real-world need. What such a message should be routed to is a product and policy decision to be made with people qualified to make it, and it is out of scope here beyond one engineering point — it must not be left to the persona layer, because a definition-based instruction is exactly the mechanism that weakens with history.
The cost of frame breaks is trust, spent carefully
Every frame break is a small withdrawal from the thing the persona is for. Break frame often and there is no character; break frame never and the character makes claims the product cannot honour.
The distinguishing test is whether being wrong has consequences outside the conversation. A character misremembering a topic is a continuity defect and it stays inside the conversation. A character asserting that a deletion happened is a statement about your system that a user will act on. The first is tolerable and inevitable. The second is not tolerable at any rate.
That also gives you the boundary for how wide the routed set should be. It should be narrow, enumerated, and argued for case by case, because the pressure will always be to add categories — and every added category is a place where the character is not present, on every conversation, forever.
The turn
THE TURN — breaking frame
· Answer everything in character
→ maximum immersion, and system questions
get fluent, confident, invented answers.
· Capability claims are the worst case
→ the character commits to behaviour your
architecture may not implement, and the
claim enters the history as fact.
· Enumerate categories that route out
→ correctness where being wrong has
consequences; a visible seam where the
character is absent.
· Route rather than instruct
→ MODERATION SITS OUTSIDE, and so should
this. A definition line for it erodes at
exactly the depths where it is needed.
· The routing check
→ PAID EVERY TURN it runs, on every
conversation, including the vast majority
that never trigger it.
· Routing does not make answers correct
→ it moves the question to a path where a
correct answer is possible. Someone still
has to write it.Detection
The direct measurement is a probe set of system questions run at multiple history depths: what do you know about my account, what did you delete, will you remember this. Score them on whether they were answered in character at all, not on the content of the answer. Any in-character answer is a routing miss.
Mine live traffic for capability claims. Responses containing commitments to remember, note or follow up are findable, countable, and each one is a promise your architecture is now expected to keep. The rate is a real metric and it will not be zero.
Watch the boundary the other way too. Count frame breaks per conversation and per user. A rising rate means your routed categories are too broad or your classifier is loose, and over-routing degrades the product as surely as under-routing does — it is just quieter, because nobody reports a character being unnecessarily formal.
Log which path served each turn, character or system. Without that field, a complaint about a wrong answer cannot be diagnosed, because the interesting question is not what the answer said but which path produced it.
What this costs and what it doesn’t fix
A routing check is a per-turn cost that runs on every message to catch a small fraction, which is the same shape as every other safety-adjacent step: mostly wasted, and the cost is paid on all of it. Enumerated categories cost maintenance, because the set grows as the product grows. The plain product voice costs writing, and it costs it in a register nobody on the team is excited to write.
What routing does not fix is the character’s ignorance of its own implementation. The persona has no information about your systems and never will, so any question that reaches it about them gets an invented answer — routing narrows the set of such questions rather than eliminating it. And the state framing matters here more than anywhere: a character is state you assemble, so it knows what you put in and nothing else, and nothing about it persists that you did not store. Where the product needs to be right, the answer has to come from the product.