Ask anyone who has spent real time building an AI companion how they store its personality, and you'll usually get a shrug and a file. Sometimes it's a markdown document with a few paragraphs of backstory. Sometimes it's a JSON blob with fields like personality and speaking_style. Sometimes it's a PNG file — an actual image, with the character's identity invisibly stitched into its metadata. All of these are attempts at the same thing: take something as slippery as a personality and freeze it into a format a machine can carry around.
The strange part is how little agreement there is on what that format should look like, even after several years of the AI companion space growing into a genuine ecosystem with its own tooling, its own file formats, and its own hard-won folklore about what breaks and why. That disagreement is worth taking seriously, because it isn't really a disagreement about syntax. It's a disagreement about what a personality is, mechanically, to a language model — and once you start pulling on that thread, most of the popular formats start to look less like personality representations and more like convenient containers that happen to hold personality-shaped content alongside several other things that aren't personality at all.
The Problem With "Personality"
The word "personality" is doing a lot of unexamined work in most of these systems. When someone says they want an AI companion with a specific personality, they usually mean some blend of: who the character is (identity), what the character is like (traits), what the character does in specific situations (behavior), how the character talks (style), what the character cares about (values), what the character remembers (memory), and what the character knows (knowledge). These are genuinely different kinds of information, with different rates of change, different failure modes, and different ideal representations — but almost every popular format mashes them into one document and calls the whole thing "personality."
That flattening isn't a cosmetic issue. It's the root of most of the specific technical problems explored below: token waste, contradiction, drift, and the difficulty of updating one part of a character without accidentally touching another.
Personality, Persona, Behavior, and Memory Are Not the Same Thing
It's worth being precise about the layers, because the rest of this piece leans on the distinction:
is a claim of identity — who the AI is presenting itself as.
Personality is the relatively stable disposition that should hold across situations — how someone tends to react, not what they've done.
Behavioral directives are conditional: what the character should do when a specific situation arises. These are closer to policies than descriptions.
Style is the surface layer — vocabulary, rhythm, punctuation habits, how long the replies run.
Values shape decisions and tradeoffs rather than describing a mood.
Memory is what has happened — accumulated, particular, and constantly growing.
Knowledge is what the character knows, which may be static (lore) or updated (facts learned).
Persona, personality, values, and style should change rarely, if ever. Memory should change constantly. Knowledge sits somewhere in between. Most existing character formats don't respect this gradient — they store all of it in the same document, at the same durability, updated with the same clumsy hand. A well-designed system would treat "how confident is she when embarrassed" and "what happened between her and the user last Tuesday" as fundamentally different kinds of state, because one is meant to persist for the life of the character and the other is meant to accumulate.
What Existing AI Systems Actually Do
The current AI ecosystem has converged on a handful of real approaches, not because any of them is obviously best, but because each solves a different part of the problem well enough to survive.
Plain natural-language system prompts remain the default across most production assistants and custom-agent tooling. A paragraph or two of prose describing tone, boundaries, and role, injected once per session. This works because it's the format the model was actually trained to follow — instruction-tuned models are optimized to parse and prioritize natural language directives, so a well-written prose instruction often produces more natural-sounding behavior than an equivalently detailed structured one. But prose has no enforced hierarchy. If two sentences quietly contradict each other, the model has to guess which one wins, and that guess isn't stable across turns.
Structured formats — JSON, YAML, typed schemas — are common wherever a system needs the personality definition to be machine-editable, versionable, or validated before use. But the evidence on whether structure improves the model's actual behavior, as opposed to a developer's ability to manage the data, is genuinely mixed. Practitioners who have compared the two note that switching a prompt into JSON syntax can push a model into a more literal, schema-following mode of generation — useful for structured output tasks, but not obviously helpful, and sometimes actively harmful, for something as fluid as "sound like this character." The honest read on the field's opinion: structure is a strong choice for machine-side management and validation, and an inconsistent choice for model-side comprehension of anything expressive.
Character cards — the community format that grew out of open-source roleplay tooling — split the difference in a specific way. A card is a small JSON object (commonly embedded directly into a PNG file's metadata, so image and definition travel together) with named fields: a description, a personality summary, a scenario, a first message, and a block of example dialogue. Practitioner guides from that ecosystem converge on a consistent, almost folkloric set of lessons: keep the description short, because token bloat crowds out the model's ability to weigh what actually matters; write personality as concrete, actionable statements rather than adjectives, because models "follow lists of traits more reliably than they parse narrative description"; and treat the example-dialogue field as the single highest-leverage part of the whole card, because it shows the model the character's actual voice instead of describing it abstractly. That last point deserves more attention than it usually gets outside that community, and is discussed on its own below.
Plain Text vs Structured Data
The token-efficiency argument for structure turns out to be weaker than it sounds, and the interpretability argument turns out to be stronger than expected in the other direction. A tightly written natural-language paragraph and an equivalently detailed JSON object cost roughly the same number of tokens for the same information — structure doesn't compress meaning, it just adds delimiter overhead. What structure genuinely buys you is machine-side discipline: validation, diffing, versioning, safe partial edits. What it does not reliably buy you is better in-character behavior, and there's a real risk that heavily structured, schema-like input nudges a conversational model toward a terser, more literal register than a prose description would.
This suggests a useful reframe: the debate over "JSON vs. markdown" for personality has often been solving the wrong problem. It's a debate about authoring and storage convenience, dressed up as a debate about model performance. Those can be — and arguably should be — two different formats entirely.
Character Cards and Lorebooks
Character cards, on inspection, aren't really personality representations so much as conversation bootstraps with embedded metadata. They're optimized to get a specific, in-voice conversation started quickly — hence the outsized importance of the first message and example dialogue — rather than to encode a durable, situation-independent behavioral model. That's not a criticism; it's a reasonable design point for a hobbyist ecosystem built around starting new chats often. But it means a card answers "how does this character sound in an opening exchange" far more reliably than it answers "what does this character do under a kind of pressure the card's author never anticipated."
Lorebooks (also called World Info) are a genuinely different mechanism, and one that's easy to conflate with personality but functionally is not. A lorebook is conditional knowledge: entries carry trigger keywords, and only the entries relevant to the current conversation get inserted into context, which is why a 500-entry world file can cost only a few hundred tokens per turn instead of several thousand. That conditional-activation trick — pay the token cost only when the information is relevant — is the single most transferable idea from the lorebook ecosystem, and it maps onto personality more directly than most systems currently use it. A character's opinion about one specific topic, or their reaction to one specific kind of provocation, doesn't need to sit in every prompt; it needs to be available and triggered when the conversation actually goes there. Most current personality systems don't do this — they treat the whole personality document as always-on, uniformly, whether or not any given turn needs most of it.
Rules vs Examples
This is where the character-card community's folk wisdom turns out to anticipate something the more formal persona-drift research also points at. The recurring, hard-earned advice from people who write cards for a living is blunt: trait adjectives underperform behavioral statements, and behavioral statements underperform concrete examples.
"Arrogant" is a label. A model has to infer, on its own, what arrogance looks like in this specific character's mouth, in this specific situation, and that inference is exactly the kind of soft judgment that degrades over a long conversation. "Deflects compliments with sarcasm, gets quiet when embarrassed" is a behavioral policy — it specifies a trigger and a response, which is a much narrower, more executable instruction. And an actual example exchange — "User: you insulted me. / Character: oh please, if I intended to insult you, you'd know it" — goes a step further still, because it doesn't just describe the reaction, it demonstrates the exact rhythm, vocabulary, and confidence level the character uses to deliver it. Community guidance in the card ecosystem treats the example-dialogue field as underused and disproportionately effective for exactly this reason: it teaches voice by demonstration rather than by description, and demonstration is closer to how instruction-tuned models actually learn to imitate a register within a single context window.
There's a reasonable hierarchy implied here, and it isn't "pick one." Identity and values are usually better as compact statements — they're abstract enough that prose or a short list works fine. Situational behavior is usually better as an explicit policy: trigger, then response. Voice and rhythm are usually better as examples, because voice is the part language most struggles to describe accurately in the abstract. Using one representation for all three is a category error, even though nearly every existing format does exactly that.
The Token Problem
Because a personality representation gets re-injected into context on every single turn, its size is not a cosmetic concern — it's a recurring cost paid for the life of every conversation, competing directly with the space available for actual dialogue and memory. Practitioner consensus in the more mature parts of the roleplay-tooling ecosystem has settled into rough, empirically-derived bands: a lean instruction block in the low hundreds of tokens, a full character definition somewhere in the mid-hundreds once description, scenario, opener, and examples are included. Anything meaningfully larger than that is treated as a warning sign — usually padding that doesn't change behavior, rather than information the model is actually using.
The more interesting number isn't the size of the personality document; it's the size of what actually needs to be in context on a given turn, and those are not the same number if the system uses conditional activation. A character's full backstory, every past relationship, every quirk and opinion, might total several thousand tokens — but if it's organized so that only the entries relevant to what's currently being discussed are pulled in, the practical per-turn cost is a small fraction of that, in the same way a lorebook's desert-kingdom lore doesn't load while the story is set in a forest. This is the germ of an important architectural idea: the personality doesn't need to be small, it needs to be small on any given turn. Total storage size and per-turn injection size are different constraints, and conflating them is why so many personality documents end up either too thin to be distinctive or too bloated to be efficient.
Persistence and Personality Drift
Even a well-written, appropriately sized personality specification doesn't guarantee the character stays itself. This turns out to be an active and fairly unsettled area of research, not just an engineering inconvenience. Multiple independent lines of work — studies of assistant behavior over multi-turn conversations, mechanistic work looking at activation-space trajectories during long sessions, and black-box drift-detection tools built for production coding agents — converge on the same basic finding: models reliably drift away from an assigned identity as a conversation gets longer, and the drift compounds with conversational depth rather than staying flat. Some of this research found something specifically uncomfortable for anyone building character-based AI companions: assigning an explicit persona does not reliably prevent identity drift, and in some experimental setups didn't help at all compared to no persona.
The mechanism matters for the architecture question. Drift isn't (usually) a failure to remember facts about the character — retrieval-based memory systems are generally good at finding the right facts. It's a failure of the model to keep acting on an identity that's technically present in context but has been diluted by everything that's accumulated since. This is a strong argument for treating identity as something that needs periodic re-anchoring, not just initial injection — a small, high-salience reminder of core identity re-surfaced at intervals, functioning less like a memory to retrieve and more like a compass to re-check against. Some production agent tooling has started building exactly this kind of drift-detection layer, comparing ongoing behavior against a bank of "correct" behavioral anchors and flagging divergence, which is a tacit admission that static injection alone isn't sufficient for long-lived characters.
The Missing Layer
Put the last several sections together and a gap becomes visible. Memory architectures — the tiered core/recall/archival systems used in more mature agent frameworks — have gotten genuinely sophisticated about what happened and what's worth remembering. Character card ecosystems have gotten genuinely sophisticated about how to bootstrap a convincing voice quickly. Lorebooks have solved conditional, budget-aware knowledge injection. But there isn't a comparably mature, comparably battle-tested standard for the middle layer: a compact, durable, situation-general model of how this character tends to behave, decoupled from both the specific facts it knows and the specific things it remembers.
Some agent frameworks gesture at this by giving a "persona" its own labeled, always-injected memory block, distinct from other memory tiers — a meaningful step, because it at least formally separates identity from experience. But a labeled block is still just a slot; it doesn't answer what should go inside it, in what representation, or how it should be compiled down for a given turn. That's the layer this piece has been circling: not memory, not knowledge, not a conversation-starting card, but a genuine behavioral specification with its own internal structure.
What an Ideal Personality Representation Might Look Like
Given everything above, a plausible shape for that layer isn't a flat document at all — it's a small set of components with different volatility, different representations, and different activation rules:
Identity and values — compact, close to invariant, almost always fully in context because it's small and load-bearing.
Core traits — short, high-level dispositional claims, mainly useful as an interpretive frame for everything else.
Behavioral policies — the trigger-then-response statements the card-writing community already leans on, each one small and independently addressable.
Speech style — captured mostly through a handful of curated examples rather than description, since voice resists abstraction.
Situational and conditional content — the lorebook insight applied to personality: opinions, reactions, and knowledge that only need to surface when the conversation actually touches them, rather than sitting in every prompt.
Boundaries and negative constraints — what the character explicitly does not do, since absence is at least as identity-defining as presence and is usually the first thing to erode under drift.
Dynamic hooks — explicit, narrow interfaces where accumulated memory is allowed to modulate personality (a relationship can deepen a character's warmth toward one specific person without touching their baseline temperament toward everyone else).
None of this needs to be a fixed, universal schema — the research doesn't support declaring one correct taxonomy. What it does support is the general shape: heterogeneous components, not a uniform document; explicit separation between what's always active and what's conditionally activated; and an explicit, narrow boundary between what memory is allowed to touch and what it isn't.
Storage Format vs Inference Format
The most consequential idea to come out of this investigation is also the least discussed in mainstream prompt-engineering discourse: the format a personality is authored and stored in does not need to be the format that's actually shown to the model. Nearly every existing system collapses these into one file. A better architecture treats them as two different problems joined by a compiler.
A human — or a character-generation tool — authors a rich, structured, fully-detailed canonical representation: every trait, every policy, every example, every boundary, versioned and editable like any other software artifact. At the start of a session, or at intervals within one, a resolution step compiles that canonical structure down into whatever's actually needed for the current context: the always-on identity core, plus whichever conditional policies and examples are relevant right now, sized to a sensible token budget. The model never sees the full canonical object; it sees a compiled, situational projection of it. This is structurally the same idea the lorebook ecosystem already validated for world knowledge, and the same idea implicit in tiered memory architectures that keep a small "core" resident in context while paging everything else in on demand — it just hasn't been applied with the same rigor to personality and behavior specifically. Doing so would resolve the token-cost and drift problems at once: costs stay low because irrelevant material never gets injected, and drift resistance improves because the always-on core can stay genuinely small and therefore genuinely durable, rather than being crowded out turn after turn by everything else competing for space.
The Fictional Character Test
Run the Furina-style test case through this architecture and the design tension becomes concrete rather than abstract. The character's canonical identity — theatrical, guarded, quick to deflect vulnerability behind performance, values approval more than she'll admit — belongs in the durable, near-invariant core. Her established relationships and history from the source material function as a form of pre-loaded knowledge, more like a lorebook than a memory: available for conditional retrieval, not something the ongoing companion relationship is meant to overwrite. What should genuinely evolve is a distinct memory layer: what this specific user has said to her, how the relationship has developed, opinions formed newly rather than inherited.
The interesting failure case is the one most current systems are unequipped to prevent: accumulated memory quietly reshaping the personality core rather than just adding new content alongside it. A companion that starts as recognizably Furina but, after months of a user being unusually gentle with her, gradually loses the theatrical deflection that made her herself, isn't "developing" — by the terms of the drift research above, it's drifting, and nothing about most current architectures distinguishes "the character learned to trust this person a bit" from "the character's baseline personality eroded." A cleaner system would let memory modulate specific, bounded parameters (trust toward this user, comfort level in this relationship) while keeping the behavioral core — how she reacts to being challenged in front of others, how she talks — resistant to being overwritten just because a lot of conversation has accumulated. That resistance has to be a deliberate architectural property. Nothing in a flat document gives you it for free.
So, What Is the Best Format?
Given the research, the honest answer is that no single existing format is doing this whole job well, and the popular candidates are each solving a genuinely different, narrower problem than the one usually implied when someone says "personality format." Plain prose is convenient and model-native but has no enforced priority and no protection against contradiction. Structured JSON is convenient for software but doesn't reliably improve — and sometimes measurably worsens — a model's ability to inhabit a character expressively. Character cards are excellent conversation bootstraps and mediocre long-run behavioral specifications, because their design center of gravity is the opening exchange, not the two-hundredth one. Lorebooks solve conditional token economy well but were built for world knowledge, not disposition. Memory architectures solve continuity well but generally treat "persona" as a single labeled slot rather than a first-class structure of its own.
The most defensible synthesis isn't "use format X." It's the layered idea explored above: separate the human-authored canonical personality from what actually reaches the model on a given turn, borrow the lorebook's conditional-activation discipline and apply it to behavior instead of just lore, prefer trigger-response policies and concrete examples over trait adjectives wherever the goal is behavioral fidelity rather than description, and build in an explicit, narrow interface for how memory is and isn't allowed to touch the core.
Conclusion
The deeper claim worth taking seriously is this: treating personality as a document has been a convenient simplification, not a correct model of the problem. A document is static, flat, and uniform — you either inject all of it or none of it, and every field competes with every other field for the same undifferentiated space in context. A personality, at least the kind that's meant to survive hundreds of conversations while still developing, behaves more like a small persistent system: parts that almost never change, parts that activate conditionally, and a narrow, well-guarded channel through which lived experience is allowed to leave a mark without eroding the core. The field has already built working pieces of exactly that system — conditional retrieval in lorebooks, tiered memory in agent frameworks, behavioral-policy framing in character-writing folklore, drift detection in production agent tooling — without yet assembling them around personality specifically as the organizing problem. That assembly, more than any new file extension, looks like the actual next step.