Answers
There are already dozens of AI memory tools. Why would we evaluate another one?
Because the thing they are crowded on is not the thing that is missing. Almost every tool on that list answers the same two questions — how text gets stored, and how it comes back — and on those two they are genuinely hard to tell apart, which is exactly what makes the category feel saturated. The question none of them answers by default is who decided that a stored statement is what the team stands behind, and what happens to it when someone changes their mind. That is governance, not retrieval, and a crowded retrieval market says nothing about it. The honest version of the objection is that you cannot tell these tools apart on the axis you were comparing them on — which is true, and is a reason to change the axis rather than to stop looking.
Last updated September 18, 2026
Saturation is an argument about mechanism; this is a question about authority
Look at what the comparison is usually made of: connects to your assistant, stores notes, embeds and retrieves them, scopes by project. Those are real features and by now they are table stakes, which is why every new entrant reads like the last one. Nothing on that list says who is allowed to make a statement binding, how a statement stops being binding, or what an assistant is supposed to do when two of them disagree. A market can be full of implementations of one mechanism and empty of answers to a different question, and that is not a paradox — it is what happens when a category forms around the easy half of a problem.
Writing is where the tools diverge, and it is the half nobody demonstrates
The visible half of a memory tool is reading, because reading demonstrates well: ask a question, watch the right note come back. Writing is where the decisions live, and it is where implementations actually differ. Does anything an assistant writes become memory immediately? Can it overwrite what a person put there? Is there a step where a human turns a proposal into a rule, and is that step visible to anyone? Here an assistant's own writing lands as a proposal and governs nobody until a person sanctions it. That is a product decision with a cost — somebody has to review — and it is the kind of difference that never shows up in a feature table, because it reads as friction rather than as capability.
Three questions that thin the crowd, and they apply here too
If you are evaluating tools in this space, three questions separate them faster than any feature list. What does the assistant receive as current when two stored statements contradict each other? What is the act that makes a statement binding, and who is allowed to perform it? And how does a statement stop being binding — is there a condition written down with it, or does someone have to remember to delete it? Any tool can answer them; most have never been asked, because the comparison stopped at storage. Whatever you end up choosing, ask those three, and the shortlist gets shorter on its own.
What it looks like in practice
A team shortlists four memory tools and finds the comparison useless, because all four descriptions read the same: connect your assistant, save what matters, get it back when it is relevant. They pick one on price, which is the only column where the four differ. Six weeks in, the problem they actually had is unchanged. The assistant is confidently wrong about the deployment process, and when they go looking, the store holds three notes about it: the original process, a note from the migration saying it changed, and a summary one of the assistants wrote from a thread where two engineers were still disagreeing. All three retrieve. None of them is marked as the one that holds, because the tool was never asked to represent that — it was asked to store and to retrieve, and it did both correctly. The gap was not in the shortlist. It was in the axis: four tools were compared on the half of the problem all four had already solved.
Questions people ask about this
- Isn't "governance" just a heavier word for the same feature?
- It is a different behaviour, and the test is cheap to run. Write two contradictory statements about the same thing into the tool and then ask the assistant. If both come back and it picks one, that is retrieval doing its job and nothing else is happening. If one comes back as current, naming who made it current and what it replaced, something else is. The second behaviour costs a person's attention to produce, and that cost is the difference — it is why it is not simply a feature the others forgot to ship.
- Doesn't a crowded category mean this gets commoditised anyway?
- The stored-and-retrieved part probably does, and that is fine: it is infrastructure, and infrastructure commoditising is how it becomes cheap and everywhere. What does not commoditise is the record of what one specific team agreed to, because it is not a technique, it is their material. Which is why the question worth asking of any tool here is what happens to that record when you leave — whether it comes out whole, and whether it still means anything outside the tool that held it.
- We already run something in this space. Do we have to replace it?
- Not necessarily, and finding out is a short exercise rather than a migration. Take the three questions above to what you already have: if it answers them, the gap described here is not yours and nothing needs to change. If it does not, you now know what is missing, which is more useful than any shortlist — and every tool you look at afterwards, this one included, should be made to answer them before anything else.
Where this is verifiable
Product documentation on this site (How it works, Install), the answers on why retrieval does not replace sanctioned memory and on memory without a write policy, and the sanction, supersession and expiry rules in the sanctioned product spec. Everything described here is behaviour the tools apply today, not roadmap.
https://www.arroway.app/en/answers/a-crowded-memory-market-doesnt-mean-a-sanctioned-one