Everyone building agents hits this wall at roughly the same point. Your assistant is useful for one conversation and then forgets everything, so the user tells it their name and their preferences and their situation again tomorrow. The obvious fix is to keep the conversation history and feed it back, and that works for about a week until the history is forty thousand tokens, costs a fortune on every call, and the model is worse at using it than it was at four thousand. Something has to compress and select, and that something is what this library is.
The conceptual pages explaining this are genuinely good and I would recommend them separately from the product. The distinction drawn between raw history and extracted memory is the thing most people get wrong, and the documentation articulates it well. History is what was said. Memory is what should be remembered, which is a much smaller set of durable facts, and turning one into the other is a real problem that deserves the attention.
Reading these pages will improve your thinking even if you decide to implement it yourself. The API is pleasantly small. You add messages, you search for relevant memories, you get them back scored by relevance, you inject them into your prompt. The quickstart works and the integration is genuinely a couple of calls rather than an afternoon of configuration.
For a category that could easily have produced a heavyweight framework, keeping the surface this narrow was a good decision. Graph memory is the more interesting feature and the one worth experimenting with. Rather than storing isolated facts, it captures relationships between entities, so the system knows that a person works at a company and that company is in an industry, and can traverse those connections when retrieving. Whether this pays off depends heavily on your domain, and the documentation is reasonably measured about it, which I appreciated.
The open source core matters more than it might seem. This library extracts facts about your users and writes them to a store, which is exactly the sort of thing you want to be able to inspect. Being able to read the extraction prompts, see what schema the facts land in, and query the store directly is not a nice-to-have when you are accountable for what your system holds about people. Now the part that worries me and that the documentation does not treat with enough seriousness.
Extraction is done by a language model. That means it inherits every failure mode a language model has. It will occasionally decide that something said in passing, or sarcastically, or hypothetically, is a durable fact about the user and write it down. It will misattribute a statement about a third party to the user themselves.
It will extract something subtly wrong and store it with the same confidence as everything else. Once written, that memory gets retrieved and injected into future prompts, where it shapes the model's behaviour indefinitely, and neither you nor the user is likely to notice. The documentation acknowledges that extraction is model-driven and moves briskly on. It should be a chapter, not a sentence.
Related to this, the handling of contradiction and update is thinner than the problem deserves. People change jobs, move house, change their minds. There is update logic and the docs describe it, and what is missing is a serious treatment of what happens when the old memory and the new one both survive, how you detect that, and what your application should do when retrieval returns two mutually exclusive facts. In practice this is where memory systems get embarrassing, and it needs more than it gets.
The privacy material is the biggest omission relative to what the tool does. This is a system whose entire purpose is accumulating personal facts about identified individuals and holding them indefinitely. That is a data protection question in most jurisdictions, and it deserves proper treatment. How do you delete everything for a user who asks.
How do you show a user what you hold about them. What is the retention default and how do you change it. How do you prevent extraction of categories of information you never wanted to store. There is some material and it reads as an afterthought next to the integration guides, and the balance is wrong for a product in this category.
The benchmark claims deserve a sceptical eye too. Comparative accuracy and latency numbers are presented, and vendor benchmarks against approaches the vendor has chosen and configured are worth roughly what you would expect. The documentation does not invite that scepticism. My three point four is for a real problem, a clear explanation of it, a small clean API and open source you can actually audit.
Marked down for treating the accuracy of the extraction step as a footnote, for shallow coverage of contradiction and staleness, and for privacy documentation that does not match the sensitivity of what the product stores. Worth reading, worth trying, and worth being more paranoid about than the docs will make you.