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.
ContextVault stores data at the workspace/org level, not only the individual user level. That is intentional. If someone leaves a team, their useful shared context should not disappear by default.
So deletion needs two paths: a user can remove their account/access without destroying shared workspace memories, while a workspace owner/admin can delete the workspace and its associated data through a clearly confirmed destructive flow.
Those account/data deletion controls are on the roadmap. I’m being careful with the design because the wrong version either preserves too much or lets one user accidentally delete knowledge other team members depend on.
I’m a solo founder in the US. I’m not interested in reading customer data; the product needs to earn trust through org scoping, minimal access, and clear deletion/privacy controls.
Yes. This means you can 'ask' up to 15,000 times a month. Writes are (for that tier) capped at 2500 a month.
Example, after an hour long AI session, you can 'save to my vault' and it will extrapolate the session as one context/learning, or all the valid bits as individual records at your discretion. This constitutes saving memories, of which you get 2500 a month. Later, if you ask "have we done something like this before?", that is 1 query to the vault.
We're open to shifting these limits around based on actual usage and fairness. 15k a month seemed like a high ceiling to us, but perhaps for some orgs they would reach that much faster. Open to suggestions. The designed intent was you saved what you thought was valuable enough to save for recall later, not everything from every AI session.
Its not Markdown files in nosql. The context is extrapolated from a session and broken out into a record Postgres. You decide in a session what memory/context to save to the vault, the next time you ask about it, you will receive that (and refresh the AIs current context in the process).
Consider the non-developer type jobs out there who may be using AI, but the AI their team is using has no clue what the other person is doing or has done. This tool helps them bridge that gap. If one person has a pile of markdown files (not talking about skills, agents, etc) and the others do not, they won't get the same benefit. Instead of having hundreds of 'solutions' or 'learnings' in a file, you store it in the cloud and depending on their role/group assignment, its available to their AI client to recall later.
I'm not trying to be obtuse, and correct me if I'm wrong, but "context" is just words, often rendered as markdown because it's easy for both LLMs and humans to produce and edit. Since its in a database and they're not necessarily full documents, I'll use the phrase "markdown snippets" for now. Feel free to quibble with the phrasing, I'm trying to understand what it does.
You save 2 respectability points by using postgres over nosql. (joke)
> depending on their role/group assignment, its available to their AI client to recall
So you generate/extract markdown snippets from the local context of each agent along a few axes like: what problem the user is working on and their approach, what role they're acting as and tools they're using, etc, and store those snippets in a postgres db with indexes over the category.
So how is that then exposed to the receiving agents? Is it fully opt-in / pull only? Or do they get some related threads automatically injected in their context. What does it look like? "Jan was working on something similar yesterday, her agent found these docs helpful: a.md, b.md" ?
Yes, sorry, context is such an overused word these days. What happens is the conversation is distilled into several areas (problem, solution, learnings, 'context' or original problem, plus other fields) and vectorized. Later, when you ask something similar, it will search and rank what it finds as potentially most relevant. This helps others discover what you or others already had done or learned. I leveraged aspects of Postgres that help rank, index and boost recall in a way having plain markdown files can't exactly achieve.
> what problem the user is working on and their approach, what role they're acting as and tools they're using, etc, and store those snippets in a postgres db with indexes over the category.
30,000 foot level - yes.
The receiving agents connect to the MCP, and when you say things like 'save this to the vault', 'save to your memory', or 'did someone solve this already?' it will use the exposed MCP tools and store the information. The AI agent is responsible for distilling the conversation bits out to the storage shape, then inserted to Postgres. This way, its AI client agnostic, there is no AI client lock-in, and teams that use a mixture of clients can retain the service all the same and experiment/deprecate AI clients as they go without losing any data.
Its kind of hard to present real world examples, but I figured this is very useful for even non-developers. Like your local plumber or HVAC company or a hundred other examples, "Customer in 14A electrical panel shorted again - what did we do last time to resolve that?" - record is found and presented back in conversational form from AI for that user to work through, if that makes sense. I tried to imagine professions "in the field" out on a call and thought wouldn't it be cool if they could get answers to things faster than the hours it can often take to diagnose issues. That is why it was important for me to support the desktop/mobile app versions and not just CLI clients to reach those kinds of customers using a UI.
Also yes, if it finds say 6 potentially relevant records, it will rank them and present them back as options to explore - it won't force #1 on you just because it was ranked #1.
Basically, I put myself in the shoes of an end user, potentially not as tech savvy as the HN crowd, who do not want to create or maintain markdown files (they may not even know what it is) and particularly do not use CLI. They can still use this tool with desktop/mobile apps, not worry about the overhead of managing several files (not to mention sharing them to others), and the more they use it the better it becomes.
So you draw some distillates out of the conversation, do a vector embedding of each, and insert the pairs into pg. Then retrieval is distill -> find top N nearby vectors. Indexing, etc. Seems like a smart way to organize long term memory.
Also I can't help but notice that this solution combines technologies whose origins literally span 6 decades: relational databases (80's), vector embeddings (00's), and LLMs (20's).
What kinds of prompts do you use to get the distillates, and what shape are they? I guess I've been assuming you extract more than one distillation out of a conversation per memory access, do you?
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.
Cheers
this seems sketchy as. how are you securely storing all that sensitive data? how do I delete data? How do I know you are not viewing my data?
Fair question.
ContextVault stores data at the workspace/org level, not only the individual user level. That is intentional. If someone leaves a team, their useful shared context should not disappear by default.
So deletion needs two paths: a user can remove their account/access without destroying shared workspace memories, while a workspace owner/admin can delete the workspace and its associated data through a clearly confirmed destructive flow.
Those account/data deletion controls are on the roadmap. I’m being careful with the design because the wrong version either preserves too much or lets one user accidentally delete knowledge other team members depend on.
I’m a solo founder in the US. I’m not interested in reading customer data; the product needs to earn trust through org scoping, minimal access, and clear deletion/privacy controls.
Hi, can you explain what the 15.000 queries per month means. Does not feel like a lot
Yes. This means you can 'ask' up to 15,000 times a month. Writes are (for that tier) capped at 2500 a month.
Example, after an hour long AI session, you can 'save to my vault' and it will extrapolate the session as one context/learning, or all the valid bits as individual records at your discretion. This constitutes saving memories, of which you get 2500 a month. Later, if you ask "have we done something like this before?", that is 1 query to the vault.
We're open to shifting these limits around based on actual usage and fairness. 15k a month seemed like a high ceiling to us, but perhaps for some orgs they would reach that much faster. Open to suggestions. The designed intent was you saved what you thought was valuable enough to save for recall later, not everything from every AI session.
I guess another thing is once the related conversation is identified you can use some other mechanism to retrieve it all or in parts etc.
So instead of markdown files in a repo, it's markdown files in a nosql database?
Its not Markdown files in nosql. The context is extrapolated from a session and broken out into a record Postgres. You decide in a session what memory/context to save to the vault, the next time you ask about it, you will receive that (and refresh the AIs current context in the process).
Consider the non-developer type jobs out there who may be using AI, but the AI their team is using has no clue what the other person is doing or has done. This tool helps them bridge that gap. If one person has a pile of markdown files (not talking about skills, agents, etc) and the others do not, they won't get the same benefit. Instead of having hundreds of 'solutions' or 'learnings' in a file, you store it in the cloud and depending on their role/group assignment, its available to their AI client to recall later.
I'm not trying to be obtuse, and correct me if I'm wrong, but "context" is just words, often rendered as markdown because it's easy for both LLMs and humans to produce and edit. Since its in a database and they're not necessarily full documents, I'll use the phrase "markdown snippets" for now. Feel free to quibble with the phrasing, I'm trying to understand what it does.
You save 2 respectability points by using postgres over nosql. (joke)
> depending on their role/group assignment, its available to their AI client to recall
So you generate/extract markdown snippets from the local context of each agent along a few axes like: what problem the user is working on and their approach, what role they're acting as and tools they're using, etc, and store those snippets in a postgres db with indexes over the category.
So how is that then exposed to the receiving agents? Is it fully opt-in / pull only? Or do they get some related threads automatically injected in their context. What does it look like? "Jan was working on something similar yesterday, her agent found these docs helpful: a.md, b.md" ?
Yes, sorry, context is such an overused word these days. What happens is the conversation is distilled into several areas (problem, solution, learnings, 'context' or original problem, plus other fields) and vectorized. Later, when you ask something similar, it will search and rank what it finds as potentially most relevant. This helps others discover what you or others already had done or learned. I leveraged aspects of Postgres that help rank, index and boost recall in a way having plain markdown files can't exactly achieve.
> what problem the user is working on and their approach, what role they're acting as and tools they're using, etc, and store those snippets in a postgres db with indexes over the category.
30,000 foot level - yes.
The receiving agents connect to the MCP, and when you say things like 'save this to the vault', 'save to your memory', or 'did someone solve this already?' it will use the exposed MCP tools and store the information. The AI agent is responsible for distilling the conversation bits out to the storage shape, then inserted to Postgres. This way, its AI client agnostic, there is no AI client lock-in, and teams that use a mixture of clients can retain the service all the same and experiment/deprecate AI clients as they go without losing any data.
Its kind of hard to present real world examples, but I figured this is very useful for even non-developers. Like your local plumber or HVAC company or a hundred other examples, "Customer in 14A electrical panel shorted again - what did we do last time to resolve that?" - record is found and presented back in conversational form from AI for that user to work through, if that makes sense. I tried to imagine professions "in the field" out on a call and thought wouldn't it be cool if they could get answers to things faster than the hours it can often take to diagnose issues. That is why it was important for me to support the desktop/mobile app versions and not just CLI clients to reach those kinds of customers using a UI.
Also yes, if it finds say 6 potentially relevant records, it will rank them and present them back as options to explore - it won't force #1 on you just because it was ranked #1.
Basically, I put myself in the shoes of an end user, potentially not as tech savvy as the HN crowd, who do not want to create or maintain markdown files (they may not even know what it is) and particularly do not use CLI. They can still use this tool with desktop/mobile apps, not worry about the overhead of managing several files (not to mention sharing them to others), and the more they use it the better it becomes.
I hope this helps answer your questions.
So you draw some distillates out of the conversation, do a vector embedding of each, and insert the pairs into pg. Then retrieval is distill -> find top N nearby vectors. Indexing, etc. Seems like a smart way to organize long term memory.
Also I can't help but notice that this solution combines technologies whose origins literally span 6 decades: relational databases (80's), vector embeddings (00's), and LLMs (20's).
What kinds of prompts do you use to get the distillates, and what shape are they? I guess I've been assuming you extract more than one distillation out of a conversation per memory access, do you?