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 proj