OpenHuman —— Erst Daten syncen, dann handelt der Desktop-Agent

2026 wandelt sich der Desktop-Agent vom „Chat-Sidebar“ zum Kollegen, der wochenlang mitarbeitet. OpenHuman (Open Source von TinyHumans) setzt auf eine klare Schleife: erst Lebensdaten synchronisieren, dann handeln—Gmail, Kalender, GitHub, Notion, Slack und mehr anbinden, Lebensdaten lokal in einen Memory Tree aus lesbarem, editierbarem, löschbarem Markdown pressen, dann Desktop-Agenten suchen, schreiben und Tools ausführen lassen. Gegenüber „jedes Mal neuer ChatGPT-Tab“ wirkt es eher wie jemand, der noch weiß, womit du letzte Woche kämpftest. Im Folgenden: Architektur, Abgrenzung zu OpenClaw und wo 24/7-Last hingehört.

Vom zustandslosen Chat zum Digitalzwilling

Die meisten LLMs „vergessen“, wenn ein Thread endet—ein paar Zeilen im System-Prompt sind Post-its. OpenHuman geht anders: erst Lebensdaten synchronisieren, dann handeln. Der dokumentierte Pfad (siehe OpenHuman-Dokumentation): UI-Installation → OAuth-Konten → auto-fetch etwa alle zwanzig Minuten → Schreiben in den Memory Tree → Spiegelung als Obsidian-kompatibler Markdown-Vault, den du direkt bearbeitest oder kürzt.

Persönlicher KI-Digitalzwilling heißt hier: Daten auf deiner Platte, menschenlesbar—keine undurchsichtigen Vendor-Threads in fremder Cloud. Das Projekt ist Beta, desktop-zentriert, Onboarding ohne Terminal versprochen; Integrationsliste im GitHub-Repository als Referenz.

Anders als geschlossene „Super-Apps“ erlaubt GPL-3.0 Forks mit geänderter Sync-Politik, anderem Speicherort oder rein lokalen Modellen—für Teams, die Vendor-Lock hassen, aber Nicht-Entwickler per UI verbinden lassen wollen. GitHub- und Product-Hunt-Traktion zeigt echte „Second-Brain“-Nachfrage; das ersetzt nicht Enterprise-SLA oder abgeschlossene Compliance—Pilot mit realistischen Erwartungen.

Wer bereits Obsidian, Logseq oder Meeting-Notizen pflegt, sollte OpenHuman nicht als „neue Notes-App“ verkaufen, sondern als „Agent arbeitet auf dem Vault, den wir ohnehin besitzen“. Das hilft in Beschaffungsgesprächen: Artefakt sind Dateien auf eurer Platte, kein Miet-Chatverlauf.

Memory Tree: Wissensbasis wächst auf der Festplatte

Die Community nennt OpenHuman oft „Agent mit Obsidian-Gehirn“—nah an Karpathys LLM Knowledgebase: Fragmente in durchsuchbaren, reviewbaren Text statt endloser Chat-Logs.

• SQLite als kanonischer Speicher; Markdown-Chunks speisen Baum-Summaries, damit nie der ganze Vault im Kontext landet;
• Ordner in Obsidian korrekturlesen, taggen, sensible Passagen löschen;
• Zusätzlich memory / web-fetch / coder (Git, Lint, Tests) und Multi-Model-Routing; optional Ollama lokal.

Für Entwickler werden Issue-Threads, PR-Texte und Design-Doc-Schnipsel langfristiger Hintergrund—ohne jedes Mal dieselbe README einzukleben. Chunking und Summary-Bäume begrenzen Kontextlänge: „mehr erinnern“ heißt nicht automatisch „jeden Turn das volle Fenster verbrennen“.

Ein typischer Tag: morgens auto-fetch für Mail und Slack; nachmittags Coder-Tools mit Architektur-Notizen im Vault; abends Spracheingabe für morgige Prioritäten in Summaries. Vault in Obsidian öffnen—du siehst, was der Agent glaubt, dass du weißt; das ist der Kernunterschied zu Black-Box-Chat.

Technische Teams profitieren besonders, wenn Issue-Diskussionen und PR-Beschreibungen automatisch in den Kontext rutschen, während Marketing oder Ops dieselbe Oberfläche für Kalender und Kundenmail nutzen—ohne getrennte „Enterprise Search“-Lizenz. Der Preis ist Pflege: wer nie löscht, baut genauso Müll an wie in einem unbegrenzten Chat-Verlauf, nur lesbarer.

Anbindung und Sync: Cold Start verkürzen

Die Docs nennen viele Integrationen (Gmail, GitHub, Slack, Notion, Linear, Drive, Stripe …) mit typisierten Tools nach OAuth; periodische Pulls sollen nach einem Sync Posteingang, Kalender und Repos „gesehen“ haben—statt zwei Wochen Copy-Paste. Neben Text: Sprache (STT/TTS) und Multi-Agent-Koordination—leichte Tasks auf schnellen Modellen, schwere Reasoning nur bei Bedarf.

Unternehmen müssen DLP und „darf die volle Mail auf die Platte“ klären; Privatnutzer: minimale OAuth-Scopes, Festplattenverschlüsselung—local-first ist nicht risikofrei. Verbietet die Policy ungenehmigte lokale KI auf Arbeitsdaten, erst Security-Review, dann Firmenkonten—das liegt auf App- und Kontoebene, nicht bei der Laptop-OS-Marke.

Bewährtes Rollout: Woche 1 nur Kalender oder öffentliches GitHub; Woche 2 Mail nach Legal-Freigabe; Woche 3 Coder-Tools auf Repo-Spiegel, nicht Produktions-Deploy-Keys. Wer die Reihenfolge überspringt, produziert schnell Schlagzeilen zu „versehentlichem Export“ statt zu Produktivitätsgewinn.

Gegen OpenClaw: erinnern vs. handeln

Kurz gesagt: OpenClaw lässt den Agenten „handeln“, OpenHuman lässt ihn „wissen, wer du bist“. Kombinierbar—VPS-Bot nur nach außen, Planung und Langzeitgedächtnis im lokalen Vault, weniger Drang, das ganze Privatpostfach auf einen öffentlichen Server zu legen. Läuft Gateway auf dem VPS, HTTPS und GitHub Actions vs. manuelles Docker beim OpenClaw Gateway wie in Produktion behandeln.

In Hybrid-Setups lohnt sich ein einfaches Datenfluss-Diagramm für das Security-Board: Pfeil „öffentlich“ nur zum VPS-Gateway; Pfeil „persönlich“ bleibt auf dem Laptop-Vault. So vermeidet ihr die Diskussion, ob OpenHuman „noch ein Chatbot in der Cloud“ ist—es ist explizit lokale Speicherung mit optionaler Cloud-Inferenz, nicht umgekehrt.

Datenschutz und Betriebsgrenzen

GNU GPL-3.0 erlaubt Fork und Audit; bei Cloud-LLMs wandern aus dem Memory Tree gezogene Snippets trotzdem über Grenzen—Modell-Region zur Vertragslage wählen. OAuth-Tokens sind Schlüssel: bei Geräteverlust oder Offboarding revoke und Vault prüfen. Docs erwähnen Browser-/Rechnersteuerung—mehr Rechte vergrößern Fehlbedienung und Over-Fetch; in produktionsnahen Umgebungen Test-Anbindungen mit niedrigen Rechten.

Kein 24/7-Slack-Bot auf dem zugeklappten Notebook erwarten: Sleep, WLAN-Aussetzer und Updates unterbrechen Desktop-Agenten; externe Webhooks gehören auf VPS oder Container. In der Beta: Testkonto „verbinden → einen Fetch-Zyklus warten → Vault öffnen und maskieren“, dann Hauptpostfach; in Obsidian veraltete oder sensible Blöcke regelmäßig von Hand löschen.

Bei Cloud-LLM-Aufrufen gelten aus dem Memory Tree gezogene Snippets wie jedes andere PII: Herkunfts-Integration dokumentieren, Subprozessoren listen, DSGVO oder Branchenregeln beachten, wenn EU- oder Gesundheitsdaten in Mails stecken. Ein Fork ändert nicht eure Pflicht zu steuern, was die Maschine verlässt—nur eure Einsicht, wie es passiert.

Selbstcheck vor Go-Live (8 Punkte)

Für Tech-Leads oder Power-User—mehr Treffer = Pilotplatz gerechtfertigt; kein Scoring-RFP.

• Genug vom Projekt-Kontext bei jedem Chat von Null?
• Bereit, Gedächtnis zu kuratieren statt alles dem Modell zu überlassen?
• Liegen Tageswerkzeuge in der Integrationsliste oder per Plugin?
• Erlaubt Compliance Mail/Code-Metadaten auf dem Privat-PC?
• Braucht ihr weiter iOS-Builds/macOS-Signing?—Mac separat planen, parallel zum Zwilling.
• Slack/Webhooks vom Desktop-Zwilling trennen?—OpenClaw in die Cloud, OpenHuman lokal ist klarer.
• Beta-Churn und gelegentlich kaputte Integrationen akzeptabel?
• Enthält Gerätewechsel/Offboarding Export oder Vernichtung des lokalen Vaults?

Oftes Fazit: OpenHuman zuerst für persönliche Produktivität, externe Bots und iOS-Lieferung über VPS oder mac in the cloud—drei Linien nicht in eine Beschaffungsnotiz packen.

Wenn vier oder mehr Punkte der Checkliste zutreffen, reserviert einen Sechswochen-Pilot mit klarem Exit: Vault exportieren, Tokens widerrufen, dokumentieren was in Slack/CI weiter über OpenClaw laufen soll. Ohne Exit-Kriterien verwechselt Management „Beta-Tool“ mit „ersetzt unsere Wissensdatenbank“—und das endet in verfrühten Ausschreibungen.