Shared memory for AI coding agents

One memory. Every agent. Every session.

Your agent forgets everything when the window closes. zero-memory gives Claude Code, Cursor, Codex and any MCP client one shared, persistent store — so the decision you explained yesterday is already known tomorrow. By your agent, and by your teammate's.

Open source, Apache-2.0. Run it on your own Postgres, or use ours.

zero-memory sits between your editors and one Postgres store Claude Code Cursor Codex · teammate zero-memory MCP Postgres pgvector · FTS · RLS

The problem

Every session starts from zero

You explain the architecture. The agent gets it, does good work, and the window closes. Tomorrow you explain the same architecture to the same model, which now proposes the approach you rejected last week — because nothing told it you had.

Multiply that by every tool you use and every person on your team. The knowledge exists. It just lives in transcripts nobody can search.

What accrues

Context that compounds instead of resetting

Every session leaves something behind: a decision with its reasoning, a gotcha that cost an afternoon, a convention nobody had written down. The store grows while you work, and the next session opens with it already loaded.

The compounding-context chart from a real instance — facts captured for one developer, accumulating across sessions.

app.zero-memory.com
Compounding context chart showing facts captured accumulating over 30 days

How it works

Write once. Every agent reads it.

A briefing before the session starts

One call returns the standing rules, the live work, and the decisions behind the code about to be touched. Clients with hooks do it before you type anything.

The reasoning, not just the fact

Decisions with the why behind them. Gotchas. Conventions. Open loops that stay visible until someone actually closes them.

Speaks MCP, works where you work

Claude Code, Cursor, Codex CLI, VS Code. One server, one store, no per-tool setup and no per-tool copy of the truth.

What changes

Memory that gets sharper with use

Everyone can store and retrieve. A store that only grows becomes a junk drawer: current decisions mixed with drafts, five retellings of one migration, abandoned notes from someone else's session.

The usual answers are keep everything and drown, or delete on a timer and lose things. zero-memory does neither: it changes what surfaces, and leaves the corpus alone.

01

It forgets like a person, not like a database

Session logs fade in a month, loose ends in two weeks, plain facts in a year, gotchas in about three, decisions and conventions in ten. Nothing is deleted — old material sinks in ranking, and a direct question still finds it.

02

Five drafts of one story become one summary

When several episodes tell the same saga, the system notices and proposes a single consolidated fact, linked back to every source. You approve it. Nothing enters the corpus without a human.

03

Ranking learns from what helped, and from what misled

It distinguishes shown from used. What proved useful surfaces earlier; what demonstrably sent someone down the wrong path loses rank and goes to a review queue rather than getting deleted. Silence moves nothing, so a fact nobody happened to need is never buried.

04

Facts about the outside world get re-checked

Library versions and API behaviour go stale on their own schedule, so those carry a "last checked N days ago" marker and a background sweep verifies them against the live web. Your conventions are exempt: their oracle is you, not a changelog.

How it ages: faded-in-ranking and corpus-age tiles with an age-bucket strip
Aging is observable, not a promise: the share past its half-life, the median age, and the whole corpus by age bucket.
Quality tiles: usefulness hit-rate, surfaced-fact age, and context precision
Quality is measured as you work, not sampled afterwards.

What it is worth

The dashboard argues with itself, so you don't have to trust it

A memory layer is easy to believe in and hard to justify. So the instance measures its own contribution: how much of what it surfaced was actually used, how old those facts were, how much of it was on topic. When there is not enough signal to answer honestly, the tile says so instead of showing a flattering zero.

Boundaries

Your memory, not your model's

Scopes are personal, project, or team, and every scope is owner-namespaced — two projects with the same name never see each other.

Access comes from explicit membership, enforced by row-level security in Postgres rather than by application code. A memory is private to whoever wrote it until it is shared, and it travels with its provenance: who wrote it, when, and from which conversation.

Sharing is a deliberate act. The default is private, and private is what you get when you forget to decide.

Nothing hidden

You see exactly what your agent sees

The dashboard's search is not a simplified view for humans. It calls the same engine your agent calls over MCP: one function, one ranking, the same scores. What you read on screen is what lands in the agent's context, down to the byte. A test keeps the two in step.

Every mechanism is inspectable. Aging profiles are a table. Usefulness multipliers are a table. A consolidated summary carries links to its sources. Every automatic action is in the audit log.

Run it yourself

Self-hosted, open source, yours

The whole thing is Apache-2.0 on GitHub: MCP server, dashboard, Postgres schema, client bundles.

Core memory — recall, remember, search, scopes, briefings — runs locally and needs no model-provider key at all. A fresh install reads your memory and sends nothing anywhere. Model-backed extras use your own provider credential, and transcript ingest ships off.

Honest answers

The questions people actually ask

Will it delete something important?
No. Nothing is deleted automatically, ever. Aging changes position in results, consolidation happens only with your approval, and an approved summary leaves its sources intact. Even a record proven to have misled someone is not deleted: it loses rank against a floor and goes to a human review queue.
Does it only keep the relevant stuff?
It keeps everything, append-only, with an audit trail. Relevance is decided on read: only what is alive, current, and proven useful reaches the agent's context. A filter on read is a filter you can be wrong about safely.
Is this another black box over embeddings?
Every mechanism is a table you can read and a log you can check — aging profiles, search parameters, usefulness multipliers, and the provenance of every consolidated fact.
What if there isn't much signal yet?
It degrades to honest hybrid search and turns itself up as your work accumulates. There is no training month to sit through.
Do you see my code?
The hosted instance stores what you and your agents write to it, nothing more. Self-host if you want that answer to be structurally impossible rather than a promise.

Your next session can start with everything you already know

A free account on the hosted instance, or clone the repository and run your own. Both lead to the same product.