Die Memory-OS-Revolution hinter OpenHuman

2026 verschiebt sich der Wettbewerb um persönliche AI von „ist das Modell schlau genug?“ zu „erinnert sich der Agent an mich?“. ChatGPT Memory, Claude-Projektkontext, AGENTS.md in Coding Agents — alle lösen denselben Schmerz: LLMs sind stateless; System-Prompt-Bullets sind Post-its, keine Intelligenz. Das Open-Source-Projekt OpenHuman (TinyHumans AI, GPL-3.0) geht weiter und hebt „Memory“ auf die Ebene von CPU und Scheduler: ein Memory OS (Memory-Betriebssystem) — kein Vektor-Plugin, sondern local-first, auditierbare Memory-Tree-Pipeline. Dieser Artikel zerlegt die Architektur und erklärt, warum Apple-Silicon-Entwickler personal Agents zunehmend 7×24 auf Mac mini M4 Cloud Mac betreiben.

Warum Memory OS statt längerem Kontextfenster

Kontext von 8K auf 1M Token ändert nichts daran: nach dem Chat bleibt nichts in den Modellgewichten. Produkt-„Memory“ ist meist:

• einige Nutzerpräferenzen im System-Prompt;
• Session-RAG aus einer Vektordatenbank;
• Plugins, die Notion oder Drive temporär mounten.

Das hilft, fehlt aber OS-Abstraktion: einheitliches ingest, Persistenzformat, Retrieval-Scopes, Lifecycle und human-readable Storage. OpenHumans Memory-OS-Metapher: Memory Tree ist kein „noch ein Vector-Wrapper“, sondern normalisiert Mail, Slack, GitHub, Transkripte per deterministischer Pipeline zu Agent-querybarem, vom Nutzer öffbarem Markdown. Die Doku: „You can't trust a memory you can't read.“

Was ist OpenHuman

OpenHuman ist TinyHumans’ local-first Personal-AI-Agent-Desktop (Rust + Tauri) — „memory and doer“ Ihres digitalen Lebens, nicht nur Chat. Im Gegensatz zu Terminal-first Frameworks:

• Memory Tree + Obsidian Wiki für strukturiertes Langzeitgedächtnis;
• Auto-fetch zieht periodisch neue SaaS-Daten ohne manuellen Prompt;
• Toolchain: Websuche, Code-Tools, Browser, Cron, Multi-Agent, Voice, Google Meet Agent;
• 118+ OAuth-Integrationen (laut Vergleichstabelle — siehe aktuelle Doku).

Um Mai 2026 sorgte das Projekt auf GitHub und Product Hunt für Aufmerksamkeit — der Unterschied ist Memory OS, nicht noch eine Chat-UI.

Kern: deterministische Memory-Tree-Pipeline

Laut Memory Tree Doku durchläuft jeder Datensatz denselben Hot Path:

source adapters (chat / email / document)
        ↓
canonicalize    → normalisiertes Markdown + Provenance
        ↓
chunker         → deterministische IDs, ≤3k Token
        ↓
content_store   → atomische .md auf Disk
        ↓
store           → chunks.db (SQLite)
        ↓
score           → Signale + embedding + Entity-Extraktion
        ↓
source / topic / global trees  → Summaries pro Scope
        ↓
retrieval       → search / drill_down / topic / global / fetch

Drei Designprinzipien beim ingest

• Deterministic: Chunk-IDs content-addressed — kein Duplikat bei wiederholtem ingest.
• Fast: Hot Path ohne LLM, nur günstige Heuristiken.
• Bounded write: Einzeltransaktion — kein halbfertiger ingest in der DB.

Schwere Arbeit — embedding, Entities, seal-Summaries, Daily digest — läuft in der Background job queue (Standard: 3 Worker, Semaphore limitiert parallele LLM-Calls gegen Auto-fetch-Spitzen).

Drei Bäume: Source, Topic, Global

Das „Dateisystem“ von Memory OS ist kein flaches Key-Value, sondern drei wachsende Summary-Bäume:

Vektor-Ähnlichkeit wirkt unten mit, aber Baumstruktur liefert Kompression und Navigation — die Grenze zu „purem RAG-Sack“. Leaf-Lifecycle: pending_extraction → admitted → buffered → sealed (oder dropped); Retrieval kann provenance zurückverfolgen ohne Pipeline-Neulauf.

Obsidian Wiki: Memory muss lesbar, editierbar, löschbar sein

Dual-Write: jeder Chunk landet in memory_tree/chunks.db und als .md unter wiki/ — Obsidian-vault-kompatibel, inspiriert von Karpathys obsidian-wiki-Workflow. Die Intelligence-Seite bietet „In Obsidian öffnen“; Suchtreffer springen zur Quell-Markdown.

Für Entwickler:

• wiki/ per Git versionieren (Datenschutz beachten);
• fehlerhafte Agent-Memory direkt in .md korrigieren;
• Compliance: Klartext + Scores + Provenance statt Black-Box-Embeddings.

Auto-fetch: Memory OS „bucht“ aktiv

Die meisten Agent-Memories sind passiv — @-Datei, Link paste, manueller Export. OpenHumans Auto-fetch (~20 Minuten) durchläuft aktive Verbindungen und schreibt neue Mails, Messages und PRs in Memory Tree. Der Scheduler triggert um UTC 0:00 global daily digest und stale buffer flush.

Neues Produktgefühl: morgens hat der Agent schon „den Kontext von gestern“ — wie OS page cache, nicht Cold-Boot-Mount aus der Cloud.

agentmemory-Backend: Memory mit Cursor und Codex teilen

Wenn Sie agentmemory (npx -y @agentmemory/agentmemory) für Cursor oder Claude Code betreiben, setzen Sie memory.backend = "agentmemory" in config.toml. OpenHuman wird REST-Dünnschicht; Storage, embedding und Hybrid-Retrieval (BM25 + vector + graph) übernimmt agentmemory.

Typische Mapping (Doku):

• store → POST /agentmemory/remember
• recall → POST /agentmemory/smart-search
• Lifecycle: consolidation, retention scoring, auto-forget, graph extraction

Memory Trees chunking/sealing und trait backend sind orthogonal — agentmemory-Wechsel ändert Obsidian-wiki-ingest nicht, aber Agent-recall geht über die Shared Library. Migration: SQLite export → POST zu agentmemory → Config neu starten (kein Hot-Migrate).

Memory OS vs. Vektordatenbank vs. Chat-Kontext

Memory-Unterschied zu OpenClaw & Co.

OpenClaw (oft in diesem Blog) glänzt bei Multi-Channel-Routing, Daemon-Health, SSH-Tunnel vs. WSS. Memory meist Plugin oder externe DB, kein eingebauter Memory Tree. OpenHuman produktisiert Memory in Intelligence: Metriken, Entity-Graph, ingest-Heatmap, Obsidian-Einstieg.

Beide auf einem Cloud Mac: OpenHuman als persönliches Wissens-OS, OpenClaw für Telegram/Webhook-Orchestrierung — trennen Sie OPENHUMAN_WORKSPACE und OpenClaw-Config, isolieren Sie CPU/RAM-Peaks per launchd oder tmux (embedding und Gateway nicht überlappen).

OpenHuman auf Mac mini M4 Cloud Mac

Warum Cloud Mac für eine Desktop-App? Drei konkrete Profile:

• Windows/Linux-Hauptrechner: macOS für Tauri-OpenHuman + Ollama Metal embedding ohne Mac-Kauf — analog zu Remote-Xcode von Windows.
• 7×24 Auto-fetch: Laptop-Sleep bricht Sync; dedizierter M4 bleibt per SSH/VNC online, Memory Tree wächst kontinuierlich.
• Großes wiki: chunks.db + Obsidian + Modell-Caches — 1 TB/2 TB siehe M4-Speicher-FAQ.

Hardware: 16 GB vs. 24 GB und Ollama

Fast-score braucht keine GPU; Background embedding und Summaries schon. Mit Local AI (Ollama) auf M4 — wie bei MLX/Ollama-Experimenten: 16 GB für leichten Sync + kleines embed-Modell; 24 GB für parallele Worker, größere embed-Modelle plus IDE. Disk: ab 1 TB für AI + Memory OS.

Deployment in Kurzform

1. Vuncloud Mac mini M4 mieten, SSH, Workspace auf persistentem Volume.
2. OpenHuman release installieren, OAuth-Integrationen konfigurieren.
3. Ersten Run ingest manuell, wiki/ und Intelligence-Metriken prüfen.
4. (Optional) Ollama + Local AI für on-device embedding.
5. (Optional) agentmemory für geteiltes recall mit Cursor.

Mac kaufen oder Cloud Mac für Memory OS mieten?

Ist Memory Tree Ihr produktives Second Brain mit Arbeitsmail und Repos, lockt lokaler Mac mini mit Privacy und ohne Miete — bis Backup am zweiten Ort oder geteiltes read-only wiki nötig wird. Kurz testen: OpenHuman + agentmemory wöchentlich mieten; langfristig siehe lokal vs. Remote TCO. CI-Teams mit GitHub Actions macOS runner splitten Mietperioden oft parallel.

FAQ

Was ist Memory OS? OpenHumans Metapher für Memory Tree + Obsidian wiki + Auto-fetch — ingest, Storage, Index, Scheduler und Retrieval wie ein OS.

Wo liegen Daten? Standard ~/.openhuman/memory_tree/chunks.db und wiki/ — SQLite plus Markdown lokal.

agentmemory mit Cursor? Ja — memory.backend = "agentmemory" und lokaler REST-Service.

Unterschied zu RAG-Vektordatenbank? Source/Topic/Global-Bäume, Zeit-digest, editierbares wiki — nicht nur Similarity search.

Mac Pflicht? Desktop zielt auf macOS; 24/7 oft Cloud Mac.

Konflikt mit OpenClaw? Nicht zwingend — Verzeichnisse und Ressourcen trennen.

Beta stabil? Aktives Projekt, schnelle Iteration — chunks.db und wiki/ selbst sichern.

Fazit

OpenHumans Memory-OS-Linie verschiebt persönliche AI von „Chat + temp RAG“ zu local-first, auditierbarem Wissens-OS. Deterministischer ingest, drei Summary-Bäume und Obsidian-Dual-Write beantworten „warum erinnert sich der Agent?“ — nicht durch größeren Kontext, sondern durch strukturierte Memory-Schicht. Auf Apple Silicon: Ollama und agentmemory lokal, bei Bedarf Cloud Mac für dauerhaften Sync — ein praktikabler 2026-Pfad für personal AI Engineering.