This project has an unusual origin for a developer tool. It came out of a research paper about managing limited context the way an operating system manages limited memory, with a working set held in fast storage and everything else paged in and out as needed. That framing is the most valuable thing here and I would recommend the conceptual documentation to people who will never install this, because the analogy genuinely clarifies a problem that most agent builders handle badly. The specific insight is that a model's context window is not storage, it is working memory, and treating it as storage is why so many long-running agents degrade.
If you keep appending conversation you eventually fill the window, and long before you fill it you have diluted the useful content with noise and made the model worse. The alternative is an explicit distinction between what is in context right now and what is retrievable, with rules about what gets promoted and evicted. Once you see the problem this way it is hard to unsee, and it improves how you build even outside this framework. The architecture follows from the idea.
Agents are persistent objects that live on a server with their own memory state, rather than being reconstructed from a message history on every request. You create an agent, it exists, you send it messages over days and it retains what it should. Memory is divided into blocks, some always in context, holding the agent's persona and what it knows about the user, and some archival, retrieved when relevant. The documentation explains this structure clearly and the distinction between block types is worth understanding.
The development environment is a good piece of tooling. You can look at an agent, see exactly what is in its context window right now, read its memory blocks, watch them change as it works, and edit them directly. For debugging a stateful system this is exactly the right affordance, and the opacity of most agent frameworks is one of the more frustrating things about building on them. Being able to see the state is a real advantage.
The intellectual honesty is worth noting. The documentation points at the research it came from rather than presenting the ideas as proprietary innovation, and it is reasonably clear about what is established and what is a design bet. That is rarer than it should be. Now the concern I keep coming back to.
The agent edits its own memory. The model decides what is important enough to write into a memory block, decides when to update a block, and decides what to archive. That is elegant and it is also handing a language model write access to the state that determines its own future behaviour, with no human in the loop. The failure mode is compounding.
An incorrect fact gets written into core memory. It is now in context on every subsequent turn, shaping every response, and it may be reinforced or elaborated by later edits. The agent becomes confidently wrong about something in a way that is persistent and self-reinforcing. This is not hypothetical, it happens, and the documentation treats memory editing as a feature to be demonstrated rather than a risk to be managed.
What I would want and do not find is serious guidance on constraining edits, on validating writes, on detecting drift, and on when to require human approval for a memory change. The naming history is a practical problem for learners. The research and the early implementation are widely known under one name, the project now uses another, and the result is that search results, tutorials, forum answers and academic citations are split across both. A newcomer trying to find help does not know which term to use and finds material of different vintages under each.
The documentation handles the transition reasonably and cannot fix the wider ecosystem. The architectural weight deserves consideration. This is a server, with a database, holding persistent state, that you have to run, back up and operate. For applications that genuinely need long-lived agents accumulating knowledge over months, that is a fair cost.
For an application where a conversation lasts twenty minutes and then ends, it is substantial infrastructure for no benefit, and a much simpler approach would serve. The documentation naturally presents the full architecture as the way to build, and does not help you decide whether you are in the case that needs it. Evaluation is the other gap and it is the one I would most like filled. The premise is that better memory management produces better agents.
How would you know. What would you measure. How do you tell whether your agent's memory is actually helping rather than accumulating noise that costs tokens and confuses the model. These are the questions that would let a team justify the architecture, and there is very little on them.
My three point five is for a framework built on a real idea, explained clearly, with an architecture that follows honestly from its premise and tooling that lets you see inside. Marked down for treating self-editing memory as a feature rather than a risk requiring guardrails, for ecosystem fragmentation after the rename, for architectural weight presented without a sense of when it is unnecessary, and for no serious evaluation guidance. Read the concepts. Adopt with care.