OneMemory: Shared Memory for AI Agents

Your AI tools keep forgetting each other. OneMemory gives every MCP agent one shared, permanent memory in CockroachDB.

Comment

Inspiration

Every AI coding tool today has amnesia the moment you switch context. Tell Claude Code a project decision or a preference, then open Cursor an hour later — and you're explaining it all over again. Memory today is trapped per tool, not owned by the person using the tools.

I wanted to ask a simple question: what if memory wasn't a feature bolted onto one app, but shared infrastructure that any AI agent could plug into? That's where OneMemory came from — and CockroachDB, with its native distributed vector indexing and first-class MCP support, turned out to be exactly the right foundation to build it on.

What it does

OneMemory gives any MCP-compatible AI agent (Claude Code, Cursor, or any custom tool) access to a single, persistent, semantically searchable memory layer:

  • remember — store a fact, preference, or decision, embedded locally and written to CockroachDB.
  • recall — semantically search across everything ever stored, regardless of which tool originally wrote it.

Store a fact in one tool. Recall it, automatically, from any other. The memory doesn't belong to the tool — it belongs to CockroachDB.

We proved this works end-to-end: a fact stored under a "Claude Code" identity was correctly recalled — via pure semantic similarity, not keyword matching — by a completely separate "Cursor" session, with no re-explaining required.

How I built it

  • CockroachDB Serverless (free tier) as the single source of truth, with a VECTOR(384) column and a native Distributed Vector Index (vector_cosine_ops) for fast semantic recall as memory grows.
  • An MCP server (TypeScript) exposing remember and recall as tools, connectable from Claude Code, Cursor, or any MCP client via a simple config snippet.
  • Local embeddings via @xenova/transformers (all-MiniLM-L6-v2), running entirely in-process — no paid embedding API, which kept the whole project genuinely free-tier friendly.
  • Amazon S3, hosting a live static dashboard that mirrors what's stored in CockroachDB in real time — a transparent, public window into the agent's memory that anyone can check without terminal access.

Challenges I ran into

This project taught us as much about infrastructure friction as it did about agentic memory:

  • Web SQL console timeouts on DDL statements — CREATE DATABASE/CREATE TABLE kept getting cancelled through the browser-based SQL shell, even though simple SELECT queries worked fine. We worked around it by running statements individually and, eventually, connecting directly instead of relying on the web console for schema changes.
  • CLI argument parsing quirks — claude mcp add failed with cryptic "missing required argument" errors when passing multiple --env flags before the server name on Windows PowerShell. The fix was reordering arguments and, ultimately, editing the MCP config JSON directly for full control over environment variables.
  • PATH not refreshing after installs — both the AWS CLI and Node tooling required fully restarting the terminal (and in one case, VS Code itself) before newly installed executables were recognized.
  • API billing constraints — testing remember/recall through a live LLM conversation required API credits we didn't want to spend. We solved this by writing a standalone MCP test client that calls the tools directly, letting us verify the entire pipeline — embeddings, CockroachDB writes, vector search — for zero cost, and even simulate two different "tools" (Claude Code and Cursor) writing to and reading from the same memory layer to prove cross-tool recall.

None of these were glamorous problems, but they're the real friction anyone deploying an agentic memory layer will hit — and solving them cheaply and reproducibly was, in a way, its own proof that this can run comfortably within free-tier constraints.

What I learned

  • Agent memory is most valuable when treated as infrastructure, not a per-app feature — the moment memory is portable across tools, it starts feeling like something a user owns rather than something a product owns.
  • CockroachDB's vector indexing genuinely simplifies architecture: no separate vector store to keep in sync, no consistency gaps between structured and embedding data.
  • A lot of "AI demo" friction has nothing to do with AI — it's tooling, PATH variables, and console quirks. Building for reproducibility (a standalone test client, a one-shot S3 setup script) mattered as much as the core logic.

What's next

  • Automatic conflict resolution when two tools store contradictory facts about the same project.
  • A "confidence decay" mechanism, so memories that are no longer acted on naturally fade in relevance.
  • Expanding beyond developer tools — the same shared-memory pattern applies to any MCP-compatible agent, not just coding assistants.
Share this project:

Updates