OneMemory: A Self-Hosted Server That Lets AI Agents Share Memory

Collaboration between AI agents is often limited by their isolated context windows—Claude doesn't know what you discussed with another LLM on your phone, and a PC session can't hand off tasks to mobile. An open-source project called OneMemory that appeared on Reddit aims to solve this with a small self-hosted server: through MCP and REST interfaces, different AI agents can share notes, tasks, and handoff information.

Project Positioning: A Shared Memory Layer for AI Agents

OneMemory's core idea is straightforward: run a lightweight server on your machine, with data stored in a local SQLite database and encrypted at rest. Any AI client that supports MCP (Model Context Protocol)—including Claude and other LLMs—as well as sessions on phones and PCs, can read and write shared notes and task state through this interface.

According to the project author on Reddit, this is a "small server," not a platform-level product. It addresses the context fragmentation problem for individual users switching between multiple devices and multiple agents: you have Claude on your PC compile a task list, then continue it on the go with another assistant on your phone, and the shared memory layer ties these states together.

MCP (Model Context Protocol) is a standardized protocol proposed and open-sourced by Anthropic in late 2024, designed to provide a unified way for AI applications to connect with external tools and data sources. Think of MCP as the "USB-C port of the AI world": clients (such as Claude Desktop and various IDE plugins) discover and invoke external capabilities via resources, tools, and prompt templates exposed by MCP servers in JSON-RPC form, without having to write separate adapter code for each data source. MCP typically runs over stdio or HTTP/SSE transport; the server declares which capabilities it provides, and the client dynamically loads them accordingly. This is exactly the technical prerequisite that allows OneMemory to serve Claude and other LLM clients at low cost—any client implementing MCP can directly connect to this shared memory layer.

Encryption at rest refers to protecting data by storing it on disk in ciphertext and only decrypting it in memory, as distinct from transport encryption (such as HTTPS). In self-hosted scenarios, encryption at rest primarily guards against risks such as device loss, leaked backup files, or physical disk reads. Common implementations include SQLCipher (encrypting the entire SQLite database) or application-layer encryption of sensitive fields individually. Note that encryption at rest does not defend against attackers who already have execution privileges—if the process can decrypt the data, malicious programs on the same host usually can too. It is therefore often paired with key management (such as the system keychain), and is a cost-effective baseline protection for personal self-hosted tools.

Feature Iterations Driven by Community Feedback

The author specifically noted that after the first version was released, feedback from the Reddit community directly drove several key changes:

• Server-stamped authorship attribution: Every note carries a server-side author marker written at ingestion, preventing agents from impersonating each other or confusing provenance.
• Administrator "distrusted writer" list: Administrators can place specific writers on a distrust list to limit the reach of their content.
• Queued command status when the PC is asleep: When the host PC is sleeping, commands sent to the server enter a queue and show their status rather than failing silently.
• Security upgrade with automatic backups: The upgrade process includes automatic backups, reducing the risk of data corruption from version updates.

These changes all point to the same issue: when multiple agents share memory, trust and consistency matter more than the number of features.

Trust Model: The Author Actively Invites Criticism

In the post, the author unusually puts limitations front and center: this is a one-person project, the signed export feature is still experimental, and he explicitly states it is "not yet ready for hostile multi-tenant environments." He even specifically invites the community to critique his trust model and points to the docs/trust.md document in the repository.

This candor is worth noting. A shared memory layer is essentially a "public blackboard" among agents; once writer identity can be forged or notes can be maliciously poisoned, the value of the entire memory layer flips into a risk. Server-stamped authorship and the distrust list are initial lines of defense, but the experimental status of signed export shows that the integrity verification chain is not yet closed. For personal or small-team self-hosted scenarios, this mechanism may be sufficient; for any scenario requiring isolation of untrusted participants, the author himself does not recommend using it.

A hostile multi-tenant environment refers to a scenario where multiple mutually distrusting users or agents share the same system and data storage, typical of SaaS platforms or open-registration collaboration services. In such environments, security design must assume that at least one party will actively attempt to forge identities, read beyond their privileges, poison data, or exhaust resources. This is fundamentally different from "trusted multi-tenancy" (such as members within the same organization) or "single-tenant self-hosting." OneMemory explicitly does not target this scenario, meaning it does not implement tenant isolation, fine-grained permissions, anti-poisoning verification, and similar mechanisms; for individuals or small teams these are not essential, but once untrusted writers are introduced, the single-point trust assumption breaks down.

Trade-offs of the Self-Hosted Approach

Choosing SQLite + local encryption + self-hosting means users bear operational responsibility themselves, but gain control in return—data never leaves the local machine. Compared with agent memory solutions that rely on cloud sync, OneMemory's privacy properties are clearer, at the cost of availability depending on your own machine—the design of queuing commands while the PC is asleep is precisely a patch for this shortcoming.

The project's use of MCP as the primary interface also aligns with the current trend in the AI tool ecosystem: MCP is becoming one of the de facto standards for agents to connect to external tools and data, and a memory layer built on it can connect to clients from different vendors at low cost, without needing separate adapters for each LLM.

"Blackboard" is a classic architectural metaphor in AI and multi-agent systems: multiple independent agents read and write information around a shared data structure (the blackboard) and collaborate indirectly through it, without needing direct pairwise communication. The blackboard model first appeared in the HEARSAY-II speech recognition system in the 1980s; its advantages are decoupling and easy extensibility, while its disadvantage is that the quality of the shared state directly determines overall reliability—if any party writes erroneous or malicious content, other agents may adopt it as fact. OneMemory's shared memory layer is essentially a persistent blackboard, which explains why the author prioritized "server-stamped authorship" and the "distrust list" in feature iterations: the success of a blackboard architecture depends on the traceability and trustworthiness of writers.

Who Should Try It

If you use Claude and other LLMs simultaneously, frequently switch tasks between PC and phone, and are willing to run a local service yourself, OneMemory deserves a spot on your watchlist. Its functional boundaries are clear, and the author is honest enough about its limitations. But if what you need is shared memory among multiple users or untrusted participants, or you require signature verification at production-grade strength, you should be cautious at this stage—this is also the author's own position.

The project is open-sourced on GitHub, and the feedback the author most wants is centered on the design of the trust model.