> 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.

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.

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.

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 Kevin. I built ContextVault because I kept running into the same problem with AI tools.

Every project accumulated prompts, coding conventions, architectural decisions, examples, and other pieces of context that made the models significantly more useful. The problem was that this information quickly became fragmented. Some lived in ChatGPT Projects, some in Claude, some in Markdown files, some in internal documentation, and some only existed in previous conversations.

Late last year, I realized several people on our team were solving the same problems independently because previous work was difficult to discover. I assumed this problem existed in other large organizations, so I started experimenting with a shared context store.

I started with a local proof of concept and a rough MCP server. If I asked questions like "have we done this before?", the AI could search the database and find the most relevant item to review. If a conversation produced something worth remembering, I could say "save what we learned to the vault." After using that workflow for a few months, I found myself relying on it every day.

I decided to make it available to others. I've never built a product before, and I thought it would be a valuable learning exercise to do.

ContextVault is a a product for storing and organizing reusable context that can be shared across people, projects, and AI tools. Instead of copying the same instructions into every conversation, you can store them once and retrieve them through our MCP server. It is not limited to any one AI client. Your team can use ChatGPT, Codex, Claude, and Gemini and save/read from the vault all the same.

It currently supports:

- OAuth support for GitHub, Google, Microsoft, and GitLab

- Structured context records with metadata

- Multi-user organizations with role-based access

- MCP server for all AI clients that support MCP

- Organization-scoped storage keeps tenant data separated

- Group visibility rules decide which memories each member can search

- Authenticated MCP access ties every request back to a real user and workspace

- Feedback signals can be captured now and used to improve ranking later

- Supports desktop versions of AI clients, not just their CLI versions (mobile app support should also work)

The backend is built with PostgreSQL, pgvector, Node.js, and TypeScript. The frontend uses Next.js, React, Tailwind CSS, and shadcn/ui (frontend is not my strong suit, please be kind). Authentication is handled with Clerk and billing with Stripe.

I started building this for my own workflow, but after relying on it for several months I decided to make it available to others. We soft launched a few weeks ago, and I find it useful as a daily tool.

Essentially, ContextVault offers a way to track memories and context, distribute them instantly to your team, and help reduce duplicated work.

I'd be interested in feedback on a few things:

- How are you managing reusable AI context today?

- Are you relying on similar tools, or do you keep everything in Git or Markdown?

- If you've built something similar, what did you learn that you would do differently?

You can see the product here:

https://www.contextvault.dev

Comments URL: https://news.ycombinator.com/item?id=48900288

Points: 12

# Comments: 11