How do AI girlfriends work?
The interesting engineering in an AI companion is not the model. Everyone has access to roughly the same models. The interesting part is everything that happens in the fifty milliseconds before your message reaches one — and that is where platforms differ enormously.
This is a walkthrough of that pipeline. It assumes you know what a language model is and nothing else.
What happens when you hit send
Your message does not go to the model. A prompt goes to the model, and your message is the last few lines of it. Assembling that prompt is the platform's actual product.
A typical assembly, in order:
- The system instruction — global rules. Stay in character, never claim to be human, refuse these categories, write in this format.
- The character card — who this character is. Usually the largest fixed block.
- The memory summary — a compressed account of everything that happened before the part that still fits verbatim.
- Retrieved facts — specific stored details judged relevant to what you just said.
- The recent transcript — the last N messages, verbatim.
- Your new message.
The model receives all of that as one blob, predicts a reply, and the platform streams it back. Then the whole thing is thrown away and rebuilt from scratch on your next message. The model remembers nothing between requests. Every impression of continuity is manufactured by that assembly step.
The character card
The card is the character definition — appearance, backstory, personality, speech patterns, boundaries. Two design decisions about it matter more than their length suggests.
Voice matters more than facts. A card written as a list of attributes ("age 27, likes hiking, sarcastic") produces a character who recites attributes. A card written in the character's own first-person voice produces one who sounds like a person. Same information, very different output, because the model imitates the register it is given.
Length is a real trade-off. A richer card gives a more distinctive character, but every token it occupies is a token unavailable for conversation history. A very long card on a small context window means the character is vivid and forgets everything you said an hour ago.
The context window is the whole ball game
The context window is the hard ceiling on how much text a model can consider in one request, counted in tokens — very roughly, a token is three-quarters of a word.
Everything in the list above shares that budget. So the window size determines the fundamental trade-off of the entire product:
| Context budget | What it buys | What gives |
|---|---|---|
| Small | Cheap, fast replies | Character forgets within days; card must stay thin |
| Medium | Coherent multi-session relationship | Older history heavily summarised |
| Large | Weeks of verbatim history plus a rich card | Cost per message rises steeply |
This is also why context window is the spec most worth asking about and the one least often published. It is the single number that predicts how a companion will feel in month two rather than minute two.
How memory actually works
Once a conversation exceeds the window, the platform has to choose what to lose. Three strategies are in common use, usually combined.
Rolling truncation
Drop the oldest messages. Trivial to build, and the reason cheap implementations develop amnesia with a sharp edge — the character remembers this week perfectly and last week not at all.
Summarisation
Periodically ask a model to compress older history into a short note, and carry the note instead of the transcript. Far better, but lossy in a specific way: summarisers keep plot and drop texture. What survives is "they discussed her job"; what vanishes is the joke she made about her manager, which is the part that made the conversation feel like a relationship.
Retrieval
Store facts as discrete entries and pull back only the ones relevant to the current message. This is how a companion recalls your sister's name in month three: the fact was extracted and stored, and your mention of "my sister" retrieved it. Retrieval fails in the other direction — it surfaces things that are lexically similar but contextually wrong.
Why characters drift
Character drift — where a distinctive character slowly flattens into generic-assistant voice — has a mechanical cause worth understanding, because it tells you what to do about it.
At the start of a conversation the character card is most of what the model sees, so its influence is overwhelming. Two hundred messages later the card is unchanged but the transcript is enormous, and the card is now a small fraction of the prompt. Models weight recent text heavily. So the model increasingly imitates the conversation rather than the character — and if the conversation has drifted bland, it reinforces bland.
Two practical implications:
- Drift is worse on platforms that summarise aggressively, because summaries are written in neutral prose and neutral prose is what the model then imitates.
- The fix on the user side is to re-establish voice — respond in the register you want back. The model is mirroring you more than you think.
How the face stays the same
Text-to-image models are stateless too. Ask one for "a woman with red hair" twice and you get two different women. Getting the same character every time requires deliberate identity conditioning, typically some combination of:
- A fixed seed — the random starting point held constant, so the same prompt lands in the same region of the model's output space.
- A reference image — the character's canonical face fed in alongside the prompt as a visual constraint.
- A small trained adapter — a lightweight set of weights taught this specific face, applied at generation time.
This is the fastest way to judge an implementation. Generate the same character in three different scenes. If the face survives, there is real identity conditioning behind it. If it doesn't, the platform is passing your text description to a generic model and hoping.