ALL RESEARCH

Memory systems

Mneme: The Shape of Memory in Machines

Five carved memory records entering a black machine interface and emerging as one structured memory form

What an AI model remembers depends not only on what was stored, but on how that past is presented when the model needs it. We compared nine memory conditions using the same histories and questions. The strongest deployable condition turned a shared selection of authorized records into a compact working set.

Farynth ResearchAugust 2026
Read the full paper

Key findings

  • The compiled working set led the deployable methods, reaching 81.76% accuracy for the 4B reader and 90.00% for 9B.
  • Recent-history accuracy declined as the generated history grew, while the compiled working set remained stable or improved.
  • The 9B reader was more accurate than the 4B reader under every deployable memory interface.
  • The result identifies a pattern worth testing across different histories and model families, not a universal ranking of memory systems.

What memory means here

Mneme (pronounced NEE-mee) takes its name from the Ancient Greek mnēmē, meaning memory. An artificial intelligence model answers from the information available in its immediate working context. It does not automatically carry a complete record of earlier interactions from one answer to the next. A memory system reconnects the model with that past by deciding what to preserve, what to retrieve, and how to present it when the model needs it.

By shape, we mean the form that remembered information takes when it reaches the model. In this study, the model that answers is the reader, and the form in which stored history reaches it is the memory interface. Each experimental memory condition implements one memory method. The same past can arrive as a chronological log, a set of search results, linked facts, separate fields, or a compact account of the current state. Each form changes both what the model sees and what it must work out before it can answer.

The right fact may arrive too late, sit inside pages of routine history, or reach the model in a form that obscures how it relates to the question. This study follows the path from stored history to the model's answer and asks how much that final presentation changes the result.

Study design

Nine memory conditions, the same worlds and questions

01Past eventsChanges inside a generated fictional world
02Memory methodRecent, retrieved, linked, typed, or compiled information
03Reader modelQwen 3.5 4B or Qwen 3.5 9B
04AnswerScored against the known state of the world

A fair comparison required histories in which the correct state was known at every step. We therefore generated 256 fictional worlds from one fixed event-and-question template, changing the people, projects, objects, dates, and other tokens in each version. Every world contained the same schedule of decisions, revisions, tasks, noise events, and nine question types.

Every memory method received the same underlying worlds and questions. We measured each history after 4, 16, and 64 sessions (9, 47, and 194 generated event records before shared eligibility filtering) and gave the models two different amounts of working context. This paired design let us change the memory interface without changing the events behind it. In total, the study produced 248,832 scored answers across 864 experimental cells.

Scored answers
248,832
Fictional worlds
256
Memory conditions
9
Session checkpoints
4 · 16 · 64 sessions
Context budgets
4,096 · 8,192 tokens

What the models had to remember

The questions asked for more than simple fact lookup. A useful memory must preserve events, follow changes, connect related records, and distinguish information that still applies from information that should be set aside.

Why these two models

We used Qwen 3.5 4B and Qwen 3.5 9B from the same open-weight model family. The smaller model has about four billion parameters and the larger one about nine billion. This provided a narrow comparison of how two model sizes from one family responded to the same memory interfaces.

Memory conditions

How the past reached the reader

We tested nine conditions: no memory, recent history, lexical retrieval, vector retrieval, graph retrieval, hybrid retrieval, typed memory, compiled state, and a diagnostic expected-evidence selector. Every condition began with the same histories and questions. A shared eligibility rule removed private, deleted, and superseded records and kept the latest authorized record for each state key. After that common step, the conditions differed in what they selected and how they presented it to the model. Seven represented deployable designs. No memory supplied no stored history. The diagnostic selector, labeled Oracle in the experiment files, supplied the records expected to answer each question as a research comparison, not a live method or a performance ceiling.

01
No memoryBaseline

No memory

The model received only the question and an explicitly empty authorized-memory block. This showed how well it could answer without stored history.

02
Recent historyHistory

Recent history

After shared privacy, deletion, and revision rules were applied, the model received as many of the newest authorized events as the context budget allowed.

03
Lexical retrievalRetrieval

Lexical retrieval

The system looked for stored text that shared words with the question and returned the closest matches.

04
Vector retrievalRetrieval

Vector retrieval

The system searched for memories with a similar meaning, even when the question used different words.

05
Graph retrievalRetrieval

Graph retrieval

The system took the four highest-ranked keyword matches as seeds, then expanded two hops through shared entity strings for people, projects, components, databases, relays, and distractor tokens.

06
Hybrid retrievalRetrieval

Hybrid retrieval

The system fused keyword, meaning, linked-record, and recency rankings, then returned up to 24 authorized events.

07
Typed memoryStructured

Typed memory

The system used the same fused event selection as Hybrid retrieval, then labeled each record with its memory type, session, and provenance.

08
Compiled stateStructured

Compiled state

The system used the same fused event selection as Hybrid retrieval, then presented the records as a compact bullet list under a current-working-set heading.

09
Diagnostic expected-evidence selectorResearch comparison

Diagnostic expected-evidence selector

This diagnostic expected-evidence selector, labeled Oracle in the study, supplied the records expected to answer each question. It was a research comparison, not a method a live system could use.

Results

The compiled working set had the highest deployable accuracy

The Hybrid, Typed, and Compiled conditions began with the same fused selection of up to 24 authorized records. Hybrid retained session tags. Typed added memory-type and provenance tags. Compiled removed those tags and presented the records as plain bullets under a “CURRENT AUTHORIZED WORKING SET” heading.

That compact presentation achieved the highest overall accuracy among the seven deployable methods. The 4B model answered 81.76% of questions correctly, and the 9B model reached 90.00%. Because Hybrid, Typed, and Compiled began with the same record ranking, their separation points to the reader-facing representation rather than to a different retrieval result.

Overall accuracy by memory method and reader. Each row is one memory method. A circle marks Qwen 3.5 4B and a square marks Qwen 3.5 9B on a zero-to-100-percent accuracy scale. Hollow marks identify the non-deployable diagnostic expected-evidence selector. The no-memory baseline is 11.11% for both readers, so those two markers coincide. Compiled state is the rightmost deployable row for each reader.
Full chart description

Each row is one memory method. A circle marks Qwen 3.5 4B and a square marks Qwen 3.5 9B on a zero-to-100-percent accuracy scale. Hollow marks identify the non-deployable diagnostic expected-evidence selector. The no-memory baseline is 11.11% for both readers, so those two markers coincide. Compiled state is the rightmost deployable row for each reader.

Overall accuracy for each reader and memory method, averaged across tested session horizons and context budgets. Compiled state was the highest-accuracy deployable condition for both readers. Hollow markers identify the diagnostic expected-evidence selector, which was not deployable. The two reader markers coincide at the no-memory baseline. Source data PDF

The hollow diagnostic markers show the expected-evidence selector. It was included for comparison and was not a deployable memory method or a performance ceiling.

The clearest difference appeared as history grew

Recent history gave the model a chronological window of the newest authorized events. At session 4, the generated history contained 9 event records. At session 64, it contained 194 raw records and 189 records after shared eligibility filtering. The longer window carried far more routine noise, and the 4,096-token condition could retain only part of it.

The difference was visible in both readers. From the 4-session to the 64-session checkpoint, recent-history accuracy fell from 71.88% to 50.74% for 4B and from 85.85% to 53.93% for 9B. The compiled working set did not show the same decline.

Accuracy at 4, 16, and 64 sessions. The 4B and 9B panels each contain three measured session horizons on a 45%-to-95% vertical scale. Compiled-state accuracy rises slightly across the checkpoints. Recent-history accuracy declines modestly at 16 sessions and sharply at 64 sessions, with the larger decline in the 9B panel.
Full chart description

The 4B and 9B panels each contain three measured session horizons on a 45%-to-95% vertical scale. Compiled-state accuracy rises slightly across the checkpoints. Recent-history accuracy declines modestly at 16 sessions and sharply at 64 sessions, with the larger decline in the 9B panel.

Recent-history accuracy declined as the generated history extended from 4 to 64 sessions, while compiled-state accuracy remained stable or slightly improved across the same checkpoints. The vertical scale spans 45% to 95% to make the within-reader change visible. Source data PDF

The shaded bands are exploratory 95% confidence intervals and were not adjusted for multiple comparisons.

Compiled state used about one quarter as much input

Recent history used about 2,241 input tokens per question. Compiled state used about 575, roughly one quarter as many, while producing more correct answers. Input tokens are the pieces of text the model had to read before answering.

Compiled working set575input tokens per trial
Recent history2,241input tokens per trial

The compiled condition changed the serialization of the fused working set: it removed session, type, and provenance tags, added a working-set heading, and used compact bullets. This experiment measured their combined effect. A follow-up study will need to vary those elements one at a time to learn which parts supplied the gain.

Accuracy and input context. Lexical retrieval uses the fewest input tokens. Compiled state uses more than lexical retrieval but much less than recent history, and it has the highest accuracy in both reader panels. Both axes focus on the observed range rather than beginning at zero.
Full chart description

Lexical retrieval uses the fewest input tokens. Compiled state uses more than lexical retrieval but much less than recent history, and it has the highest accuracy in both reader panels. Both axes focus on the observed range rather than beginning at zero.

Compiled state used about one quarter of the context required by recent history while producing higher accuracy for both readers. The axes focus on the observed range and do not begin at zero. Source data PDF

The axes focus on the observed range so the differences remain legible; neither axis begins at zero.

What the result means

The memory interface changed what the reader had to work through. Recent history supplied a growing chronological window that included large amounts of routine noise. The fused conditions selected a much smaller set of records. Among those fused conditions, the compact compiled serialization outperformed the session-tagged hybrid form and the type-and-provenance-tagged form even though all three began with the same record ranking.

The result is therefore not evidence that one retrieval algorithm was better than another. It shows that the reader-facing serialization of the same fused selection coincided with large accuracy differences. Because the compiled treatment changed its heading, tags, and formatting together, the experiment cannot yet identify which element contributed most.

The reader mattered as well. The 9B model was more accurate than the 4B model under every deployable interface. Because the two models differ in more than parameter count, the study does not identify model size itself as the cause.

Limits and evidence

This study provides evidence about a memory-interface pattern, not a verdict on every possible memory system. It used two models from the Qwen 3.5 family and 256 lexical variations of one controlled history-and-question template. The confidence intervals describe variation across those template instantiations, not across structurally different kinds of history. Real conversations and projects will be noisier, more ambiguous, and less complete.

The scope-forgetting questions also did not distinguish the interfaces: every condition, including no memory, answered them correctly because the shared eligibility layer had already removed private and deleted records. That one uniformly correct family accounts for the shared 11.11% no-memory floor; it is not an estimate of chance performance. The result checks the common filtering rule, not the relative quality of the nine interfaces.

The study recorded 53 invalid structured outputs: responses that did not follow the required answer format closely enough for the automatic scorer to interpret them. The primary analysis counted them as incorrect. Removing them in a separate sensitivity analysis changed no paired estimate by more than 0.117 percentage points, so they did not materially affect the result.

We preserved the records behind the reported comparisons, uncertainty estimates, invalid-output treatment, and clean analysis rerun so that each result can be inspected.

The study design, estimands, bootstrap plan, and reporting specification were frozen before discovery, but the executable analysis was implemented after the run. We therefore describe this as design-frozen discovery, not an externally preregistered confirmation. A separate mixed-effects model failed to converge and does not support an additional result.

After the first analysis was complete, we copied the sealed evidence into a new environment on a different operating system and processor architecture. The complete analysis ran again from the original trials, code, seeds, and declared bootstrap procedure.

The rerun checks the path from preserved trial evidence to the reported results. It is not an independent reproduction, and it did not repeat the full GPU inference workload.

01

Matched worlds and questions

Every memory condition used the same generated worlds and questions. The analysis compared methods within worlds so differences in world difficulty stayed aligned.

02

Confidence intervals preserved the study design

The 95% percentile confidence intervals came from 10,000 deterministic bootstrap samples that resampled complete worlds rather than isolated answers. Holm correction covered each declared family of comparisons.

03

Invalid answers counted as errors

The primary analysis counted all 53 invalid structured answers as incorrect. A second analysis removed them and changed no paired estimate by more than 0.117 percentage points.

04

Analysis reproduced from sealed evidence

A clean environment on a different operating system and processor architecture reproduced all ten analysis tables byte-for-byte from the sealed trial evidence.

Sealed files checked
2,760
Hash mismatches
0
Tables reproduced exactly
10
Bootstrap arrays
Exact match

SYSTEMS

GPU metrics

The study ran on one workstation with a Ryzen 9 5950X, 128 GB of system memory, and an RTX 3090 Ti. Both reader models ran on the same GPU and software environment.

The workstation recorded one systems summary for each experimental cell. These measurements describe the workload; they were not used to explain differences in model accuracy.

GPU
10,752 CUDA cores
Peak GPU memory
22,651 MiB
Active GPU time
60.99 hours
GPU energy
19.769 kWh

GPU METRICS

Temperature and utilization

GPU temperature55°CGPU utilization94%
Cell 864 / 864 Reader Qwen 3.5 9B Memory Diagnostic expected-evidence selector Condition 64 sessions · 8,192 tokens Measured GPU energy 19.77 kWh cumulative
Each point summarizes one experimental cell. The temperature lane shows the highest recorded GPU temperature in that cell; utilization is the mean of its one-second samples. The observed peak was 65°C, below the 84°C stop boundary. Move across the chart to inspect a cell.

GPU METRICS

Dedicated memory and power

Dedicated GPU memory20.4 GiBAverage GPU power244 W
Cell 864 / 864 Reader Qwen 3.5 9B Memory Diagnostic expected-evidence selector Condition 64 sessions · 8,192 tokens Measured GPU energy 19.77 kWh cumulative
Dedicated GPU memory is the peak observed in each cell. Average GPU power is calculated from the measured energy accumulated during that cell divided by its duration. The dedicated-memory axis begins at 20 GiB. The complete run used 19.769 kWh of measured GPU energy. Move across the chart to inspect a cell.

Where the research goes next

The experiment narrows the next set of questions. We now need to determine which parts of the compiled serialization produced the gain, whether the pattern survives structurally different histories, and whether different readers and questions need different forms of memory.

Separate the components of the serialization

A controlled comparison can keep the selected records fixed while changing the working-set heading, session tags, memory-type tags, provenance tags, bullet format, and record order one element at a time.

Test different histories and readers

Comparisons across structurally different histories and unrelated model families can show which findings generalize and when memory should adapt to the reader.

Test incomplete and adversarial memory

New studies should measure what compact working sets omit and how missing, conflicting, misleading, or poisoned records affect later answers.

Research materials

Read the full paper, inspect the published records, or download the source data behind the three primary figures in this article.

SUPPORT FARYNTH RESEARCH

Help expand what Farynth can study.

Farynth currently conducts its research using a single 24 GB workstation GPU. Our next target would increase that capacity to 96 GB, allowing us to evaluate larger local models and undertake more ambitious studies independently.

Current24 GB
Target96 GB
View the current goal