can you give a bit more details on how it works? what makes this different/better from main AI agent memory out there? the website is also quite cryptic
Thank you again for your feedback. I did listen, and I have updated the site significantly.
I had intentionally let the site be vague on particulars as I was hammering out backend issues.
One main issue that we discover for many AI is that they're not exactly "write" capable when it comes to certain tasks... Which makes the claim that it works with everything - partially true, but not to the extent that I want it.
That's where having a bridge via a plugin will be both essential and super scary. I've been thinking through all the various concerns and exploits that every plugin goes through and... wow. What a thing. After being completely paranoid and hypervigilant - I believe I have an elegant solution that satisfies my immediate terrors.
Yes it makes more sense now. One thing I wonder, as most of memory systems this one also requires an LLM API key, what's the expected pricing involved? What does the LLM do here? I was looking into Cognee, one of the main players in the field, and they use YOUR tokens to summarise and chunk all your company data, which I expect to generate a hell of a token bill.
Fair feedback on the site — we probably went too minimal. Here's the mechanics:
*How it works:*
saor is a REST API + MCP server that stores structured context for AI agents. Not raw chat history — structured identity: who your business is, what your voice sounds like, what decisions you've made, what worked, what didn't.
1. You sign up, get an API key
2. Run `npx saor-mcp --setup --key sk_YOUR_KEY` in any project
3. Your AI tool (Claude Code, Cursor, etc.) now has 10 MCP tools: brain_context (read), brain_remember (write), brain_search (recall by tags), etc.
4. At session start, the AI loads your brain — identity, memories, constraints
5. As it works, it writes memories back — tagged, auto-linked
6. Next session, next tool, different AI entirely — same brain. Context compounds.
The brain is Postgres. No AI on our servers. Your AI tools do the thinking. We just store and serve the structured data.
*What's different from Mem0, Zep, etc:*
Most memory tools are key-value stores with vector search. Store a fact, recall a fact. Digital Post-it notes.
saor does three things they don't:
1. *Structured identity, not just memories.* Voice, audience, positioning, ethical constraints — a brain, not a notepad. Your AI doesn't just remember facts, it knows who it's working for.
2. *Knowledge graph.* Memories auto-link by tags. A "pricing" memory in one project connects to "pricing" in another. The graph builds itself — no manual linking.
3. *The brain teaches the agent.* Every context pack includes agent_instructions that tell the AI how to use the brain — read at start, write as you learn, tag for linking. The brain onboards every AI automatically. No CLAUDE.md needed.
Let me know if what I've given you makes sense. I tend to "just do" what I need to have done, and while I understand the particulars of my needs, I don't generally need a roadmap for others...
Of note, I am working on the browser plugin. It should eliminate the need to work through the variable of "which site, which comms method" that we all navigate when we're involving more than one AI in a project.
This is very interesting. Question: I am building an LLM-free memory system, does the gpt-4o-mini full evaluation requirement from the docs mean that systems using an LLM must standardize on gpt-4o-mini, or are LLM-free Add/Search systems ineligible? Thanks
> Sorry for the concern, and thank you for your support of AML. Your submission is eligible.
>
> According to the AML requirements, if an LLM is used, it must be *GPT-4o-mini*. If no LLM is used, this requirement does not apply.
Interesting, I'm building something somehow similar (purely latent-space though, no LLM in the loop) and I'm curious about how did you define supersession/contradiction? is it purely via cosine similarity threshold (as per readme) or do you leverage LLM on top-k docs to actually track them?
If yes did you dogfood it and found it working correctly?
Really nice! I always had in mind to build something similar but on the geographical axes: given a long/lat param show all historical events related in the surrounding area.
that's my current setup, but it requires quite some manual work. Especially when I want to release. ie I commit and push to private repo, create PR with summary, merge. Then I run the script to copy over files to public repo (skipping files listed in a custom .publicignore file), then manually commit to public repo (I have to copy over commit messages and PR summaries from private repo), then push and release on public. It's a bit exahusting, and when something drifts it becomes a hell to keep them both in sync.
My suggestion was to keep one repo with the docs and a separate repo with the code, and zero intersection.
I teletransported commits from one repo to another with "git format-patch" and "git am" or something like that. I never remember the magic spell. If you do that too often, you may automate it in a script.
Antirez's take is bold, and probably very scary for most programmers (and especially for their managers), but I think he's mostly right. I'd even go further: people who don't adapt to this change will be soon left behind, because today things are moving blazingly fast.
This doesn't mean AI-generated code is safe. The key point here (which AR explains well in his latest YT video on his way to the gym :D) is that you still need to master the CS fundamentals. Which means:
- People who master the fundamentals will use AI to move much faster.
- People who don't master the fundamentasl and vibe code will evetually hit a wall,
but most importantly
- People who master the fundamentals but review all the code will move much slower.
Maybe. Depends on how solid the code is in the directions that matter for that code. Does security matter? Real-time performance? Never losing a transaction? Never leaking memory? What matters for the code you're trying to write? Future maintainability? How good is AI at producing code that does not fail in the directions that matter?
People who master the fundamentals but review all the code will move much slower. But they'll be more successful in the medium to long run if they're catching things that matter. (If they aren't, of course, they're just wasting time.)
>Does security matter? Real-time performance? Never losing a transaction? Never leaking memory? What matters for the code you're trying to write? Future maintainability?
The assumption I believe is: if you are experienced enough you will instruct your agent(s) to address all of these during your iterations.
the problem you are addressing is interesting, but given this is NOT an OSS I found the post a bit difficult to evaluate because the core mechanics of the product are not very clear.
You provide a lot of implementation details (authentication providers, database choices, frontend stack, etc.), but those are quite unrelevant to understand your tool. The key questions for a memory systems to me are:
- What exactly is a "memory" or "context record" in ContextVault?
- How is information added, updated, or removed over time?
- How does retrieval work (vector search, ranking, rules, something else)?
- How do you handle stale information, contradictions, or superseded knowledge?
- What makes this different from a shared RAG knowledge base or a document store with MCP access?
A few concrete examples or an architecture overview would probably make the product much easier to understand. For example, showing a before/after workflow of an agent using ContextVault would help clarify where the intelligence of the system actually is.
nice article(s), AI agent memory is still deeply unexplored, IMO it will become a critical space very soon (if it's not already). The biggest issue it's benchmarking memory systems: benchmarks are still quite immature because testing memory systems is intrinsically complex. Locomo, LongMemEval, etc do not cover all the use cases you listed there.
