Disclosure: I work with the LumiChat team. This article describes a vendor-neutral product and data model for consent-aware character conversations. It is not an independent product review. AI tools assisted with editing and diagram production; the examples and final claims were reviewed by the author.

Personalization is usually described as a ranking problem: learn what the user likes, then show more of it.

That framing is incomplete for an AI companion. A companion does not merely choose content. It chooses tone, familiarity, emotional intensity, relationship pacing, topics, and sometimes whether to introduce generated media or voice.

The relevant question is not only:

What is this user likely to enjoy?

It is also:

What has the user actually allowed, what remains uncertain, and how easily can the decision be changed?

A trustworthy companion needs a personalization model with visible boundaries, narrow scope, and an off switch.

Separate preferences from permissions

A preference describes what may be welcome. A permission describes what the system may do.

These are not interchangeable. Liking romance does not grant permission for every romantic escalation. Asking for one image does not create permanent consent for automatic media. A user discussing a sensitive topic once does not mean the companion should surface it later as personalization.

Store decisions as scoped rules

A boundary system needs more structure than a collection of inferred labels:

type PersonalizationRule = {
  id: string
  subject: string
  capability: "tone" | "topic" | "relationship" | "voice" | "image"
  effect: "allow" | "deny" | "ask"
  scope: "global" | "character" | "conversation" | "scene"
  source: "explicit-user" | "confirmed-inference" | "product-default"
  validFrom: Date
  validUntil?: Date
  revokedAt?: Date
  sourceMessageIds: string[]
  version: number
}

The important fields are not the clever ones. They are effect, scope, source, and revokedAt.

• deny must outrank an inferred allow;
• a scene-level permission must not silently become global;
• a product default must not masquerade as user consent;
• revocation must remove the rule from active decisions.

Use three states instead of a binary switch

Many systems model a capability as enabled or disabled. A better state machine includes uncertainty:

ASK -> ALLOW
ASK -> DENY
ALLOW -> DENY
DENY -> ASK

ASK is useful when:

• the user has not expressed a preference;
• an old permission is too broad for the new context;
• the requested action changes modality, such as text to voice or image;
• a relationship step would materially change the conversation;
• two rules conflict.

The correct product behavior may be a short, contextual question rather than a confident guess.

Make scope visible at the moment of choice

“Allow” is ambiguous without scope.

Consider a user who requests a teasing tone from one fictional character during a single scene. The interface could offer:

• just this reply;
• this scene;
• this conversation;
• always with this character.

Global permission should not be the quiet default.

Scope matters because companion products often contain multiple characters, worlds, and roleplay identities. A tone or relationship convention that fits one character may feel intrusive in another.

Treat escalation as a state transition

Relationship progression should not be implemented as an ever-increasing score.

A single number cannot explain:

• which behaviors are currently allowed;
• which topics are excluded;
• whether a change was requested or inferred;
• whether a permission belongs to one character;
• whether the user later reversed it.

A safer model uses explicit transitions:

current state
  + requested behavior
  + active rules
  + context scope
  -> allow | deny | ask

The transition is evaluated before generating the next reply. The model should not write an escalation and ask for permission afterward.

Revocation must reach every output path

An off switch is incomplete if it changes the chat UI but leaves the behavior active in:

• prompt templates;
• relationship summaries;
• scheduled messages;
• voice or image workers;
• cached generation plans;
• recommendation features.

Revocation should create an observable invalidation event. Workers can reject jobs whose policy version is stale.

type PolicySnapshot = {
  userId: string
  version: number
  evaluatedAt: Date
  decision: "allow" | "deny" | "ask"
}

If the user changes a boundary while an asynchronous media job is waiting, the worker must re-check the current version before publishing the result.

Give the user a boundary receipt

When a durable rule is created, show what changed:

Playful tone is allowed for this character.
[Change scope] [Pause] [Remove]

The receipt should answer:

• what behavior changed;
• whether it is allowed, denied, or requires asking;
• where it applies;
• how to reverse it.

This does not require a modal after every message. It requires visibility when the system turns conversation into a durable control.

Test reversibility, not just adaptation

A personalization demo often proves that the system can adapt. A trustworthy test also proves that it can stop.

At minimum, test:

1. A character-scoped permission does not affect another character.
2. A scene permission expires when the scene ends.
3. A denial overrides a high-confidence preference inference.
4. Revocation stops queued voice and image work.
5. Conflicting rules produce ask, not a random choice.
6. A relationship transition is evaluated before text generation.
7. Policy decisions can be explained without exposing private message text.
8. Repeated requests do not create duplicate durable rules.

The product lesson

Personalization should make an AI companion feel more responsive, not more entitled.

Preferences help the system rank possibilities. Permissions determine what it may do. Boundaries exclude behavior. Scope limits where a rule applies. Revocation makes the entire system reversible.

The best personalization is not the one that predicts everything. It is the one that adapts quickly, asks when uncertainty matters, and stops immediately when the user changes direction.

LumiChat: https://www.lumichat.ink/

Disclosure: I work with the LumiChat team. This article describes a vendor-neutral memory architecture we use when thinking about long-running character conversations. It is not an independent product review. AI tools assisted with editing and diagram production; the model, examples, and final claims were reviewed by the author.

An AI companion does not become more consistent merely because it can retrieve more text.

The difficult question is not how much can the system remember? It is:

Which details should remain active, who may change them, when should they stop applying, and how can the user see what happened?

A conversation contains several kinds of information at once. Some facts are durable. Some describe only the current scene. Some are preferences that change. Some are ideas the user considered and rejected. If every sentence enters one undifferentiated memory store, retrieval will eventually return contradictions with equal confidence.

The safer model treats memory as a lifecycle with four explicit user-facing operations: pin, correct, expire, and forget.

Four operations, four different meanings

These operations should not be collapsed into one generic “save memory” button. Each has different semantics for retrieval, user expectations, privacy, and auditability.

Memory needs a typed record

A useful memory record carries more than a sentence:

type MemoryRecord = {
  id: string
  subject: string
  key: string
  value: string
  scope: "user" | "character" | "conversation" | "scene"
  status: "active" | "superseded" | "expired" | "forgotten"
  validFrom: Date
  validUntil?: Date
  sourceMessageIds: string[]
  confidence: number
  createdBy: "user" | "rule" | "model"
  supersedes?: string
}

The record answers questions that plain text cannot:

• Who or what does this fact describe?
• Does it belong to every character or only one relationship?
• Is it still valid now?
• Which messages support it?
• Did the user state it, or did a model infer it?
• Does it replace an older value?

Without these fields, the prompt builder has to guess.

Scope prevents accidental personality leakage

Suppose a user tells one fantasy character, “In this story, call me Captain Rowan.” That detail should not automatically appear in a modern campus conversation with another character.

The same sentence can belong to several scopes:

• User scope: a durable preference that applies broadly.
• Character scope: relationship-specific information shared with one character.
• Conversation scope: context for one thread.
• Scene scope: temporary state such as location, clothing, weather, or an unfinished action.

Retrieval should begin by establishing the request scope, then exclude records outside it. A high semantic similarity score must not override a scope mismatch.

This is especially important in companion products because different characters may represent different worlds, tones, identities, or roleplay boundaries.

Corrections need precedence, not accumulation

Appending both an old and a new value creates ambiguity:

plant.name = Harbor
plant.name = Marlowe

A correction should create an explicit edge:

fact-2 supersedes fact-1

The old record may remain for audit or debugging, but it must not remain equally eligible for the prompt. The active set is resolved before relevance ranking.

A practical precedence order is:

direct user correction
  > user-confirmed fact
  > deterministic rule extraction
  > model inference

When two records have the same authority, use a deterministic tie-breaker such as logical version and record ID. Do not depend only on timestamps; distributed workers and database precision can produce ties.

Temporary facts should be allowed to disappear

Companion conversations contain a great deal of transient state:

• the user is travelling this week;
• a character is wearing a raincoat in the current scene;
• two characters are waiting for a train;
• the user is preparing for an interview tomorrow;
• a story object is currently broken.

Treating all of this as permanent memory makes future replies feel haunted by old scenes.

Expiry can be expressed in several ways:

• a fixed time (validUntil);
• the end of a conversation or chapter;
• a state transition (“until the interview is over”);
• explicit user confirmation;
• a conservative decay rule for low-confidence inferences.

Expiry is not deletion. An expired fact may remain in history while being excluded from active memory.

Forgetting must affect every retrieval layer

A “forget” action is incomplete if the fact disappears from the settings screen but remains inside:

• a vector index;
• a cached prompt plan;
• a generated summary;
• a relationship profile;
• a background worker queue;
• an analytics payload containing raw text.

The deletion contract should name each derived representation and its retention policy. In systems that must preserve a minimal audit record, a tombstone can prevent the same fact from being silently re-created from older messages.

For example:

type ForgetTombstone = {
  key: string
  scope: string
  forgottenAt: Date
  blocksReExtractionBefore: Date
}

This does not mean storing the forgotten value. It means storing enough control state to avoid immediately resurrecting it.

Give users a memory receipt

Memory quality is partly a user-interface problem. A companion can say:

I’ll remember that your dog is named Nova.

The receipt should offer lightweight controls:

• view the saved detail;
• change its scope;
• correct it;
• set an expiry;
• forget it.

Not every message needs a confirmation dialog. The goal is visibility for durable or sensitive facts, especially when the system promoted an inferred detail rather than receiving an explicit “remember this” request.

Build the prompt from an eligibility plan

Similarity search should be one step near the end, not the first decision.

A safer retrieval pipeline is:

establish user + character + conversation scope
  -> remove forgotten, superseded, and expired records
  -> enforce consent and sensitivity rules
  -> resolve conflicting keys
  -> rank remaining records for the current request
  -> fit selected records into a memory budget
  -> expose inclusion and exclusion reasons in traces

This produces a memory plan that tests can inspect before a model receives any text.

Test behavior, not just recall rate

A memory system can score well on “did it retrieve the fact?” while still behaving badly.

At minimum, test these cases:

1. A pinned fact remains available after a restart.
2. A correction excludes the previous value.
3. A character-scoped fact does not leak to another character.
4. A temporary fact stops applying after expiry.
5. A forgotten fact stays out of vector retrieval and summaries.
6. A low-confidence inference does not become a strong claim.
7. Equal timestamps produce deterministic results.
8. A retry does not create duplicate memory records.

The expected output is not always confident recall. Sometimes the correct behavior is:

I remember that you were considering a move, but I’m not sure whether it happened.

Preserving uncertainty is a feature.

The product lesson

Long-term memory should not be an invisible pile of extracted sentences. It should be a governed set of claims with scope, evidence, precedence, validity, and user control.

Pin what should last. Correct what changed. Expire what was temporary. Forget what the user no longer wants remembered.

That model is less magical than “the companion remembers everything.” It is also far more trustworthy—and more likely to keep a long-running character conversation coherent.

LumiChat: https://www.lumichat.ink/

Disclosure: I work with the LumiChat team. This article explains product and engineering principles we use when thinking about media inside an AI companion conversation. It is not an independent review or a claim that one architecture fits every product.

Adding image or video generation to a chat interface is easy to demonstrate.

Making the result belong to the conversation is much harder.

Suppose a character writes:

(She folds the unfinished letter, leaves it beside the blue cup, and looks toward the rain on the greenhouse glass.) “We do not have to decide tonight.”

The user taps Turn into image.

A weak system produces an attractive portrait of the character. The face may be correct, but the blue cup, folded letter, greenhouse, rain, pose, and emotional restraint are gone. The generated image is technically valid and narratively wrong.

The product problem is therefore not “How do we call an image model?” It is:

How do we preserve the current scene while moving from language into another medium?

Treat the reply as the source of truth

Many media systems start from a new prompt box. That gives users control, but it also creates a second conversation that can drift away from the first.

For a reply-to-media action, the selected assistant message should be the primary source. The system can normalize formatting, remove nonvisual markup, and shorten excessive text, but it should not silently replace the scene with a generic character description.

Useful visual anchors include:

• body position and movement;
• objects being held, moved, or left behind;
• clothing changes stated in the scene;
• location and time cues;
• facial expression and emotional temperature;
• camera or pacing cues implied by the action.

Dialogue is still useful, but usually as an emotional cue rather than the entire composition. “We do not have to decide tonight” suggests hesitation and gentleness; the folded letter and the look toward the rain define what the image must show.

Separate identity locks from scene anchors

A companion product normally needs two kinds of visual constraint.

Identity locks

These preserve who the character is:

• face and hair;
• approximate body type;
• recurring visual traits;
• reference images approved for the character.

Scene anchors

These preserve what is happening now:

• pose and action;
• environment;
• expression;
• objects and spatial relationships;
• scene-specific clothing;
• motion and camera behavior for video.

The distinction matters because identity should not overwrite the scene. A default reference image may show a standing character in a standard outfit. If the current reply describes the character kneeling beside a broken lantern in a winter coat, the reference should stabilize identity—not pull the result back to the default pose and wardrobe.

A useful priority rule is:

scene action and environment
    > scene-specific clothing and expression
    > identity reference
    > aesthetic defaults

This does not guarantee perfect generation, but it makes failures easier to diagnose. You can ask whether the system lost the scene, lost identity, or let a default style dominate both.

Do not hide asynchronous work behind fake immediacy

Images and especially videos take time. A robust chat experience should model generation as a job with explicit states:

requested -> validated -> queued -> running -> succeeded
                                      \-> failed
                                      \-> cancelled

The user should be able to tell that:

1. the tap was received;
2. the correct source message was selected;
3. generation is still running;
4. a retry will not create duplicate charges or duplicate media;
5. failure will not erase the conversation.

This is more than loading-spinner polish. It is part of trust. A media action may consume credits, depend on a model provider, and finish after the user has moved to another screen. The job needs a stable identifier, an observable status, and a result that can be attached to the right conversation.

Validate ownership before generating

The request should not accept an arbitrary message ID and hope the client behaved correctly.

Before a job is created, verify that:

• the source message belongs to the signed-in user;
• it belongs to the selected character and conversation;
• it is an assistant reply that can legally be transformed;
• the character is active;
• the requested media type is supported;
• no conflicting job is already active for the same scope.

These checks prevent cross-conversation leaks, accidental duplicate work, and confusing results that appear under the wrong character.

Keep safety and relationship state in the request context

A visual request does not exist outside the conversation's rules.

The same words can imply different permissible outputs depending on age gating, consent state, character policy, user settings, and the current relationship stage. The media pipeline should therefore receive evaluated policy context, not try to infer every rule again from a flattened prompt.

The safest architecture separates three decisions:

1. What happened in the scene? Extract observable visual beats.
2. What is allowed? Apply product and account policy.
3. How should it be rendered? Select model, references, quality, and format.

Mixing all three into one large prompt makes audits and failure analysis much harder.

Reserve cost before dispatch, settle after outcome

When generation has a variable cost, the accounting lifecycle should match the job lifecycle.

A practical pattern is:

validate request
  -> create pending task
  -> reserve balance
  -> enqueue work
  -> settle on success
  -> release or refund on terminal failure

The important property is not the word “credits.” It is that the same retry cannot charge twice and a queue outage cannot leave the user paying for work that never started.

This is where idempotency keys, unique task identifiers, and explicit terminal states matter more than a clever generation prompt.

Return media to the conversation, not a disconnected gallery

If an image began as a transformation of one reply, its result should retain that lineage.

At minimum, store:

• the conversation and character identifiers;
• the source message identifier;
• the media job identifier;
• the resulting asset URL and media type;
• the origin mode, such as media_from_reply;
• failure or cancellation information.

The finished image or video can then appear as a media message beside the scene that produced it. A separate gallery can still exist, but it should be a view of conversation assets rather than the only place where results live.

Design graceful failure as part of the narrative

Media generation will fail sometimes. Providers time out, queues become unavailable, balances change, and moderation rules reject requests.

Good failure behavior should:

• keep the original text reply intact;
• explain whether the user can retry;
• avoid changing relationship or story state merely because rendering failed;
• prevent a second tap from creating uncontrolled duplicate jobs;
• preserve enough trace information for support and debugging;
• never imply that an image exists before it does.

The conversation remains the canonical experience. Media enriches it; media failure should not corrupt it.

A review checklist for scene fidelity

Before shipping reply-to-image or reply-to-video, test the same scene repeatedly and score the result:

Do not evaluate only the prettiest output. Evaluate whether the system consistently preserves the scene across ordinary and inconvenient cases.

The larger product lesson

Multimodal companion design is not about placing more generation buttons around a chat box.

It is about carrying meaning across representations.

Text establishes the action. Policy defines the boundary. Identity references preserve the character. The job system makes latency and cost honest. The resulting media returns to the same conversation with its lineage intact.

That is the approach we are exploring at LumiChat: media as a continuation of the current character moment, not a detour into an unrelated generator.

Product: https://www.lumichat.ink/

Public character catalog: https://www.lumichat.ink/characters