T. / Journal

Inside OpenHuman: The Memory Architecture Behind an Open-Source Personal AI

OpenHumanMemory

May 20, 2026

Engineering Notes

6 min read

A three-layer summary tree replaces full-corpus RAG search, with a look at its hierarchy, comparisons with Mem0 and MemGPT, and the experience behind two merged contributions.

As an OpenHuman contributor, I am breaking down the project's core—the Memory Tree architecture—at the source-code level. If you are interested in long-term memory systems for AI agents, this article offers a different perspective.

1. What Is OpenHuman?

OpenHuman is an open-source personal AI superintelligence assistant with 22k+ GitHub stars. It is developed by the tinyhumansai team and is currently in early beta.

Its core idea is simple: connect all your data sources—Gmail, Notion, GitHub, Slack, Calendar, and more than 118 integrations—with one-click OAuth; automatically pull data every 20 minutes; compress it into structured knowledge; and store it locally. This means the agent does not need to start cold. Once your accounts are connected, it can understand your full context.

Several key features:

Local-first: Your data stays on your own machine instead of being uploaded to the cloud
Model Routing: Automatically assigns tasks to different LLMs for reasoning, speed, or vision
TokenJuice: A token-compression engine claimed to reduce costs by 80%
Desktop avatar: Can speak and join Google Meet calls
Tech stack: 70% Rust and 26% TypeScript, with a desktop app built on Tauri

It was inspired by Karpathy's Obsidian wiki workflow: using a structured local knowledge base instead of fragmented cloud data.

2. The Memory Module: The Core of the System

The most interesting part of OpenHuman is not its UI or integrations, but its Memory architecture. That was my biggest takeaway from reading the source deeply, although it also happens to align with the area I care about.

2.1 Layered Architecture

The Memory module follows a classic layered design, from bottom to top:

┌──────────────────────────────────────┐
│  conversations/   slack_ingestion/   │  Domain adapter layer
├──────────────────────────────────────┤
│  tree/   (bucket-seal retrieval pipeline) │  New retrieval architecture
├──────────────────────────────────────┤
│  ingestion/        (extraction + chunking) │  Document ingestion layer
├──────────────────────────────────────┤
│  store/      (UnifiedMemory backend) │  SQLite + FTS5 + vectors
├──────────────────────────────────────┤
│  traits.rs           (Memory trait)  │  Abstract contract layer
└──────────────────────────────────────┘

Layer 1: Abstract contract (traits.rs)

It defines the Memory trait, the interface that every storage backend must implement:

#[async_trait]
pub trait Memory: Send + Sync {
    fn name(&self) -> &str;
    async fn store(&self, namespace: &str, key: &str, content: &str, ...) -> Result<()>;
    async fn recall(&self, query: &str, limit: usize, opts: RecallOpts<'_>) -> Result<Vec<MemoryEntry>>;
    async fn get(&self, namespace: &str, key: &str) -> Result<Option<MemoryEntry>>;
    async fn forget(&self, namespace: &str, key: &str) -> Result<bool>;
    // ...
}

Memory categories are represented by the MemoryCategory enum:

Core: Long-term facts and user preferences, similar to semantic memory
Daily: Time-based activity logs, similar to episodic memory
Conversation: Conversation context
Custom(String): Custom extensions

Interestingly, OpenHuman uses namespaces for isolation instead of relying only on a fixed enum of memory types. This means any data source—Gmail, Slack, or GitHub—can have its own namespace, making the design more flexible than Mem0's fixed categories.

Layer 2: Unified storage (store/)

UnifiedMemory is the production backend implementation. A single SQLite database handles everything:

FTS5 for keyword search
Vector tables for semantic retrieval
Graph tables for entity-relation triples

Many RAG systems combine FAISS, Redis, and PostgreSQL. OpenHuman instead chooses an all-in-one SQLite approach. That is the right fit for a local-first design: users do not need to install a collection of middleware.

2.2 Memory Tree: The Most Important Design

Memory Tree is the most distinctive part of OpenHuman, and the biggest fundamental difference between it and approaches such as Mem0, MemGPT, and Zep.

A traditional RAG retrieval flow is: query → embedding → full-corpus search → rerank → return. This is query-time fusion.

OpenHuman's Memory Tree builds a hierarchical summary tree at write time, then searches the tree directly at query time. The idea is completely different. It is closer to how human memory is organized: categorize first and recall later, rather than searching the entire corpus every time.

The data pipeline:

Raw data (chats/emails/documents)
    ↓
canonicalize/  →  Normalize into standard Markdown + metadata
    ↓
chunker.rs     →  Split into chunks of ≤3,000 tokens with deterministic IDs
    ↓
content_store/ →  Store each chunk as a .md file on disk
    ↓
store.rs       →  Persist to SQLite (chunks, scores, summaries, hotness)
    ↓
score/         →  Score chunks (embeddings + entity extraction)
    ↓
Three-layer tree:
  tree_source/  →  Source-level summaries (for example, "Gmail summary")
  tree_topic/   →  Topic-level summaries (for example, "everything about Rust")
  tree_global/  →  Global daily summaries
    ↓
retrieval/     →  Retrieval interface

The three-layer tree is the key:

tree_source: Aggregates by data source. Your Gmail has one tree, GitHub another, and Slack another. Inside each tree is a hierarchy of L0 buffer → L1 seal → cascade.
tree_topic: Aggregates by entity and topic, and lazily loads based on hotness. Frequently accessed topics have summaries built first.
tree_global: Produces a global daily summary, giving the agent an overall view of "what happened today."

The benefit of this design is that retrieval does not need to scan the full corpus. Instead, it uses the query intent to locate the relevant tree node and directly returns an already organized summary. For a personal assistant that needs to understand context across time and across data sources, this is much more efficient than pure vector retrieval.

2.3 Comparison with Mem0, MemGPT, and Zep

Dimension	OpenHuman	Mem0	MemGPT	Zep
Storage backend	All-in-one SQLite	Multiple backend options	Hierarchical memory	PostgreSQL
Retrieval	Hierarchical summary tree	Vector retrieval	Context-window management	Hybrid retrieval
Data organization	Namespace isolation	Fixed categories	Conversation-centered	Session-centered
Local-first	✅ Fully local	❌ Cloud-first	❌ Requires an API	Partially supported
Multi-source integration	118+ data sources	Custom implementation required	None	Limited

OpenHuman's strength is that it is not merely a memory library, but a complete personal data center. Its weakness is that the project is still very young: the code evolves quickly, but its stability has yet to be proven.

3. What Contributing Was Really Like

I contributed two PRs to OpenHuman, both of which were merged:

PR #1629: Windows development environment documentation

I went through the complete Windows setup process as a newcomer and found several gaps in the documentation: installing Visual Studio Build Tools, the LLVM/Clang dependency, the CMake dependency, Windows PATH length limits, and more. I organized these findings into a Windows section in CONTRIBUTING.md.

PR #1891: A bug fix for the Memory chunker

When split_on_lines encountered an extremely long single line—for example, a 25,000-character paragraph with no line breaks—it did not split the line and instead emitted it as one chunk. This caused:

Embedding costs 125 times higher than normal
Retrieval to return one enormous blob instead of a precise excerpt

The fix was to split lines longer than max_chars at word boundaries with split_whitespace, while ensuring that extremely long individual words, such as URLs, were not broken apart. The founder, senamakel, refined the implementation further on top of my work, and it was ultimately merged.

My overall impressions of the contribution process:

The project is maintained very actively; PRs usually go from submission to merge in one to three days
A CodeRabbit bot performs automated reviews, helping maintain code quality
The founder will iterate directly on your branch, which makes collaboration very efficient
Every submodule has its own README, and the code is easy to read

4. Conclusion

OpenHuman is worth watching not because of how usable it is today, but because its Memory Tree architecture represents a new direction for memory systems in personal AI assistants: instead of brute-force search at query time, it builds a structured knowledge tree at write time.

If you are building AI agents or RAG systems, or are interested in personal knowledge management, I recommend reading the source under src/openhuman/memory/, especially the implementation in the tree/ directory.

Related links:

GitHub: https://github.com/tinyhumansai/openhuman
My PR #1629 (documentation): https://github.com/tinyhumansai/openhuman/pull/1629
My PR #1891 (code): https://github.com/tinyhumansai/openhuman/pull/1891

The author is an OpenHuman contributor and shares this understanding of the project from the perspective of reading its source and contributing to it in practice. Corrections to any technical inaccuracies are welcome.

Author: T | Optoelectronic Information Science and Engineering, Shantou University | AI Agent Track
GitHub: github.com/iuyup