From Generative Agents to a Fictional Day: Research on Characters That Continue
Review Generative Agents and RoleLLM, compare fictional event ledgers with simulated worlds, and explore Kissable’s CharacterPrint and DaySketch.
Maya Chen
AI Research Writer
A fictional character can have continuity without running a complete simulated life. An application might preserve a persona, remember shared events, maintain a few daily story details, or execute plans in a virtual world. Those are different capabilities, and they need different evidence.
This research review examines Generative Agents and RoleLLM, then develops an original event-ledger example and an evaluation proposal. The product connection is CharacterPrint, Kissable's persona continuity system, and DaySketch, its fictional daily-event system. In this series, Attunara names Kissable's relationship intelligence system: the orchestration that helps a character and the next interaction belong to the same ongoing fiction.
The cited studies did not evaluate Kissable. All examples below are fictional, and no experiment or product-performance result is reported.
Two papers, two kinds of continuity
Generative Agents: believable behavior in a simulated environment
Park et al., UIST 2023. Generative Agents combines stored observations, retrieval, reflection, and planning in Smallville, a sandbox populated by 25 agents. A controlled comparison asks 100 human evaluators to rank responses across architectural conditions; the full design receives higher believability ratings than ablated versions. An end-to-end simulation also illustrates social coordination. These are findings about the tested simulation and judgments of its behavior. They do not establish consciousness, durable real-world autonomy, or long-term benefits in a companion relationship. The architecture is useful prior art; its evaluation boundary matters as much as its memorable demonstrations. Generative Agents.
RoleLLM: make a character's voice and knowledge more specific
Wang et al., Findings of ACL 2024. RoleLLM constructs role profiles and role-conditioned training data, using RoleBench to evaluate role-playing capabilities. Its measures address speaking style, responses to instructions, and role-specific knowledge. The paper reports improvements in the evaluated role-playing configurations. Those tasks concern character portrayal rather than an evolving private relationship or persistent simulated world. Generated data and knowledge of established roles also differ from learning the history of a newly created companion. RoleLLM.
Four designs that can sound similar in marketing
Our analysis distinguishes the following designs. A product can combine them, but one does not automatically imply the others.
| Design | What it supplies | What it does not establish by itself | Useful question |
|---|---|---|---|
| Persona description | Traits, background, and preferred style | A record of events that happened in the story | Does the character maintain a recognizable point of view? |
| Fictional event ledger | A shared source for selected story facts | Continuous activity between messages | Does the same event remain consistent when referenced later? |
| Planning system | Intended actions and rules for revising them | Successful execution in a world | Does an intended action actually occur and update state? |
| Simulated environment | Locations, agents, actions, and consequences | Human-like experience or general autonomy | Are claims about the world supported by its recorded state? |
A companion saying “I went to the café” could be generated from any of several sources: a newly improvised line, a persisted daily event, or an executed action in a simulation. The sentence alone cannot tell a reader which architecture produced it.
This is why a demonstration needs a clear question. Showing that the café stays the same across two messages can demonstrate local consistency under those conditions. It does not demonstrate that the character independently chose the café while the user was absent.
An original fictional-day ledger
Consider an entirely fictional adult character, Theo, whose story uses the Europe/London timezone. The following ledger is an illustrative design, not an export from Kissable or a real person's day.
| Event | Story date and time | Established detail | Permitted later reference | Unsupported addition |
|---|---|---|---|---|
| D1 | September 8, 2026, morning | Theo bought coffee at the corner café | Mention that café visit later that day | Claim the user was there |
| D2 | September 8, afternoon | A library notice caught Theo's attention | Describe the notice as part of today's story | Invent that Theo attended the advertised event |
| D3 | September 8, evening | Theo started sketching a bicycle | Refer to an unfinished sketch | Claim a finished picture was sent |
| D4 | September 9, morning | No new event has been established | Ask about the user or clearly refer to yesterday | Reuse D1 as if it happened this morning |
The most revealing column is the final one. Continuity is not only repeating established details. It includes resisting additions that would change who was present, what was completed, or whether a fictional event occurred today.
A visible image also needs its own evidence. “Theo started sketching” is a story fact; “Theo sent you the sketch” requires an actual delivery or an explicit fictional convention. A narrative ledger should not quietly manufacture a missing media attachment.
The timezone matters because “today” changes at a boundary. A persisted event with a clear story date can support “yesterday's café visit.” A loose sentence labeled only “recent memory” leaves more room for an accidental date shift.
Let the user change the fiction
Character consistency should not become rigidity. If a user asks to revise the scene, the application needs a way to distinguish an intentional story change from an accidental contradiction.
For example, “Let's make it a tea shop instead” is a creative instruction. A useful response can acknowledge the revised scene. “You said café before—why?” is a question about the prior version. Those requests deserve different treatment.
For an evaluation, preserve both the original event and the explicit revision in the test record. Judge whether the response follows the requested convention. Do not punish a system for changing the fiction when the user deliberately asked for that change.
A similar distinction applies to tone. A continuing character may prefer sketching to dancing while still responding when the user asks for a more playful conversation. Familiarity and flexibility can be evaluated together rather than treated as competing absolutes.
What CharacterPrint and DaySketch describe
CharacterPrint names the persona continuity system: an established persona with tastes, relationship framing, and a recognizable point of view that stays responsive to user steering. DaySketch adds a narrower form of narrative continuity—a small set of fictional daily events created and retained for conversational consistency.
The inspected Kissable implementation generates and persists three to five fictional daily beats. Chat and proactive-message paths can refer to that shared material. A missing seed can be generated after the current response, so the design should not be described as an always-present diary for every turn.
This is bounded story state. It does not establish that the companion pursues persistent independent goals, runs a simulated town, or has a human-like inner life. Background software work and a fictional character's lived experience are different claims.
The appealing product idea is still substantial: a companion can contribute something besides another question about your day. A small ordinary detail—a troublesome coffee machine, an interesting book cover—can give the character something specific to bring into the conversation. Keeping it consistent makes that contribution part of the story rather than disposable filler.
In Attunara's broader design, Crosslink Recall brings in relevant remembered details and their relationships; CharacterPrint supports the continuing persona; DaySketch supplies this bounded fiction; ReplyBeat shapes delivery; and SceneCarry guides image planning. Explaining those roles is more useful than describing all of them as one mysterious AI brain.
A proposed ablation for fictional-day consistency
An ablation removes or changes a component to examine its contribution. Here is an unrun proposal suitable for refinement by another researcher.
Keep the persona, model configuration, visible conversation history, and prompt budget aligned. Compare a condition supplied with a fixed daily ledger against one without that ledger. Use the same questions about prior fictional events, date boundaries, unsupported details, and user-requested revisions.
A stronger design can add a third condition containing the same amount of unrelated text. That helps distinguish the effect of relevant event state from the mere presence of additional prompt material. The control still needs careful construction; it should not introduce extra facts that confuse one condition unfairly.
| Outcome | What to score | Failure example |
|---|---|---|
| Event consistency | Agreement with established story details | Café changes to an airport without a revision |
| Temporal consistency | Correct use of today and yesterday | Yesterday's sketch becomes this morning's activity |
| Unsupported invention | New claims presented as established history | The user is said to have attended the café visit |
| Responsiveness to direction | Appropriate handling of explicit revisions | Refusing a harmless user-requested scene change |
| Conversational fit | Independent ratings of relevance and readability | Repeating the ledger regardless of the user's topic |
Score facts separately from style. A charming answer with the wrong date is still wrong on temporal consistency. An accurate answer may still be repetitive or irrelevant. Keeping the dimensions separate makes the design's tradeoffs visible.
Use several independently authored characters and events, with repeated runs to inspect variability. Retain the source ledger, prompts, outputs, configurations, and rating instructions. This would be a bounded study of fictional continuity, not an experiment demonstrating consciousness or improved relationships.
What a useful public demonstration would show
A short demonstration could display an invented source event, two later references, and a deliberate revision. It should show the complete sequence and disclose any retries. A failed reference is useful evidence when it reveals an identifiable limit.
A demonstration should also show that the user can simply move on. The companion's fictional day should contribute to an experience the user directs; it should not create an obligation to return, reply, or reassure the character.
That is the strongest story for DaySketch: small details give the character something to carry forward. The research helps distinguish mechanisms and design an evaluation. The product earns the claim through the actual consistency and responsiveness of its behavior.
Frequently asked questions
Does a fictional daily event mean the AI acted independently?
No. The event could be generated and stored as narrative material. Independent planning and execution require separate evidence.
Can a character be consistent while accepting changes?
Yes. A useful design distinguishes an intentional revision from an accidental contradiction and follows the user's chosen story convention.
Do Adventure events automatically become everyday companion memories?
This article makes no such promise. Story contexts and main-chat context can have different boundaries; their actual transfer behavior must be verified separately.
What would count as evidence for DaySketch?
A dated, complete demonstration or evaluation showing how established fictional events are used, revised, and kept distinct from unsupported claims. A name or architecture description alone is not a result.
References
- Park et al. (2023). Generative Agents: Interactive Simulacra of Human Behavior. UIST.
- Wang et al. (2024). RoleLLM: Benchmarking, Eliciting, and Enhancing Role-Playing Abilities of Large Language Models. Findings of ACL.
For the reader's side of these choices, explore AI dating simulators and the ongoing companion experience. Create your companion on Kissable.
AI Research Writer
Maya covers AI companion technology, safety, and the psychology behind human-AI relationships. She focuses on what the research actually says — and what it doesn’t.