Echo Memory runs on one storage engine — Postgres — from a single local agent up to an org-wide shared graph, with no forced migration in between. The novel part is the memory structure and the read/write algorithm running on top of it, not a new database engine underneath it. Here's what each layer actually does.

Storage: Postgres, pgvector, Apache AGE

Two extensions turn plain Postgres into what Echo Memory needs. pgvector handles vector similarity — embeddings, nearest-neighbor search, the part every memory tool needs somewhere. Apache AGE adds graph traversal on top of the same tables: openCypher queries against the entities-as-nodes, facts-as-edges model described in why the graph is the data model in the first place. Both extensions live in the same database as the same data. There's no separate vector store to keep in sync with a separate graph store, and no forced migration later as a graph grows from one person's local agent to an organization's shared one.

Retrieval: hybrid today, multi-hop next

v1a — what's running now — retrieves with hybrid vector and full-text search. That's the baseline every flat memory store also has, and it's what makes basic recall work today. v1b adds Personalized PageRank over the graph via networkx, for associative, multi-hop retrieval that hybrid search structurally can't do — walking a path across several connected, causal-typed facts instead of ranking each fact independently. v1b is gated, deliberately: it doesn't start until v1a demonstrates that recall earns its keep on its own.

Interface: Model Context Protocol

The MCP server exposes three tools — write_episode, query_memory, get_audit_log — over the Model Context Protocol. Any MCP-compatible agent reads and writes the same graph through the same three calls, whether that's Claude Code, Cursor, a chatbot, an ops agent, or something built in-house. For an agent that doesn't speak MCP at all, the same three operations are reachable directly — see the integrations documentation in the repository.

What the write path actually costs

Extraction happens in the calling agent, never on the server, so recording a memory makes zero LLM calls. Measured locally with echo-memory benchmark:

  • 15ms write, median
  • 8ms query, median
  • 1ms digest
  • Zero LLM calls per write

The tradeoff is explicit, not hidden: the calling agent has to arrive with entities and facts already extracted, which is more work for the caller than handing over a raw transcript. That's the reason the MCP tool contract spells the shape of a call out instead of accepting free text and doing the extraction server-side.

The staged build, honestly labeled

v1a — built. write_episode, query_memory, get_audit_log, the MCP server, and the echo-memory CLI are running today. v1b — gated. Causal-typed edges and Personalized PageRank retrieval across the graph, not just single-fact recall — deliberately not started, because v1a has to prove recall earns its keep first. v1.1 — planned. The org-wide tenancy model the broader vision depends on: per-agent, per-team, or organization-wide graphs, on the same Postgres instance.

The validated wedge driving v1a is specifically cross-tool coding agent memory — stopping Claude Code, Cursor, or anything else from losing context between sessions and tools. See the install guide to wire it in.