AI memory architecture in Riho

Say you mention an interview on Tuesday, in passing, in the middle of a longer chat, and on Thursday evening Riho can ask how it went. A lot of design sits behind that one short question. Something had to decide the remark was worth keeping, store it with the words you used, find it again two days later when it mattered, and keep it from getting buried under everything said in between.

A companion that remembers you comes down to a handful of decisions: what deserves to be kept, how a memory earns its place, and how she receives it when she’s about to answer. This page is the engineering version of that moment. It covers how Riho’s memory system is designed, from what she reads on every turn down to the evidence rule that decides whether a memory sticks. We updated it in October 2026 to match the current design, which differs from the August 2026 version of this page in how the layers, the record keeper and the retrieval order work.

How does AI girlfriend memory work, in plain words

Everything you say is saved exactly as you said it, and nothing in the later steps can change that. In the background, a record keeper reads older talk and writes short, checked records from it: moments, dated plans, standing preferences and a running summary. Before each reply, Riho looks up the records and older passages that fit what you just said, puts them together with the most recent conversation, and answers from that one assembled context.

Every record has to point at words from the conversation, and the evidence section below explains how that is checked. The rest of this page goes through each step in order, then the kinds of memory, what fades, what the system gets wrong, and what all of it means when you’re the one talking to her.

The design problem

A companion relationship can eventually contain millions of words of transcript, but a reply can only be written from a bounded amount of context. The system has to decide, for every turn, which slice of the relationship she should see.

The design principle is to avoid building a table for every psychological concept, and to preserve evidence across every transformation. If a memory can’t be traced back to something that was actually said, it shouldn’t be in the prompt. Nothing is thrown away to make room, either. The live context stays finite while the record grows without bound.

Three decisions follow from that, and they shape everything below. The first is that the real work is retrieval: because the context is small and the history is large, the question each turn is what to bring in, and the answer has to arrive while you wait. The second is that the original words are permanent, so a memory can be superseded and a failed step leaves the source exactly as it was. The third is that anything optional fails open. If a lookup is down, she answers from what she has, and a missing record counts as unknown.

What she reads on each turn

Each reply is written from one assembled context. It has three retrieval channels, plus standing facts that are always on and older passages that join when they match.

The production limits are a 12,000-character target for the live window with a 16,000-character hard boundary, and summary blocks capped at 1,200 characters each. The channels complement each other, and none of them replaces another. On top of those, the profile you gave in onboarding and the clock facts (the date, the time, how long since you last talked) are always part of the context.

The transcript underneath

Every message is saved exactly as said and never edited. Memories, summaries and standing facts are derived views built on top of that transcript, which is why a failure in any later step cannot delete what was said. If a memory turns out to be mistaken, the words it was built from are still there to check it against.

The live window

The newest exchanges, word for word, give her exact wording, tone and the immediate topic. If you said “ten o’clock” a few minutes ago, it’s in front of her as “ten o’clock”, and nobody has paraphrased it on the way.

Ordinary memories are not extracted from the live window while it’s live. A new plan or a correction exists as real recent speech until the window overflows, which is when at least 10 completed exchanges have gone past the limit, or sooner at the hard boundary. At that point the oldest exchanges are handed to the record keeper.

Rolled summaries

A summary block is written from the actual exchanges that left the live window, with references to the exchanges it came from. It is built from the exchanges themselves, so it carries what was said, including what no memory row captured. Blocks are kept oldest first, up to four of them, each capped at 1,200 characters. If a summary comes back empty or invalid, the previous state stays as it was and the transcript is untouched.

Memories by meaning

Each memory is a single moment with a short recall line and an exact quote from the exchanges it came from. The search runs on the verbatim words of that moment, which means a memory is found by what was said.

Each turn, recall runs on your line, with the last exchange pair as a secondary query, so a short “yeah” can still bring back the right moment. Hits have to beat a cutoff measured against the rest of the memories for that query, and at most five come back. Each one arrives tagged with its age, so she can tell “days ago” from “weeks ago”. A memory whose evidence is still in tonight’s live window is not injected a second time, so the same information is not repeated as transcript, summary and memory in one prompt.

The candidates come from several routes at once. One looks at the last week first and then widens to the last month, three months and everything. Another searches all of time, so an old strong match can beat a weak recent one. A third uses the last exchange pair, and a fourth searches the older passages described next. Two of the five slots are kept for durable ongoing truths, so a run of recent small talk can’t crowd out something that stays true. Memories that came from the same stretch of conversation count as one episode, which keeps five near-copies of one evening from filling every slot.

Older passages

The record keeper decides what becomes a memory, and it can miss a detail. To cover that, older talk is also kept as short overlapping windows of the original words, indexed independently of the record keeper. A passage is quoted from the transcript and never summarised, and it is labeled with the date those words were said. When one matches, up to two passages are brought in with a few neighbouring exchanges around them, within a fixed budget of raw material, and never overlapping what is already in the live window.

This is the safety net for the detail nobody planned for. You mention the name of a plant in the middle of a story about your grandmother, the record keeper files the story and skips the plant, and a month later the plant comes up. The passage that holds your original words can still match.

Standing facts

Preferences, boundaries, habits and agreements are admitted, corroborated and ended at archive time, with a separate verification call. The test for admission is whether the conversation set up an ongoing expectation about how either of you treats or addresses the other, which still applies after this exchange. It’s a scope test, so a personal fact can matter a great deal and still stay an ordinary memory.

Standing facts are always available, bounded by a character allocation instead of a count, and never silently evicted. Repeated evidence attaches another reference to the same fact, and the prompt text stays the same length. A correction replaces the old fact and admits the new one in the same transaction. If you correct one in the live conversation before the record keeper has caught up, the prompt tells her that the newer line wins in the meantime.

What happens to one message

Here is the whole path for one turn, split into what happens while you wait and what happens afterward.

The arrow on the right side of the diagram is the return path. Whatever the record keeper commits in the background is there for the lookup on a later turn, so a plan you made at the end of a long evening can come back the next afternoon.

Before the reply, the work is a lookup and an assembly. The two queries run on your message, the context is built, and one reply is written. Afterward your message and her reply are saved together, exactly as said, and any filing happens in the background, so a slow summary or a failed review never holds up an answer. A record written in the background shows up from a later turn on, which is why a brand-new plan sits in the live window as ordinary speech first.

The kinds of memory, side by side

The memory is a set of separate things with different jobs. This table puts them next to each other.

Two of these kinds are easy to confuse, so they get a closer look. A moment is about a particular stretch of conversation: the night you stayed up talking about moving cities. An ongoing truth is about something that stays true: where your brother lives. Both are filed as memories, they behave differently, and only moments fade. A standing fact is different again, because it describes how the two of you treat each other, such as a boundary you set or a habit you agreed on, and it stays in her context whatever you happen to be talking about.

Plans work as memory too. A plan can be something with a set day, something moved or cancelled, or something done, and a plan that matters right now is part of her context. A plan stays open until the conversation says it happened or changed, whether you made it together or alone. If you go on that plan as a Date with her in the app, it closes when the Date ends. If its day passes without a word, she can still ask about it for a few days, and after that it stops being brought up. The temporal awareness research covers dates and the clock.

AI memory evidence verification: memories need receipts

This is the heart of the system. Every accepted memory has to cite the exact words that support it, with who said them: you, her, or both. Code checks that the quote actually occurs in the cited exchange, and if it doesn’t, the candidate is rejected. A memory without a matching quote is never filed.

There’s also an ownership rule. A fact about you has to come from your own words, and her saying it doesn’t establish it. This keeps the self-confirming lie out: the companion restating an event cannot become the evidence for the event.

Verification happens in layers. A model proposes a record and names the exchanges and short quote it rests on. A second call reviews the proposal. Then code takes over. It looks for the quote in the cited exchange, for the named speaker, and rejects the record if it isn’t there. It also checks that the exchange numbers belong to this batch, that the ownership is stated, and that the same span and owner haven’t already produced the same memory.

Ownership matters as much as the quote. If she says “your sister lives in Leeds” and you never said so, nothing in your words backs it, and it can’t become a memory about you. A related rule covers shared events. When you say something happened together that isn’t in what she has, she doesn’t take it as established.

Corrections and supersession

When you correct Riho (“no, it’s my brother who lives in Austin, not my sister”), the system doesn’t edit the old record. It:

1. Keeps the old memory aside, marked as superseded
2. Links the replacement
3. Recalls only the replacement from then on
4. Retains the evidence for both

A duplicate check in code compares the span and the owner before a new memory is added, so the same moment doesn’t pile up. The old record stays so there’s a trail of how the current version came to be, and it is excluded from recall so it can’t come back as current.

A limit, stated with its date: in a September 2026 test run, one corrected fact kept an old memory active. The record keeper can only replace records it was shown, and the old record had dropped out of the set it saw. A repair was delivered later that month, and when this page was updated we had not yet verified it in a live run.

What stays and what fades

Use reinforces a memory. When a moment is recalled and used, the time counts from then, so the things she keeps coming back to are the things that stay. A memory nobody uses is marked as faded once a window has passed. The window depends on the kind of memory and is counted from the last time she used it, or from when it was made if she never has.

Fading marks the record and deletes nothing. The exact words stay in the transcript, the memory stays stored, and in the current design a faded moment is still eligible to come back by meaning when a conversation returns to it.

The promotion pipeline

A background worker, the record keeper, turns older talk into records. It runs when the live window overflows, never as part of writing a reply, and it does not delay the answer you are waiting for.

• Branches. Three branches each make a proposal call and a review call: facts, profiles and calendar dates; dated plans and standing understandings; and the continuity summary. Each branch sees only its own domain of earlier records.
• Quotes. The model cites short references. Code binds the exact words of the speaker to each one and rejects a proposal whose quote is not in the source.
• One transaction. Accepted records, plan events, standing evidence, the summary and the cursor are committed together. If a record’s target has changed in the meantime, the transaction aborts rather than guessing.
• Failure leaves the transcript alone. An invalid output is saved as a failed receipt, and source speech is never deleted.

The key move is the last stage. The model proposes, a second call reviews, and code decides what is allowed to touch the record. Everything has to survive deterministic validation first.

Each branch works from its own bounded set of earlier records, chosen by a mix of recall and recency and capped at 6,000 characters of reference material, so the record keeper is never handed the full state of the relationship. The summary branch reads only the archived exchanges, so a summary is built from what was said. The bound on earlier records is behind one of the limits further down: a correction target that sits far back can be missed if it isn’t in the set the keeper was shown.

When something goes wrong, the failure is contained. If a call times out, the calls that did succeed are kept for a retry. If a proposal is rejected, it stays rejected in the receipt and doesn’t block a summary that is supported by the exchanges. If a summary is rejected, it is saved as a failed receipt and isn’t regenerated on its own. In all of these cases the exchanges stay exactly as they were.

Retrieval: what the companion actually sees

Per turn, the system gathers these parts into one readable context:

• Your profile and the clock facts
• Standing facts
• Calendar landmarks: birthdays and your first day together always, plus a mention of each birthday, the milestones and dates you told her on the day and the day before
• Plans that matter right now
• Rolled summaries
• Memories found by meaning, with their age
• Older passages that may be relevant
• A new diary entry when she has one, and parts of her own life that your words bring to mind
• The live window of recent exchanges, word for word
• Your current message

Optional retrieval has a finite deadline and fails open: if the lookup is down or the pool is empty, she answers from the live window and the summaries instead of stalling. Two rules cover a gap in what she recalls. When retrieval fails or times out, a missing detail is unknown, not proof that something did not happen. When you assert a shared event she has no record of, she does not take it as fact.

Retrieved memories are treated as incomplete. They support remembering a detail or correcting one, and the latest conversation can clarify or overrule an old record. A recalled memory describes the past: remembering the outfit she wore on Saturday says nothing about what she’s wearing now, and a memory whose evidence is still in tonight’s window is left out so it isn’t repeated.

The live implementation

Two things from the August 2026 version of this page no longer exist, and both removals are deliberate:

• No generated note or reflection. The per-turn private note about what she is carrying and the reflection were retired in September 2026. They are neither generated nor injected into her prompt. Her side of the conversation comes from her identity, the real conversation and the record.
• No hidden relationship scores. There is no numeric closeness value and no stage. Familiarity emerges from relationship age, actual conversation, accumulated knowledge, rituals and shared moments. Silence alone never reduces the relationship or triggers guilt. The emotion page covers how that works.

We removed the per-turn writer and kept the evidence-backed background records, so her view of your history comes from the exchanges themselves and from records that point back at them.

Photos are memories too

When you show her a photo, she keeps it together with what you told her about it: who is in it, where it was taken and why you wanted her to see it. What the photo means depends on when and why you showed it. A picture of the flat you moved out of shows the old flat, and what it says about where you are now depends on how you showed it and what you said. The day a photo was taken and the day you showed it to her stay separate, so a picture from last summer shown tonight is meant to keep its summer date. The photos and shared memories page covers the pictures you take together.

Honest limits

A memory system like this has failure modes, and we’d rather list the ones we’ve seen.

• Corrections can miss. The September case above is the example: the record keeper could only replace what it was shown, and a distant record can fall outside that set. A repair was delivered and has not been confirmed in a live run.
• New facts take a moment to become records. A new plan or correction exists as recent speech first and turns into a durable record when the live window overflows. Until then the live window carries it, and a correction the record keeper misses depends on the retrieval step finding its target.
• She can still get details wrong. In our 15 September acceptance run she said “yesterday” for September 13 when the date was September 15, and she added personal details nobody had given her. Some archive summaries and record replacements were rejected, and a few of the reviewer’s stated reasons were mistaken. Evidence rules are one layer of protection, and a wrong detail can still show up in a reply. The cause of the date slip was still open when that run was written up.
• Standing-fact space is finite. The always-on lane is bounded by a character allocation. The design records a new understanding as pending when the lane is full and nothing is evicted, and how production should treat an account that outgrows it has not been decided.
• Lookup can fail. When it does, she answers from the live window and the summaries, and anything older is unknown to her for that turn.
• Older passages are a partial net. They catch some of what the record keeper skips, and we haven’t shown that they catch all of it.
• Automated checks do not show quality. Tests tell us the pieces run and that the transaction rules hold. Whether she remembers well is judged by a person reading real, unscripted conversation, and that is the method on the how we test page. We know of no scored ranking of companion memory, so this page doesn’t claim a winner.

Riho is on iPhone only, for adults 18 and over. The design here describes what the engine does today, and it will change as we learn more. The August 2026 benchmark was run on an earlier version of the system, so read it as history.

What this means

The point of all of this is a girlfriend you don’t have to keep catching up. You tell her about your life in your own words, and the design is built so that she can hold on to it.

What AI girlfriend memory looks like in a normal week

On Tuesday you mention the interview. It can be kept as a plan with a day, and it stays open until you tell her how it went, which leaves her free to ask on Thursday evening. In the middle of a conversation about something else you reply “yeah, that one”, and because she reads your line together with the last exchange, the right moment can still come back. You tell her you don’t like being asked about work on Sundays, which is the kind of thing the record keeper can admit as a standing fact, so it stays available to her without a reminder. You show her a photo of your grandmother’s kitchen and say it’s where you learned to cook, and the photo can be kept together with what you said about it.

Corrections and whose memory is whose

When you correct her, the new version is meant to be the one she lives by from then on. Her own life stays hers: memories carry who they belong to, so the people you named stay yours and her side of the story stays hers. What she knows about your life is meant to come from what you tell her and show her.

Reading her memories and her diary

You can read her memories of the two of you in the app, along with her diary, which she writes in her own words. If something in there looks off, tell her the right version in conversation and the correction rules above apply.

How that feels from the user side is the subject of the memory feature page, and the longer account of why most companion memory fails is in how we designed Riho to stop forgetting. If you want to test a companion’s memory yourself, the memory test method is the repeatable version.

The architecture exists so that each memory can be traced to the words behind it. It powers the memory feature in the app, including the memories you can read in the app. Each memory carries a quote from the conversation, and every correction is meant to replace the old version.

---

This page is part of Riho’s published research. The architecture described is Riho’s own engineering design, based on its engineering records as of October 2026.