ai-memory: Share Long-Term Memory Across Coding Agents

Overview

ai-memory gives coding agents a shared, persistent memory that can outlast a session, machine, or agent vendor. Lifecycle hooks capture work, then the service turns observations into Markdown pages that agents can search and use for handoffs. The default capture, search, and handoff paths do not require an LLM API key.

The project is designed for people who want to own and inspect their memory files rather than rely on separate, vendor-specific notes. It can run locally or as a shared server for multiple machines and teammates, with project knowledge shared while personal handoffs remain separate.

Key Features

• Captures prompts, tool calls, and session boundaries through agent lifecycle hooks, with sanitization and configurable capture rules.
• Stores the source of truth as git-backed Markdown pages; SQLite provides a derived search index.
• Supports retrieval through full-text search, entities, links, and optional vector search.
• Provides typed, claim-once handoffs so another supported agent can pick up unfinished work.
• Offers integrations for a broad range of coding-agent harnesses through MCP registration, hooks, or both.
• Supports a shared server with multi-user authentication, per-person attribution, and an audit log.
• Includes optional LLM features for summaries and semantic search, while the default path works without them.

Use Cases

• A solo developer switches from one coding agent to another mid-task and wants the next session to retrieve prior decisions, failed approaches, and open questions.
• A developer works on the same project across machines and wants the project wiki and handoffs available from a self-hosted server.
• A team wants agents to retrieve shared project knowledge while keeping individual handoffs personal and recording who made changes.
• A developer wants to inspect, edit, or version-control agent memory as ordinary Markdown instead of depending on a vendor-specific memory store.

Getting Started

See the README for platform-specific installation and agent setup. Once installed and configured, launch a harness through ai-memory to enable its managed continuity workflow:

ai-memory run claude

Alternatives

• EverOS: EverOS preserves conversations and context for agents across apps, while ai-memory captures coding-agent activity in a git-backed project wiki.
• OpenViking: OpenViking organizes agent knowledge, memories, and skills in a virtual filesystem, rather than recording coding work as a git-backed Markdown wiki.
• atlas: Atlas captures coding-agent sessions in a desktop workspace tied to Git, while ai-memory is a self-hosted service for searchable project memory and handoffs.
• memoripy: Memoripy is a Python memory runtime for screening evidence and tracking changing facts, rather than a Rust service that records coding-agent activity.

Considerations

• The project is new and changing quickly, despite frequent recent commits and releases. Treat upgrades and data recovery as operational concerns, and review the project’s backup and lifecycle guidance before relying on it for important work.
• The core service requires Rust 1.95 or newer when building from source. SQLite is part of its indexed storage design; the README does not list a GPU requirement.
• LLM-backed summaries and semantic search are optional, but require configuring supported providers. The default path avoids that dependency.
• Integrations differ: some are MCP-only, hooks-only, managed-only, or experimental, and native Windows is listed as experimental. Check the support matrix for your target setup.
• A shared server introduces deployment and access-control responsibilities. The README recommends loopback binding for a single-user setup and describes authentication and TLS options for broader access.