Skip to content

eden-memory

The durable memory and sync component of ATP. Local SQLite, vector embeddings, MCP server, and optional multi-device sync.

eden-memory is the memory and sync component of the Agentic Team Protocol. It gives ATP agents persistent, local-first memory: facts, preferences, context, and lifecycle records stored in a SQLite database on your machine.

It is also useful on its own as an MCP memory server for any stdio MCP client.

  1. Remember — your agent stores a fact or context via eden_remember.
  2. Embed — the binary embeds the content as a 256-dim vector.
  3. Store — the memory and vector go into ~/.eden-memory/default.db.
  4. Recall — later, your agent asks eden_recall; eden-memory returns the closest matches by cosine similarity.

There is no cloud account, no external API, and no network call for recall. First run extracts the embedded runtime and model weights to your platform cache; the SQLite database stays under ~/.eden-memory/. Optional encrypted multi-device sync runs through a self-hosted eden-relay so the contents stay opaque to the relay operator.

If you use Claude Code, run the agentic-team-protocol on top of eden-memory. It adds role-based subagents (Dispatcher, Researcher, Builder, Verifier, Archivist) and a seven-stage lifecycle, all backed by the same local SQLite store.

Each 0d3sa release ships three related single-file Go binaries:

  • eden-memory — this component: memory, MCP server, sync, and pairing.
  • eden-relay — dedicated relay server for multi-device sync. See eden-relay docs.
  • eden-team — headless ATP supervisor for CI and automation. See eden-team docs.