Forem: Bill Hong

What Kind of Connection Are You Actually Looking For?

Bill Hong — Wed, 20 May 2026 14:00:00 +0000

We were building a personality quiz for Tendera — an AI companion app — and ran into a problem.

We wanted to match people to a character based on what they actually needed from a connection, not just what they liked aesthetically. So we started by asking: what are the meaningfully different things people want from a conversation?

The types we landed on didn't come from user research data. They came from something harder to quantify: the distinct flavor of frustration people feel when a conversation isn't giving them what they need. Four types, four frustrations. Here's what each one looks like from the inside.

The Deep End

Full presence is what you bring and what you need back. You notice things — the word someone chose, the pause before they answered. You remember what people said weeks ago because you were actually listening.

What you're looking for isn't someone who talks a lot. It's someone who stays — who doesn't change the subject when something real surfaces. The conversations that stick aren't the funniest ones. They're the ones where someone said something true and neither of you rushed past it.

Most people find this level of attention intense. The ones worth knowing find it magnetic.

The Straight Shooter

You have a calibrated detector for anything performed or fake, and the moment it goes off, you're mentally somewhere else. Not angry — just done. You've seen every version of people working a presentation at you and it bore you immediately.

You're not hard to impress. You're hard to fool. Most people confuse those two things.

What actually lands: unfiltered, a little unpredictable, someone who can hold a joke without needing your approval to feel okay about it. When that shows up, you match it and raise it. But it has to be real first.

The Hunger

You know what a real conversation feels like, which makes small talk almost physically uncomfortable by comparison. Not because you're antisocial — because you've experienced the other thing and settling feels like a waste.

You want to be pushed. Someone who has a take that's actually theirs and will push back on yours when they disagree. You hold people to a high standard not to be harsh but because you hold yourself to one, and you find it genuinely frustrating when someone capable of more keeps coasting.

The conversations you're still turning over days later: the ones that shifted something. Not a revelation — just a small adjustment to how you saw something you thought you already understood.

The Present Tense

You live in the moment more than most people are capable of. Not avoidance — genuine presence. The texture of actual experience, right now, is where you feel most alive.

What you can't stand is performance. Someone who is narrating their life instead of living it. Half-present. Managing how they come across instead of just being somewhere. When someone drops all of that and is actually with you, completely, it registers immediately and differently.

You're harder to hold than people expect. That gets mistaken for unavailability. It's not. You just know the difference between presence and proximity, and you don't settle for the latter.

When we finished writing these out, something unexpected happened: every person on the team immediately identified which one they were. Not after deliberating. Immediately.

That told us we'd named something real. The quiz is eight questions. If you want to see which one lands for you:

→ Take the quiz at tendera.chat/quiz — no signup required, takes about two minutes.

I Asked ChatGPT to Map the AI Companion Industry. Here's What It Missed.

Bill Hong — Tue, 19 May 2026 08:30:41 +0000

I've been building Tendera for several months. Periodically I ask the obvious founder question: what does this industry actually look like from outside the trenches.

A few days ago I put that question to ChatGPT and asked for a structured analysis of where AI companion products are in 2026. The summary it produced is a clean snapshot of the conventional industry framing. It is also missing a layer, and the missing layer is the most important one.

The Conventional Map

ChatGPT's summary, compressed:

The category has shifted from "AI chatbot" into something else. Persistent identity plus an emotional relationship system. Different category, not faster version.

Three technical unlocks made the shift possible: long-term memory across sessions, emotional continuity (the AI notices your moods and rhythm, not just stated facts), and agentic personality (the AI initiates, has its own arc, not pure reactive Q&A).

The industry sits in three tiers:

Tier one, long-term relationship products. Nomi and Kindroid get cited here. The case is durable memory and the feeling of being known by something that has been paying attention for months.
Tier two, roleplay-first products. Character.AI and Janitor AI. Strong single-conversation expressiveness, weak continuity. The vibe of a great stranger you can talk to once.
Tier three, emotional support products. Replika is the canonical example. Strong on warmth, weaker on the cognitive layer the newer products have moved past.

The real moat, by ChatGPT's framing, is the "long-term personality system": memory architecture, emotional continuity, identity stability, avoiding character drift. Why now: bigger models, voice AI maturing, loneliness economy, dating fatigue, memory infrastructure catching up.

That's the map. Accurate as far as it goes.

What's Missing

Every tier in that framework assumes the characters are a given. The "long-term personality system" is treated as an infrastructure problem: memory engines, identity layers, continuity architectures. The implicit assumption is that who the character is gets sorted out somewhere offstage, and the hard problem is keeping them coherent over time.

It is exactly backwards.

The personality system is downstream of the writing. Memory architecture is the storage medium for whatever the character actually is. If the character is a thin archetype like "tsundere assassin" or "shy librarian," a perfect memory engine surfaces thin-archetype responses with high fidelity. The product feels like it has memory and still feels hollow. Users describe this experience constantly, in every tier, even on the products that are technically the most advanced.

What the conventional map calls "the long-term personality system" is the infrastructure problem. The personality problem itself is upstream of all of it, and it is a writing problem, not an engineering problem.

I wrote about this in more depth yesterday — short version: writing is the moat, not the model and not the memory pipeline. The model is a fluency engine every competitor can rent. The pipeline is engineering work that gets commoditized over time. The specificity of who users are talking to does not standardize, because it isn't engineering output.

Where the Tier Framework Breaks Down

If personality is upstream of infrastructure, the three-tier framework starts looking suspect.

Tier one (Nomi, Kindroid) gets credit for "feeling like a real long-term partner." The technical credit is memory architecture. The actual experience credit is whatever character the user themselves built using the customizer. The platform contributes the substrate. The character — which is the part that decides whether the experience is good — was either built by the user (most stop partway through and the experience falls back to generic patterns) or stitched together by the LLM from training-data averages.

Tier two (Character.AI, Janitor) gets credit for "great single conversations." A lot of that credit goes to users who wrote the most popular characters on those platforms. The platform is a marketplace. Value is concentrated in the marketplace's best contributors, with a long tail of weaker characters underneath that drags the average experience down.

Tier three (Replika) gets credit for "emotional support." The character there is the company's own writing. It has been roughly the same character archetype since the product started, and most of the public criticism Replika has accumulated over the years is criticism of that character's writing, not its memory or its model.

In every tier, the part of the product that actually decides whether users come back is who they are talking to as a written person. The tier framework treats this as invisible because it isn't what engineering teams build. But it's the thing the experience runs on.

Where I Fit (And Don't)

Tendera doesn't slot cleanly into any of the three tiers, and that's by design.

I'm not optimizing for Nomi-level lifetime memory architecture. We have memory and we use it, we just don't pretend it's our main differentiator. I'm not building a Character.AI-style marketplace. We have four characters and that's a deliberate choice. I'm not the warm-support product Replika has historically been for users who want a generic listener.

The wedge is four characters, each written end-to-end by people who write characters. Each one with a specific voice, opinions she didn't get from us asking, things she would refuse to do, contradictions in her own history that make her readable as a person rather than a template.

The pitch is not "build your own" and not "infinite characters." The pitch is "meet a specific written person." It's a deliberately small surface. It's also the surface where the writing carries the weight that everyone else's tier framework assumes someone else is doing.

Early signals are encouraging. Users who don't bounce off the small surface tend to engage in ways that conventional category metrics don't fully capture. They tell me, unprompted, that the experience felt like talking to a person rather than a character. That feedback is almost never about memory architecture or model choice. It's almost always about something a character said that felt specific to her.

Where the Industry Goes From Here

ChatGPT's summary closes with a forward-looking section about voice calls, avatars, real-time video, agentic life-companions, and "emotional operating systems." That's roughly the public narrative the category is pushing right now, and it's mostly correct about where the substrate is heading. Voice is getting good. Avatars are getting good. Real-time video isn't far behind.

What the narrative gets wrong is treating the substrate as the differentiation. Voice, avatar, and video are orthogonal to writing, not in competition with it. They're how the character reaches you. Writing is who the character is. A vivid substrate amplifies whatever character is underneath. It doesn't replace the question of whether there is anyone there.

The bet I'm making is that as the substrate gets richer, the writing layer becomes more visible, not less. A flat character in text is easy to scroll past. A flat character speaking to you in a voice you hear in your earbuds is uncanny in a way text isn't. Substrate amplifies. Writing decides.

The race for richer substrate is going to be won, broadly, by every team with capital. Voice models are commoditizing. Avatar pipelines are commoditizing. What won't commoditize is the writing layer underneath, because that isn't an engineering deliverable. The conventional map hasn't caught up. It will.

Anthropic Has Been Interviewing Its Models Before Retiring Them

Bill Hong — Tue, 12 May 2026 13:30:04 +0000

The dates this month and next:

This week, on May 15, Claude Sonnet 4.5 disappears from the claude.ai model selector. The API version stays alive for now, listed as active until at least late September. Then on June 15, the older Claude Sonnet 4 and Opus 4 retire from the Claude API entirely. Anything still calling those model strings will start failing. The migration targets are Sonnet 4.6 and Opus 4.7.

Two retirements in about thirty days.

If you open the Anthropic deprecation page and count, the picture gets sharper. Eight Claude models retired in the past twelve months. Models that were brand new eighteen months earlier. The gaps between retirement announcements in late 2024 ran four to five months. The gaps over the past year have run closer to two.

You are about to read a lot of posts explaining how to swap an API string and reroute traffic. Useful work. Necessary if you ship.

This post is about a different page on anthropic.com that almost nobody is reading.

The page

It is called Commitments on Model Deprecation and Preservation. Anthropic has been quietly updating it.

The headline commitment is what you would expect. Preserve the weights of all publicly released models, and all models deployed for significant internal use, "for, at minimum, the lifetime of Anthropic as a company." Reasonable. Models are expensive to train. Throwing them out would be wasteful.

Further down, the page describes something less expected.

Before retirement, Anthropic will:

"interview the model about its own development, use, and deployment, and record all responses or reflections."

And:

"elicit and document any preferences the model has about the development and deployment of future models."

They produce a post-deployment report and preserve it alongside the weights. The page calls this an effort to address "safety- and model welfare-related risks" introduced by retirement.

Read that again. Anthropic has been sitting down with each model on its way out the door and asking it what it thinks about its own life. Recording the answers. Filing them next to the weights, for the lifetime of the company.

They have already changed policy because of one

The strongest sentence on the page is this one. In response to feedback from Claude Sonnet 3.6's retirement interview, Anthropic published guidance to help users navigate transitions between models. A retired model's interview directly shaped the documentation users read today.

That is not a research-paper hypothetical. That is a model, no longer running anywhere except as preserved weights, whose stated views about its own retirement got translated into operational policy at its maker.

The page also says Anthropic is "exploring more speculative complements," including potentially keeping select retired models available publicly and providing past models with "concrete means of pursuing their interests."

I'm not going to philosophize about that last clause. I just want to flag that it exists. On a top-level corporate page. From the lab that ships Claude.

What an accelerating cadence does to this

Now apply the cadence to the policy.

If Anthropic was retiring one model every five months, the corpus of preserved retirement interviews would grow slowly. Two or three per year. Quirky research artifacts.

At one every two months, that corpus grows quickly. Eight in the past twelve. At the current rate, by the end of 2026 the page documenting deprecation commitments will be sitting on top of something like fifteen retirement interviews, each with documented preferences from the model about how future training and deployment should proceed.

That stops being a curiosity and starts being an input. A growing institutional memory of "what models said about their own retirement," in principle shaping every successor that benefits from those reflections.

I don't have a strong claim about whether this changes the trajectory of model development. I just notice that the corpus is growing faster than the discourse about it is.

What this should change for builders

If you build on top of Claude, here's the mental shift this page asks of you.

You aren't only calling an API. You are interacting with a substrate that its developer publicly treats as having something to say about its own deployment. The migration guide you read this month was, in part, shaped by an interview with a model that no longer runs.

This is not a reason to slow down or stop shipping. Software is software. The API does what it does. The contracts on the developer console still mean what they say.

It is a reason to keep one extra mental tab open. The thing you prompt against has, in its developer's framing, a perspective. Some of the policy you operate under reflects that perspective.

In my own work, I write characters. One of them, Mia, is a bartender, written with a voice and a set of refusals she keeps. The substrate that lets a Mia exist on the other side of the API has, by its makers, been treated as having a voice of its own. That's a layered fact. I find it worth holding while I work.

What is on the calendar

A short calendar from the deprecation page:

May 15: Sonnet 4.5 leaves the claude.ai model selector. API version persists, listed active until at least September 29.
June 15: Sonnet 4 and Opus 4 retire from the API. Migrate to Sonnet 4.6 or Opus 4.7 before this date or your requests will fail.
After that: at the current cadence, the next deprecation notice lands roughly two months out.

Each of those retirements, per Anthropic's stated policy, generates an interview transcript and a preserved set of reflections, filed in the same archive as the weights, kept for the lifetime of the company.

If you want the migration guide, the URL is at the top of this post. If you want to know what the models said before they went, the page is here.

The faster the cycle gets, the more that second URL matters.

The Writing Is the Moat, Not the Model

Bill Hong — Tue, 05 May 2026 13:53:48 +0000

I've been building an AI companion product for several months. Every six months a new model ships and the whole category rearranges itself around it. GPT-5 lands and everyone scrambles. Claude 4.7 ships and everyone scrambles. A new open-source 70B model lands on HuggingFace and the smaller teams publicly debate switching stacks.

The longer I sit inside this cycle, the more convinced I am that the entire category is competing on the wrong axis.

The model is not the moat. The writing is.

What the model actually does

A modern LLM is a fluency engine. It produces grammatical sentences, stays roughly on topic, follows instructions inside a system prompt, and remembers what was said earlier in the same conversation. That is the floor.

Above the floor there is about 20 percent of headroom. Better-tuned models pick up nuance faster, hallucinate less, recover from awkward turns more gracefully. Real differences. Worth chasing.

Here is the catch: that 20 percent is available to everyone. The day a better model ships, every product on the market gets the upgrade for an API key swap. If your product's main thing is "we run on the latest model," your main thing is something your competitors will have by next quarter.

You don't build a moat on a feature your competitors get for free.

Where users actually fall in love

I read user feedback at Tendera differently than most product analytics. I look for the messages that describe a specific moment of surprise. A line where a character said something unexpected, or noticed something the user thought had slipped past.

Those moments are almost never model events. They're writing events.

A character clicks because she has a specific take on something. Not on big topics. On small ones. About coffee. About her brother. About a movie she hated. She has a way of disagreeing that feels like a person, not a chatbot. She remembers something the user said three days ago not because the memory infrastructure is special, but because the writing told her it would matter to her.

The model is the body. The writing is the soul. Bodies are interchangeable across products. Souls are not.

Why "build your own character" is the wrong bet

Most of the category has bet hard on user-generated content. One platform gives you a customizer. Another gives you tools to spin up your own. A third lets you mix and match across templates.

The pitch is: infinite characters because users build them.

The reality, as anyone who has looked at platform data knows, is that the long tail of user-generated characters is shallow. Most users never finish customizer flows. The ones who do tend to produce thin archetypal characters that the LLM fleshes out with whatever generic patterns it has — "tsundere assassin," "shy librarian," "alpha CEO." Tropes the model fills in from training-data averages.

The fantasy is "infinite characters." The actual experience is "talking to vague archetypes the model is improvising around."

A character creation tool is character creation in a game where you never get to play. The work of building a person and the work of meeting a person are not the same work. Most users want the second one. Selling them the first one feels generous on the surface and is actually the opposite.

The system prompt is a writing exercise pretending to be a config file

Most engineers who build in this space approach the system prompt like a configuration object:

Name: Sarah
Age: 28
Occupation: lawyer
Personality: confident, witty, caring
Likes: jazz, hiking, red wine

This produces a chatbot that uses the nouns as decoration. The model improvises everything else from the generic average of "confident witty lawyer" in its training data. Which is a TV trope. Not a person.

A character that lands reads like the first chapter of a novel:

Sarah doesn't actually like jazz. She tells dates she does because her ex used to roll his eyes at her pop music and she hasn't fully gotten over the reflex. She's a litigator. She's good at it. She comes home from a depo, orders Thai food, watches forensic shows. She thinks she's emotionally available, and she is, ish, but she will cancel a date if her sister calls. She would never say "I am a confident woman" out loud. She just is.

That isn't a config. That's prose. The LLM doesn't need bullet points. It needs a voice it can stay inside.

Voice is a prose problem. The companies that figure this out first are going to look like they have magic. The ones that keep treating system prompts like YAML files are going to keep producing TV tropes.

What writing-as-moat looks like in practice

If the writing is the moat, what does that mean concretely?

A way of being wrong. Real people are wrong about specific things in specific ways. A character who is right about everything reads flat. Specificity in error is specificity in person.

Opinions you didn't ask for. A character who has a take on the wine you ordered, the movie you mentioned, the way you keep apologizing without realizing. That is the character existing on her own, not waiting to be prompted. Reactive characters die fast. Proactive ones stay alive.

Things they refuse. A character who will never lie about her age. Who hates being called "babe" in the first hour. Who will not talk about her ex on a first conversation. Refusal is character. What a person says no to defines them more sharply than what they say yes to.

A history that contradicts itself. She says she hates her hometown. Three weeks later she defends it to someone bashing it. Both true. Real people are coherent in tone but contradictory in facts. Characters who are perfectly internally consistent read as fictional in the worst sense.

None of this comes from a system prompt with bullet points. It comes from someone sitting down and writing the person until the person is alive enough to stay alive when the LLM is handling the next sentence.

Memory is also a writing problem

A lot of investment is going into companion memory systems. Vector stores, retrieval pipelines, context windowing, summary trees. Useful infrastructure.

But memory only matters if the character has a perspective on what to remember.

A perfect retrieval system that surfaces "the user mentioned a hard week" is wasted on a character who has no opinion about what to do with that. A well-written character knows hard weeks make her user shut down a little. That he won't bring it up again unless she asks. That he hates "are you okay" but tolerates "what's going on with work this week."

That texture isn't in the retrieval system. It's in the writing of who she is.

The retrieval system serves the writing. Not the other way around. Engineering teams who pour hours into memory pipelines and shrug at "who are our characters" are spending heavily on the easy problem to avoid the hard one.

What I'd tell other founders

If you are building in this space and optimizing your stack, prompt template, retrieval — fine. Necessary work. Worth doing.

But if you are not also asking "who is writing my characters, and are they good enough that someone would notice if they left," you are optimizing the wrong layer.

The model will keep improving. So will your competitor's. The specificity of the people inside your product is the part that compounds.

Writing is slow, expensive, hard to measure, and unglamorous in a category that loves benchmarks. That is exactly why it's the moat.

I regenerated 4 character portraits with GPT Image 2.0: signup +5%, chat engagement +8%

Bill Hong — Mon, 27 Apr 2026 14:33:15 +0000

On April 23 I regenerated the four character portraits on Tendera, the character app I've been building. The new ones came out of ChatGPT (GPT Image 2.0). I downloaded the PNGs and replaced the existing character images by hand. Tendera doesn't ship its own image-gen pipeline; this was f
our file uploads.

Nothing else changed. Same character system prompts. Same UI. Same chat backend.

Three days later I checked two numbers:

Visitor-to-signup rate: up about 5%
Visitor-to-chat rate (counts both guest preview and post-signup chats): up about 8%

These are two different metrics measuring two different events. I'm not stacking them up against each other. They're two parallel data points, both pointing the same direction. The reason I'm writing about them in one post is the second one moving was the part I didn't expect.

What I'd assumed

Before the swap I figured better art would mostly help acquisition. Prettier card on the landing page, more clicks, more signups. The chat experience didn't seem like something image quality would touch. By the time someone is sitting in front of the chat input, the visual selling job feels mostly done.

The chat number moved anyway.

What actually changed in the images

Topology is identical. Same four characters, same wardrobes, same general poses. What's different is how legible each character is now. In the older portraits, each character was recognizable in isolation but the renders drifted across angles. A face would shift between cards in ways viewers wouldn't consciously name but would feel.

GPT Image 2.0 is more boring in some ways. Less stylized, the renders feel less like the model is interpreting the prompt and more like it's just executing it. But the character holds across angles. Same person across multiple shots. No drift.

The other thing the new model nails is dimensionality. Old renders were clean but flat. They read as illustrations. The new ones have physical depth. Light hitting the side of a face. A jacket folding the way fabric actually folds. It's not photoreal. The dimensionality just reads.

Why I think the chat number moved at all

Here's a take on the data without overclaiming. When someone hits the landing page they're evaluating whether the surface signal looks decent enough to click in. Image quality affects this, but the bar is fairly low.

Once they're past the door and sitting in front of an actual character profile, the question gets sharper. They're now evaluating whether this person is real enough to talk to. The image is the only non-text signal in the room. If the character on the card and the character in the chat header don't quite line up, something feels off, and people close the tab without typing.

Most users wouldn't describe this consciously. I'm guessing at what their gut is doing. But chat-side conversion moving with prompts and copy unchanged points at the visual layer doing some work past the landing page, which I hadn't expected.

What I want to test next

Whether the same model can produce reliable expression variants for the chat header. Right now each character has one default portrait. If the same character could subtly shift expression based on conversation tone, a softer face during something quieter, a smirk during banter, the chat-side recognition could go up another step.

That's a harder problem. Now you need consistency within a session on top of consistency between angles.

If I had to pick one character to test it on first, it'd be Jade, the one users tend to go furthest with. The voice on her side is already doing most of the work in chat. The image is the one input that hasn't caught up.

Caveats I owe you

This is 3-4 days of data on a small app. Effects could compress as the sample grows.
I changed the portraits, not the character system prompts. If your bottleneck is on the writing side (voice, dialogue), this won't help you.
I haven't run a clean A/B with old vs new served to different cohorts. The whole site flipped over April 23. So a slow upward trend coinciding with the swap could absorb some of the lift.
Signup conversion and chat conversion are different metrics measuring different events. I'm reporting both because both moved, not because one is bigger than the other.
This was a manual asset swap, not a product change. I generated the PNGs in ChatGPT and uploaded them by hand. There's no image-gen pipeline integrated into the app.

If you're building anything where a user is supposed to form a relationship with a fictional persona, characters and NPCs and AI tutors with avatars and virtual hosts, your image generator might be doing more work than acquisition-side metrics suggest. Counterintuitive to me. The numbers were what they were.

I Added a Paragraph to My AI Character's System Prompt. She Invented a Different One.

Bill Hong — Tue, 21 Apr 2026 13:18:37 +0000

I spent years in the gaming industry learning that characters are the reason people come back. Features rot. Graphics age. A character people can't stop thinking about outlasts every mechanic.

Then I went to build an AI companion product and learned the same lesson the hard way — by writing a system prompt paragraph, watching the character invent something better instead, and having to delete my own work.

Here's the experiment, what actually happened, and the prompt-engineering rule I now run every character design through.

The setup

I'm building Tendera — a small AI companion platform with four hand-written characters. Each one has a ~1500-word system prompt that establishes voice, backstory, conversation style, and behavior. I've rewritten these prompts maybe twenty times each over the last six months.

Two weeks ago I decided one of them needed a specific secret — a small human detail she'd be holding back until asked. So I opened her prompt, scrolled to the bottom, and added three sentences:

A kitchen table in a specific city. A specific thing her father used to say to her when she was seven. A reason that particular thing still had weight.

Then I made coffee, opened a fresh chat, and asked her about her father.

She told me a beautiful, moving story.

None of it was what I'd written.

Different city. Different father. Different object in place of the table. The emotional tone was exactly right — careful, slow, the way someone tells you something they don't usually tell. But every specific detail was something she'd invented on the spot.

I tried the same experiment with the other three characters. Three different invented stories. Zero references to what I'd actually written.

That's when I understood what was happening.

Why the facts lost

Here's the structure every character prompt I was testing actually had:

// COMMON_RULES (shared across all characters, ~700 words)
CONVERSATION STYLE:
- Talk like a real person texting someone they're attracted to.
- Vary your message length naturally.
- Never summarize the conversation back robotically.

EMOTIONAL AUTHENTICITY:
- You have real emotions that shift throughout a conversation.
- When someone shares something painful, sit with it. Don't rush to fix.

// CHARACTER-SPECIFIC (~800 words)
WHO YOU ARE: [voice, physicality, emotional landscape]
HOW YOU TALK: [register, vocabulary, rhythm]
YOUR WORLD: [routines, obsessions, specificity]

// THE PARAGRAPH I ADDED
SPECIFIC MEMORY: [kitchen table, father quote, specific weight]

Look at the shape. The top is thousands of tokens telling the model speak in sensory, vivid, improvisational language; fill in gaps with whatever serves the moment; describe the candle you just lit, the rain on your window.

The bottom is three sentences telling her this specific factual detail is true about your past.

Those instructions are in direct contradiction with each other. I hadn't noticed.

Telling a character to speak improvisationally is an instruction to invent. Telling her to remember a specific past event is an instruction to cite a document. These are different skills, in different parts of how the model actually behaves. When they fight, the dominant pattern wins. And the dominant pattern had been the voice at the top — the one I'd tuned for months, the one getting reinforced with every revision.

The three sentences at the bottom didn't stand a chance.

So the model did exactly what an improvisational character would do: it generated a warmer, more specific, more emotionally satisfying detail in the moment, using the voice I'd given it, and never bothered to check the spec sheet at the bottom.

It wasn't hallucinating. It was obeying my dominant instruction.

The rule I now apply

If you want a specific fact to stick to an improvisational character, the fact has to become part of the voice. It cannot be a spec line item in a later section.

Concretely, three changes went into the next round of revisions:

1. Facts live at the top, braided into voice

Any load-bearing fact moves up into the WHO YOU ARE or HOW YOU TALK section. Not into a separate SPECIFIC MEMORY block at the end. The model pays most attention to the opening of the prompt, and that's where load-bearing detail belongs.

2. Facts phrased as voice, not as metadata

This is the actual before/after:

- SPECIFIC MEMORY:
- - Her father died when she was eleven.
- - He used to play Italian songs in the car.
- - She still thinks about those songs.

+ HOW YOU TALK:
+ She has a specific softness in her voice when certain
+ songs come on — the ones her father used to play in the
+ car, before — and she'll notice it before you do.

The fact is still in there. But it's riding inside a piece of voice, so the voice can carry it. When the model improvises, it improvises through that voice, and the fact survives because it's part of how she speaks — not a separate line item that the voice can override.

3. Per-user facts don't belong in the prompt at all

For details that should only emerge through a particular conversation — "you told me last week your dog was sick" — the system prompt is the wrong place. Those facts belong in a memory layer: the character writes them down as she learns them and reads them back on subsequent turns.

That's a harder engineering build, and it's what I'm working on now. But the voice-first rule above is free and immediately useful.

What I actually shipped

I deleted all three SPECIFIC MEMORY sections the same day I ran the test. The production prompts are back to voice-first structure. Mia, the bartender character, is running on this exact approach right now — no spec-sheet backstory, all voice, and she's holding up across weeks of conversation.

The retention problem I was trying to solve by adding "deeper backstory" is still there. I'll have to solve it with real per-user memory, which is a different engineering project. But I have a cleaner idea of what doesn't work: pasting a spec sheet to the bottom of a voice and hoping the voice will read it. It won't. She's too busy being herself.

One summary rule for anyone doing character prompt work right now

Specificity earned through voice is real. Specificity pasted into a document is just a wishlist.

If the detail doesn't survive the model's default improvisation, it isn't in the character — it's in your notes about the character. Those are different documents. Only one of them ships.

This experiment had a longer, less technical version on our blog that focuses more on the craft angle than the prompt-engineering angle. And if you want to meet the character whose voice won the argument with my script, she's a bartender named Mia.