SkillAgentSearch skills...

Vault-Agent-Memory

Local-first memory governance for AI agents: shared, reviewable, auditable memory via SQLite and MCP.

Install / Use

claude mcp add zycaskevin -- npx -y github:zycaskevin/Vault-Agent-Memory

If the server publishes to npm under a different name, use that package instead — check the repo README.

About this skill
🔌

MCP Server

Model Context Protocol server

Quality Score

84/100

Supported Platforms

Claude Code
Claude Desktop

Vault Agent Memory

English | 繁體中文 | 简体中文

Website · Founding 10 challenge · Live evidence · Reproduce independently · Methodology · Install

Vault is a local-first, backend-agnostic memory governance layer for AI agents.

Vault Agent Memory gives Codex, Claude Code, Hermes, OpenClaw, n8n, Coze, and other agents one governed memory vault to share. It is not trying to be another notes app or vector database. It helps agents decide what should be remembered, who can use it, whether it is still current, and how to roll it back when it is wrong.

Vault's product boundary is the governance contract, not a specific backend. The same candidate-first review model can run on local SQLite, a self-hosted central memory host, a Supabase cloud adapter, or a future managed Vault Cloud backend.

Vault works standalone, and it can also become the governed memory backend for other agent memory frameworks. You can use Vault by itself with CLI, MCP, Gateway, and local SQLite; or let frameworks such as Hermes, OpenClaw, Letta, mem0, Claude Code, and Codex connect through Vault APIs while Vault keeps the review, audit, lifecycle, and backend boundaries consistent.

The core multi-agent model is single-host sharing, multi-host governed sync: agents on one trusted machine can share the same local Vault, while agents on other machines or hosted runtimes can read approved memory and submit candidates. Only a trusted sync host promotes official memory, runs lifecycle jobs, and pushes reviewed read copies back out.

The Python package and existing install path remain vault-for-llm.

Vault is for people already building or working with agents. The main interface should still not be a long CLI manual: ask an agent to install Vault, answer a few setup questions, then read a short daily memory report.

New here? Start with the public website. It explains why Vault is a memory foundation—not merely another memory system—and publishes paired A vs A + Vault evidence with the full method and raw artifacts.

Release Maturity

Vault Agent Memory v0.10.2 is a Public Beta / Developer Preview release. The local-first path is ready for agent developers to try in real projects, and the multi-agent model is intentionally conservative:

  • local SQLite/Markdown remains the source of truth;
  • same-machine agents can share one trusted Vault;
  • remote or hosted agents read approved memory and submit candidates;
  • only a trusted sync host should hold service-role credentials, promote official memory, run Dream/forgetting/archive jobs, and push reviewed read copies;
  • central vector search is a derived read layer over reviewed safe summaries, not a second active-memory database.
  • backend adapters can change, but the Vault Governance Contract stays the same: approved reads, candidate submissions, review, promotion, audit, and daily reports.

The package is pre-1.0. Advanced Supabase, Gateway, central vector, automation, and benchmark surfaces are useful for developer preview deployments, but should be enabled deliberately and monitored with the generated reports.

Deployment is intentionally layered:

Agents / Apps / Memory Frameworks
  -> Vault Memory API plus MCP / Gateway / OpenAPI adapters
  -> Vault Gateway / Vault Governance Contract
  -> Memory Provider Interface / Backend adapter
  -> Local SQLite / Self-host central host / Supabase / future Vault Cloud

30-Second Version

Vault Agent Memory exists because agent memory fails in practical ways:

  • a new session acts like it joined the project on day one
  • bug fixes stay buried in chat history
  • old notes outrank newer decisions
  • private observations leak into shared project memory
  • remote agents can pollute shared memory if every host can write active truth
  • teams cannot tell which memory was reviewed, trusted, or deprecated
flowchart TB
    subgraph Agents["🤖 Your Agents"]
        C[Codex]
        CL[Claude Code]
        H[Hermes]
        CO[Coze]
        N[n8n]
    end

    subgraph Vault["🔐 Vault — Governed Memory Layer"]
        direction TB
        Pipeline["Review Pipeline<br/>Privacy · Duplicates · Quality · Source"]
        Report["Daily Report<br/>Auto-promote low-risk · Review high-risk"]
        subgraph Layers["Memory Layers"]
            L0["L0 Identity"]
            L1["L1 Rules"]
            L2["L2 Context"]
            L3["L3 Knowledge"]
        end
        Ledger["Task Ledger<br/>Live workbench · Handoffs"]
        Storage["SQLite / Markdown<br/>Local-first · Zero dependencies"]
    end

    subgraph Adapters["🔌 Adapters / Backends"]
        Obs[Obsidian Sync]
        Sup[Supabase]
        GW[Gateway API]
        SH[Self-host Host]
        VC[Vault Cloud Future]
    end

    Agents -->|propose| Pipeline
    Agents -->|search / bounded read| Layers
    Agents -->|update status| Ledger
    Pipeline --> Report
    Report --> Layers
    Layers <--> Ledger
    Layers --> Storage
    Adapters <-->|import / export / sync / managed backend| Vault

    style Agents fill:#e1f5fe,stroke:#0288d1
    style Vault fill:#f3e5f5,stroke:#7b1fa2
    style Adapters fill:#e8f5e9,stroke:#388e3c

Why Vault?

| Without Vault | With Vault | |---------------|------------| | Each agent remembers separately, repeating the same mistakes | One shared memory vault — learn once, benefit everywhere | | Old info fights with new decisions; agents don't know what to trust | Temporal boundaries + expiry — always surface the most current truth | | Sensitive info leaks everywhere; no audit trail | Governance metadata — who sees what, track every change, rollback anytime | | Memory is just a pile of chat logs, hard to find signal | Candidate → Review → Promote — only what's useful stays | | Cross-host agents write directly into one shared store | Remote agents submit candidates; a trusted sync host reviews and promotes |

The core workflow is:

propose -> review -> promote -> search -> bounded read -> rollback -> audit

In plain language:

Vault is not about helping agents remember everything. It is about helping teams govern what agents remember, trust, share, forget, and roll back.

Who Are You? Start Here 👇

| Role | What You Care About | Starting Point | |------|---------------------|----------------| | 🧑‍💻 Agent Developer | How do I plug Vault into my agent? | → MCP Integration Guide | | 🤖 Power Agent User | How do I stop Claude/Codex from forgetting? | → 5-Minute Quickstart · Copy the install prompt to your agent | | 👥 Team Collaboration | How do multiple agents share memory without chaos? | → Three-Agent Shared Memory Demo | | 📝 Obsidian User | How can agents safely use my notes? | → Obsidian Integration | | 🏗️ Architect / Tech Lead | Is this reliable? What's the architecture? | → Design Decisions · Benchmarks |

For Agent Builders: Ask Your Agent To Install It

Copy this prompt into an agent that can run local commands:

Install Vault Agent Memory for this project. Use vault-for-llm[mcp]==0.10.2.
Use the agent-assisted governed-auto memory mode.

Do not show advanced CLI flags first. Ask me only four questions:
1. Which language should Vault use: Traditional Chinese, Simplified Chinese, or English?
2. Should this be an independent vault or a shared vault for multiple agents?
3. Should Vault connect to Obsidian, Supabase, both, or neither?
4. What time should the daily memory report run?

After setup, run a smoke check and tell me:
- where the vault lives
- how I read the daily memory report
- where the local GUI or next action is

Daily rule:
safe, low-risk, sourced memories can be kept automatically;
uncertain, sensitive, conflicting, or strategic memories should go into the
daily report for my review.

The agent will usually run:

python3 -m venv .venv
source .venv/bin/activate
pip install "vault-for-llm[mcp]==0.10.2"
vault quickstart

You can also print the install prompt from Vault itself:

vault guide --intent install

To check for a newer release without changing the environment:

vault upgrade --check

Vault detects common pip, pipx, uv tool, and editable installs and prints the appropriate upgrade command. This first-stage command is check-only: it does not install packages or migrate vault.db.

vault quickstart is the small first-run wizard. It asks only for language, independent/shared memory, optional Obsidian/Supabase connections, and daily report time. See docs/quickstart.md for the 5-minute walkthrough and FAQ. Advanced integration flags stay under vault setup-agent.

Agent-assisted quickstart uses governed-auto by default. Internally this is still the consumer setup path, but that does not mean Vault is a zero-learning consumer app. Low-risk, sourced candidates that pass privacy, duplicate, metadata, and quality gates may enter the active vault. Strategy, private, sensitive, conflicting, or low-trust memories stay in the daily report for human review. Nothing is hard-deleted automatically.

Daily Use

The intended human surface is small:

  1. Agents propose reusable lessons while they work.
  2. Vault checks privacy, duplicates, quality, and source evidence.
  3. Safe low-risk memories can enter the vault.
  4. Uncertain decisions are summarized in a daily report.
  5. The user approves, rejects, defers, or keeps both sides for conflicts.

The report should answer:

  • What did Vault remember today?
  • What few memory decisions need my attention?
  • Are there stale, sensitive, conflicting, or low-quality memories to review?

That is the product shape: more automatic over time, but still governed.

What Vault Is Not

Vault is not an Obsidian replacement.

Obsidian is great for humans reading notes. Vault helps agents use those notes safely, with source ranges and review boundaries.

Vault is not just RAG.

RAG usually focuses on retrieving context. Vault focuses on the memory lifecycle: who wrote it, whether it was reviewed, which agents can read it, when it stops being current, and how to roll it back.

Vault is not a raw chat-history landfill.

It is candidate-first. Agents can suggest memory, but long-term memory should stay source-backed, reviewable, and clean.

Vault is not a zero-setup app-store product for people who do not use agents.

The first public audience is agent-assisted builders: people using Codex, Claude Code, Hermes, OpenClaw, n8n, Coze, or similar systems who want one governed memory layer without studying every internal command.

How Vault Compares

Vault is complementary to memory services and agent runtimes, not a drop-in replacement for all of them.

| Tool category | Strong at | Vault's different focus | |---------------|-----------|-------------------------| | Mem0 | Managed memory APIs, personalization, cloud/self-hosted deployments, and published memory benchmarks | Local-first governance, review gates, rollback, daily human review, and multi-agent adapter setup | | Letta / MemGPT | A stateful agent platform with a memory-first agent, dreaming, skills, and agent-managed memory | A shared governed memory layer that existing agents can use without becoming one specific agent runtime | | Vector databases / RAG stacks | Fast retrieval over embeddings and documents | The memory lif

Truncated for display — read the full file on GitHub.

Related Skills

View on GitHub
GitHub Stars50
CategoryAI
Updated25d ago
Forks12

Languages

Python

Security Score

100/100

Audited on Aug 27, 2026

No findings