Geistr Core: Eine Desktop-First-Foundation für lokale KI-Apps
Ich habe vor Kurzem Geistr Core veröffentlicht — eine open-source, desktop-first Foundation für lokale KI-Anwendungen.
Für mich ist das keine klassische Produktankündigung. Es ist persönlicher. Geistr Core ist das Ergebnis von Monaten voller Bauen, Brechen, Testen, Umbauen und langsamem Herausziehen jener Systeme, die ich immer wieder gebraucht habe: Chat-Sessions, Memory, Tools, Permissions, MCP-Server, Skills, Background Loops, Provider-Handling, Attachments und all die kleinen Details, die aus einer KI-App mehr machen als nur ein Chatfenster mit API-Anschluss.
Das Projekt nutzt Pi als Teil des AI-Provider-Layers, und das öffentliche Repository liegt hier: github.com/Asm3r96/geistr-core.
Warum ich es gebaut habe
Die meisten KI-Produkte starten mit dem spannenden Teil: dem Modell, dem Interface, der magischen Demo.
Aber sehr schnell taucht die eigentliche Arbeit auf. Man braucht persistente Sessions. Man braucht ein Memory-System, das sich nicht wie eine Black Box anfühlt. Man braucht Tool-Permissions. Man braucht eine Möglichkeit, MCP-Server anzubinden, ohne die ganze App in ein Sicherheitsrisiko zu verwandeln. Man braucht User-Profile, Attachments, Model Selection, Background Tasks, Approvals, Logs und ein UI, das trotzdem ruhig bleibt, während all das passiert.
Ich bin immer wieder auf dasselbe Foundation-Problem gestoßen: Bevor ich die eigentliche Experience bauen konnte, musste ich dieselbe Agent-App-Infrastruktur neu bauen.
Geistr Core ist meine Antwort darauf.
Es ist die langweilige Grundlage, die ich mir selbst gewünscht hätte — und "langweilig" meine ich als Kompliment. Gute Infrastruktur sollte nicht ständig Aufmerksamkeit verlangen. Sie sollte die nächste Idee leichter machen.
Die Idee hinter Geistr
Geistr begann als local-first Desktop-KI-Workspace. Ich wollte eine Umgebung, in der ein Assistant wirklich mit mir arbeiten kann, während der Mensch trotzdem die Kontrolle behält.
Das bedeutet: Die App darf nicht einfach nur eine Chatbox sein, die an eine API angeschlossen ist. Sie braucht eine echte Runtime um das Modell herum:
- Sessions, die bestehen bleiben und wieder aufgenommen werden können.
- Memory, das nützlichen Kontext über Zeit speichert.
- Profile und Identität, damit der Assistant Kontinuität hat.
- Tools, die Dateien lesen, Dateien bearbeiten, suchen, fetchen und mit dem Workspace interagieren können.
- Permissions, damit Aktionen explizit und nachvollziehbar bleiben.
- MCP-Support, um externe Fähigkeiten anzubinden.
- Skills, damit wiederholbare Workflows als lesbare Anweisungen beschrieben werden können.
- Background Loops, damit freigegebene langlaufende Prozesse existieren können, ohne zu versteckter Magie zu werden.
Ein Modell allein ist keine App. Der Harness darum herum ist entscheidend.
Das passt auch zu meinem früheren Denken rund um Markdown Agent OS: Agenten werden nützlicher, wenn Workflows, Grenzen und State als Dateien und Text sichtbar bleiben, statt in undurchsichtiger Orchestrierung zu verschwinden.
Wie ich daran gearbeitet habe
Der Entwicklungsprozess war sehr praktisch. Ich habe mich nicht hingesetzt und zuerst das perfekte Framework entworfen. Ich habe Geistr gebaut, indem ich Geistr benutzt habe.
Jedes Feature kam aus Reibung.
Als Sessions schwer zu verwalten wurden, habe ich Sessions verbessert. Als Memory zu unklar wirkte, habe ich an Memory-Tools und Indexing gearbeitet. Als Tool-Zugriff zu mächtig wurde, habe ich Permission-Layer gebaut und Read-only-Grenzen getestet. Als sich Workflows wiederholten, wurden sie zu Skills. Als einzelne Aufgaben weiterlaufen mussten, kamen Background Loops dazu.
Das Muster war immer gleich:
- Die kleinste nützliche Version bauen.
- Sie in echter Arbeit verwenden.
- Finden, wo sie unsicher, langsam oder verwirrend wirkt.
- Das System enger ziehen.
- Die Regel dokumentieren, damit der nächste Lauf stabiler wird.
Ein großer Teil der Arbeit war nicht glamourös. Es war Typechecking, File-Size-Guards, Approval-Flows, lokale SQLite-Details, Provider-Abstraktionen und sicherzustellen, dass der Assistant nicht einfach nur behauptet, etwas sei passiert, obwohl das Tool selbst keinen Erfolg zurückgegeben hat.
Aber genau diese Schicht macht eine KI-App vertrauenswürdig.
Local-first als Produktphilosophie
Für mich ist local-first nicht nur eine technische Architektur. Es ist eine Beziehung zum Nutzer.
Wenn ein Assistant sich Dinge merken, Dateien anfassen, Tools ausführen und Teil des täglichen Workflows werden soll, dann sollte der Nutzer sehen können, was passiert. Daten sollten nah beim Menschen bleiben. Workflows sollten lesbar sein. Permissions sollten sichtbar sein. Das System sollte die Grenze zwischen Hilfe und Kontrolle respektieren.
Darum ist Geistr desktop-first. Der Desktop ist immer noch der Ort, an dem ernsthafte persönliche Arbeit passiert: Dateien, Projekte, Notizen, Code, Dokumente und Kontext leben dort.
Ein lokaler KI-Workspace sollte sich nicht so anfühlen, als würde man ein Gehirn in einem Browser-Tab mieten. Er sollte sich anfühlen wie die eigene Werkstatt.
Warum ich es jetzt open-source gestellt habe
Ich habe Geistr Core veröffentlicht, weil ich glaube, dass viele Builder auf dieselbe Wand stoßen.
Das KI-Ökosystem ist voll mit Model-Wrappern und Demo-Apps, aber die wiederverwendbare Grundlage für ernsthafte lokale Agent-Anwendungen ist noch jung. Nicht jeder Builder sollte Chat-Infrastruktur, Tool-Routing, Permission-Checks, MCP-Wiring, Memory-Handling und Provider-Auswahl wieder von vorne bauen müssen.
Geistr Core ist nicht die endgültige Antwort. Es ist eine funktionierende Grundlage.
Und es ist ein öffentlicher Ausdruck davon, wie ich glaube, dass KI-Apps gebaut werden sollten: human-in-the-loop, local-first, permission-aware, nachvollziehbar und an echter täglicher Nutzung orientiert — nicht nur an beeindruckenden Demos.
Was als Nächstes kommt
Die nächsten Schritte sind klar: die Desktop-App weiter verbessern, die Core-Systeme härten, die Developer Experience aufräumen und wiederkehrende Muster weiter in wiederverwendbare Bausteine verwandeln.
Besonders spannend sind für mich bessere Memory-Injection, klarere User-Profile, Voice Input, Token-Usage-Übersichten, Update-Flows und ein noch polierteres Session-Management.
Aber die größere Richtung steht bereits.
Geistr Core ist die Grundlage für die Art von KI-Workspace, die ich selbst verwenden möchte: ruhig, lokal, fähig, ehrlich und strukturiert genug, damit ein Assistant echte Arbeit leisten kann, ohne der Kontrolle des Nutzers zu entgleiten.
Das Repository findest du hier:
github.com/Asm3r96/geistr-core
Und falls du neugierig auf Pi bist, das Geistr Core im Provider-Layer nutzt: