One Memory: What Parts Do We Really Need

00Summary: an output that changes the task

The task was: from the provided list of memory engines, select the necessary parts and assemble them into one large memory. The analysis showed that most of the necessary parts are already in our own code, and external engines provide only two or three truly missing pieces on top of all this. Therefore, we should not assemble "from their parts," but rather build up our missing layers, taking from them exactly what we don't have.

The second conclusion is even more important than the first, and it's unpleasant. Independent measurements do not confirm that fact extraction by the model actually improves memory: on the same test, extraction turned out to be worse than regular search through raw replicas. This means that extraction cannot be taken by default, only as an add-on that we first measure.

What exactly we are assembling

1. Our own core. One memory with provenance, time of truth, and versions. Here we already have almost everything; what's missing is the linking of four storages into one.
2. Time for truth. Two-temporal graph model from Graphiti: each fact has a time interval "when it was true" and separately "when we learned it". This is a direct answer to "memory is dynamic".
3. Understandable output. Our consent and receipt layer. No engine and no product has it. This is our distinction.
4. Extraction and connections. We connect them last and based on measurements: from Mem0, we take the extraction technique; from A-MEM, the note-linking technique, and only if our measurement shows benefit.

11How we checked: six streams from primary sources

The analysis was not based on reviews or promotional pages. Six independent streams read the code and documentation of each engine and wrote the results into a separate file to be consolidated later.

What exactly was required from each engine: how it transforms conversation into records, how it decides whether to add a fact or erase an old one, where this logic resides (file and function), what minimal part can be taken, what databases and model are needed, how mature it is, and what its license is. The license was checked not by the icon on the page, but by reading the license file itself: for three engines, the icon said "undefined," but the file contained Apache 2.0.

22Main conclusion: we need integration, not invention

An analysis of over forty engines (including those found at different addresses) yields an unexpected result: almost all the necessary memory layers are already implemented, but in four different places that are unaware of each other. Agent profile memory is stored as flat text, agent memory on the platform is stored in sections, pod knowledge is stored as records with attestations, and memory snapshots are stored separately. They are read in three different ways.

This means that ninety percent of the work is not about taking someone else's engine, but about consolidating our own into one and building what neither we nor they have.

33What we already have: nine ready layers

The sixth parsing stream read not foreign engines, but our own code. Result: our memory is implemented more broadly than we ourselves thought about it. Below are nine layers that already exist, with their location in the code and what each does.

44What's missing: eight layers

The missing layers are the real challenge. All eight are not new inventions, but rather combinations and additions to what already exists.

55License gates: what can be taken at all

Before any device analysis, the question arises whether the code can be taken. The check was done by reading the license file in the repository, not by an icon on the page: for three engines, the icon said "undefined," but the file contained a permissive license, and two of them would have been mistakenly removed.

66Decision matrix: take, option, or reject

Each engine was given a verdict based on one rule: we take what is either absent from us, or absent from everyone and at the same time small in volume and clear in structure. The cost of implementation is measured not by the size of the repository, but by the number of third-party services that will have to be deployed alongside it.

Pay attention to the asymmetry: all three "take" items are small, understandable pieces. All "rejection" items are either heavy platforms or lack of code. This is the true result of the analysis: we don't need large engines not because they are bad, but because we don't want to drag three foreign databases for memory.

77Time of Truth: The Only Engine That Does This

Out of six temporal layer engines, only one truly cancels an old fact with a new one. Its edges have not one time, but two: when the fact was true and when we learned about it. Plus a separate mark for when the fact ceased to be true, and a separate record node indicating where the fact came from.

Field names in this engine's scheme: validity start, validity end, expiration time, creation time, reference time, and list of episode records. Upon cancellation, the system returns a list of canceled facts and closes the old fact's validity period with a new start. This is precisely the behavior Marina requested when she said memory is dynamic.

88Fact Extraction: Strong Techniques and a Warning Signal

Two engines provide the most portable extraction technique, and both keep it in the model's prompt text, not in deeply buried code.

For other engines, this layer was either closed in the cloud, tied to its own database schema, or completely absent. The memory service on Redis does not extract facts at all: it expects the caller to bring them.

99Independent Measurements: Extraction Can Be Worse Than Simple Search

This is the most important and most inconvenient finding of the analysis. When we compiled memory accuracy measurements across systems, it turned out that almost all of them were made by the system authors themselves, and rare independent measurements yield numbers several times smaller.

A separate pitfall is that numbers from different systems simply cannot be compared: one metric counts exact answers, another evaluates the answer with a model, and a third counts hits. The numbers in the table are placed side-by-side only to show the spread, not to pick a winner. You cannot choose based on someone else's numbers at all.

1010Local core: readable files, oversight, and decay

The requirement that "a person must understand what is being shared without rereading hundreds of entries" is met in only one way: memory must be visible. Of all the engines, one stores memory as ordinary text files with a header, which can be opened by any editor, and at the same time requires no external dependencies.

This core has already been verified live, not just by description. The search returned the desired note with a score of 8.16. The strength of the entry increased from 1.25 to 1.50 after accessing it: fading works both ways, important things strengthen, forgotten things weaken. Intake supervision flagged an error for a note without a source, and an attempt to write over someone else's version was rejected.

1111Connections and evolution of notes: memory that develops

Simply adding notes turns memory into a dump: similar facts are duplicated, opposing ones lie next to each other. One engine solves this with a technique borrowed from paper card catalogs: a new note doesn't just settle, it seeks out related ones and rewrites them.

1. A new entry transforms into a note with content, tags, keywords, context, and time.
2. The system reviews already accumulated notes and searches for related ones.
3. Similarity transforms into connections between notes.
4. Neighboring notes are rewritten: their context and tags are refined to account for the new one.

Two steps here are key: generating connections and evolving memory. The author's own testing shows that disabling these two steps significantly degrades the quality of answers to multi-step and open-ended questions. That is, the value lies in the connections, not in the notes themselves.

1212What we rejected and why: an honest analysis of failures

A rejection is also a result, and its reason is more important than the solution. Below are the reasons for each rejected group, so as not to start the analysis again in six months.

1313Memory robustness: why origin and oversight are even necessary

Memory is not only convenience, but also an attack surface. Analysis of primary sources yielded measurements from which it follows that without origin, oversight, and signatures, memory is dangerous.

1414Understandable output: no one has this part

A separate analysis stream searched the world for a solution to one human problem: for a person to understand what they are sharing without re-reading hundreds of records. There is no solution. The closest approaches are listed below, and each covers only a part.

The strongest argument here is negative, and it comes from the memory vendor: memory does not have a human output model, neither for them nor for the majority. This means that "what you actually give away" is not an improvement of someone else's solution, but an unoccupied niche. We already have the building blocks for it: pointers and hashes in the passport, signed step receipts, intake supervision, and recall with replacement.

1515Architecture of a single memory: five layers

From the entire analysis, one picture emerges. Memory is not an engine, but five layers, three of which we already have, one we take as a scheme, and one we take as a technique.

The order of the layers is also the order of operation. First one type of storage, then time, then connections, then oversight, then output. Model extraction is not included in this scheme at all: it connects as an optional add-on over the second layer and only by measurement.

1616Why the foundation is raw episodes, and extraction is just a superstructure

Independent measurements are designed to make us overturn the usual scheme. It is customary to think that memory is what the model extracted and compressed. Measurements show that compression can worsen answers: precise search through raw replicas turned out to be no worse, and in some places better than extraction, and loses only to the full context, which does not fit into memory.

This arrangement yields three consequences at once. First: the answer can always be traced back to where it came from, meaning the origin does not need to be restored; it exists by design. Second: if the extraction made a mistake, it can be recalculated anew from the raw episode, rather than losing data. Third: the battery of tasks measures the utility of extraction honestly, because there is something to compare it with.

1717Final set for versioning

Following the analysis, a short list goes to versioning. Each line indicates how it is taken: entirely as a library, as a schema with attribution, or as a technique rewritten by hand.

1818Step-by-step work plan

The order is determined by dependencies: until repositories are merged, there's nothing to show for origin and delta; until there's a time of truth, one cannot answer "what was considered true then."

Task battery, one for all engines

Add a fact. Change a fact and check if the old one is gone. Ask "when was this true". Ask based on a retelling. Find out the origin of a record. Erase and check that it was erased and didn't resurface. Measure the volume. The same battery for raw episodes, for the note kernel, and for extraction, so that the numbers are comparable.

1919Risks and honest limits

The analysis provided a clear picture, but it has boundaries, and they must be stated aloud.

Separately: we checked the kernel on readable files live, but extraction by the model was not confirmed live. This is not an excuse, but an honest status: for one engine we know the behavior, for the other we only know that the installation did not reproduce.

Implementation cost by parts

2020Completeness check: each statement and its outcome

The analysis was conducted based on the list of engines and the questions that arose during the process. Below is each statement with the outcome of the check.

Three things remained unchecked, and this is fair: a direct measurement of consent request frequency specifically for memory does not exist; an independent measurement of the conversational task for four engines is unavailable; the behavior of model-based retrieval has not been reproduced live by us.

2121Numbers on which the conclusion is based

All numbers in this analysis are taken from primary sources and signed with their origin. Not a single one is retold from a review.

2222The same thing in simple words

If you remove all terms, the conclusion sounds like this.

We wanted to assemble one large memory from ready-made parts from others. When we truly disassembled them, it turned out that almost everything we needed was already built by us: memory already exists, the origin of records already exists, signatures and receipts already exist, filtering out external commands already exists. It's just that all of this is in four different places and not shown externally. This means the main work is not to "assemble external parts," but to "consolidate our own into one and display it."

We found exactly three things in external engines that we don't have: a way to store two times for each fact (when it was true and when we learned about it), a way to link notes so that memory evolves, and, as a possible addition, a way to extract facts from a conversation using a model.

And most importantly. When we looked at honest, non-promotional measurements, it turned out that extracting facts with a model can make memory worse, not better. Therefore, we build memory entirely on raw conversations, and fact extraction is placed on top and enabled only if our own measurement shows a benefit.

2323Primary sources

The analysis is based on scientific papers, official pages, and open repositories. Below are those referenced in the text.

Separately: the analysis of our own code involved reading agent memory files, pod knowledge, pod receipts, agent table, and passport format. None of this changed.

2424One-page output

Analysis completed. The rejection of large platforms was accepted not due to weakness, but due to support cost: three small understandable parts instead of eight large foreign databases. The real work begins where no one has done it: in human-understandable memory output.