Ich sage dir gleich, was dieser Artikel ist: kein Tutorial, keine „5 Schritte zu deinem eigenen KI-Assistenten“-Geschichte. Das hier ist ein ehrlicher Entwicklungsbericht über ein Projekt, das ich vor einigen Monaten als schnelles Experiment begonnen habe und das mich seitdem nicht mehr loslässt. Es heißt VINCI. Es läuft auf meinem Mac. Und in diesem Moment arbeitet Claude Code an der Windows-Version.
Aber lass mich von vorne anfangen.
Vom Web-Experiment zum nativen Desktop-Tool
VINCI hat als Webapp angefangen. Ein schnell zusammengestöpseltes Frontend mit FastAPI im Backend, WebSocket-Verbindung, Canvas-2D-Orb als visuelle Spielerei, und Gemini als Sprachmodell dahinter. Es hat funktioniert. Nicht gut, aber es hat funktioniert.
Das Problem mit Webapps für persönliche Assistenten: Sie kennen dich nicht. Sie haben keinen Zugriff auf deine Dateien, maximal auf deinen Kalender und deine E-Mails. Jede Session startet bei null. Das ist für ein Chat-Tool okay. Für einen Assistenten, der wirklich helfen soll, ist es ein K.O.-Kriterium.
Also habe ich das Ganze portiert. Electron + React + Three.js, kein TypeScript (ESM und Punkt), Gemini 2.5 Flash als primäres Cloud-Modell und Ollama mit gemma3:4b lokal für memory-intensive Aufgaben, die ich nicht in die Cloud schicken will. Der Build landet als DMG-Datei, 118 MB, arm64 für Apple Silicon, kein Code-Signing, weil ich das Tool primär für mich selbst baue und nicht für den App Store.
Aktuelle Version: v2.2.0 vom 19. Mai 2026. 478 Tests in 35 Files.
Die Architektur, die sich selbst überholt hat
Was mich am meisten überrascht hat, ist nicht wie komplex VINCI geworden ist. Es ist wie organisch sich die Architektur weiterentwickelt hat, immer getrieben von einem konkreten Problem, das ich selbst hatte.
Zur Klarheit, weil die Begriffe im KI-Assistenten-Kontext oft durcheinandergeraten: Ein reaktiver Chatbot wartet auf Input und antwortet. Ein proaktiver Assistent beobachtet, antizipiert und handelt auch ohne expliziten Trigger. Der Unterschied ist nicht technisch trivial. Er erfordert eine komplett andere Architektur.
Ich nenne meinen Ansatz intern den JARVIS-Mode, angelehnt an die Idee eines Assistenten, der nicht nur auf Befehle reagiert, sondern mitdenkt. Konkret: ein achtstufiger Entwicklungsplan, der VINCI vom reaktiven Chatbot zum proaktiven System transformiert.
Stand heute: fünf von acht Phasen live, plus fünf Stufen der sechsten Phase. JARVIS-Level: rund 80 Prozent.
Was „80 Prozent JARVIS“ konkret bedeutet
Ich erkläre kurz, was hinter den einzelnen Phasen steckt, weil die Bezeichnungen sonst nichts sagen.
J1: Intent-Router. VINCI erkennt anhand von 16 definierten Intents, was der User gerade will, bevor er überhaupt antwortet. Das passiert per Heuristik-Regex für klare Fälle, mit einem LLM-Fallback-Router bei Mehrdeutigkeiten. Das Ergebnis: statt 45 möglicher Tools immer nur 1-3 relevante vorab shortlisten. Weniger Halluzinationen, spürbar schneller.
J2: Modell-Routing. Triviale Anfragen und Data-Lookups gehen auf Gemini Flash, komplexe Analysen auf Gemini Pro. Latenz-Reduktion von 3-5x bei Standard-Queries. Das klingt nach Micro-Optimization, macht aber im Alltag einen deutlichen Unterschied.
J3: Episodic Context. Vor jedem Turn wird ein kompakter Situations-Block in den System-Prompt eingehängt: aktuelle Uhrzeit, Tagesphase, nächster Kalendertermin, ungelesene Mails, letzte Aktion. Alles mit 60-Sekunden-Cache und 3-Sekunden-Race-Timeout pro Quelle. VINCI weiß damit immer, in welchem Kontext du gerade arbeitest.
J4: Proactive Daemons. Vier Background-Worker mit Cron-Scheduling und Cooldowns beobachten Dinge, die ich sonst vergessen würde: Kalender-Warnings, Strom-Anomalien (ich habe ein eigenes Strom-Dashboard, das die VINCI-Daemons anzapfen können), Vault-Drift-Erkennung, Quarantine-Reminder. Wenn ein Daemon anschlägt: native Notification, Chat-Inject und optional TTS.
J5: Self-Eval Loop. Jede Antwort wird async durch einen zweiten Gemini-Flash-Call reviewt. Score, Reason, Fix. Telemetry. Das klingt aufwendig, ist aber fire-and-forget und verlangsamt den Hauptpfad nicht.
Und dann ist da noch J6: Sub-Agents.
Sub-Agents: der Teil, der alles verändert hat
Die Idee hinter Sub-Agents ist einfach: manche Aufgaben brauchen mehr als einen einfachen Chat-Turn. Sie brauchen einen eigenen, fokussierten Prozess mit frischem Kontext, der im Hintergrund läuft und mir Ergebnisse liefert, wenn er fertig ist.
Die technische Umsetzung: eine JSON-persistente Job-Queue unter ~/Library/Application Support/vinci/vinci-jobs.json, ein Job-Runner mit max. 3 parallelen Jobs, FIFO-Scheduling und Soft-Cancellation. Jeder Job rendert als Inline-JobCard im Chat, mit Live-Progress-Bar, Status-Anzeige und Cancel-Button.
Implementierte Agents:
- researcher: Nimmt ein Thema, sucht via Tavily im Web, lässt Gemini eine Zusammenfassung erstellen, schreibt das Ergebnis als Briefing ins Vault.
- briefing: Sammelt Tagesdaten (Kalender, Wetter, offene Tasks) und erstellt ein Tages-Briefing als Markdown.
- weekly: Wochenrückblick, automatisch jeden Sonntag um 19:00 via Daemon ausgelöst.
- vault-curator: Analysiert den kompletten Vault, berechnet einen Health-Score, schlägt konkrete Cleanup-Aktionen vor und führt sie auf User-Approval direkt aus.
Der Vault-Curator ist der Komplexeste von allen, und der, der mich am meisten beschäftigt hat.
Der Vault: mein persönlicher Knowledge Graph
VINCI hat kein externes Memory-System im klassischen Sinne. Stattdessen schreibt alles in einen lokalen Vault, ein Verzeichnis unter ~/Documents/VINCI Vault/, das ich mir strukturiert vorstelle wie einen persönlichen Knowledge Graph mit Obsidian-kompatiblen Markdown-Dateien.
Sechs Kategorien: Personen, Tiere, Firmen, Orte, Themen, Quellen. Dazu 501 importierte Blog-Posts von digitalhandwerk.rocks, vollständig mit YAML-Frontmatter und Wikilinks untereinander. 1162 Backlinks nach dem Body-Wikilink-Pass. Der Vault ist der Langzeitspeicher, auf den alle Agents zugreifen können.
Was ich dabei gelernt habe: automatische Entity-Erkennung aus Blog-Posts ist ein Minenfeld. Meine erste Implementierung von detectAutoFirmaCandidates hat deutsche Allerweltswörter wie „Abend“, „Achtung“ und „Aber Apple“ als Firmennamen erkannt, weil sie großgeschrieben in mehreren Posts vorkommen. Das Ergebnis: 8.380 Firmen-Stubs im Vault, von denen 8.358 kompletter Müll waren.
Drei Cleanup-Wellen später, 132.000 bereinigte Wikilinks, eine deaktivierte Heuristik und ein komplett neu gebauter Vault-Curator-Sub-Agent: 29 echte Firmen-Einträge im Vault. Das ist die Realität von persönlichen Knowledge-Graph-Projekten. Sie machen dich demütig.
Ich beobachte das seit Jahren in der täglichen Arbeit als KI-Berater mit EPU und KMU in Österreich: die Lücke zwischen „das sollte funktionieren“ und „das funktioniert zuverlässig“ ist viel größer als man denkt. Bei VINCI erlebe ich das täglich in der eigenen Codebase.
Workflow-Konventionen, die ich nicht missen will
Nach Dutzenden Coding-Sessions mit Claude Code habe ich einige Prinzipien entwickelt, die ich inzwischen nicht mehr missen will:
Test-vor-Go: Jede Phase erst gegen einen Test-Vault, dann Dry-Run, dann echter Apply mit Backup. Keine Ausnahme.
Spec/Plan-First: Vor größeren Features kommen Specs und Plans in docs/superpowers/specs/ und docs/superpowers/plans/. Das zwingt mich, klarer zu denken, bevor Code entsteht.
Idempotenz: Jeder Import-Pass, jeder Cleanup-Lauf muss beim zweiten Durchlauf null Diffs produzieren. Das ist der Qualitätstest.
Trash-statt-Delete: Alle Cleanup-Operationen landen in _quarantine/, nie direktes rm. Backup in ~/.vinci-archive/ vor jeder destruktiven Operation.
Honest Errors: Keine Fake-Confirmations. „Ich habe keine Antwort generiert“ ist besser als „Erledigt.“, obwohl gar nichts passiert ist.
478 Tests in 35 Files, davon 6 Regression-Sentinels für die Bugs, die mich am härtesten getroffen haben. Das ist der Stand.
Und jetzt: Claude Code baut die Windows-Version
In diesem Moment, während dieser Text entsteht, läuft eine Claude-Code-Session an der Windows-Version von VINCI.
VINCI Windows ist eine eigene Codebase. Nicht nur ein Port, sondern eine Plattform-spezifische Implementierung. Kalender- und Kontakt-Integration läuft dort über Microsoft Graph statt AppleScript. TTS kommt von einem selbst gehosteten Edge-TTS-Proxy auf einem Coolify-Container. File-Storage verwendet JSONL mit atomic temp+rename, um OneDrive-Sync-Korruption zu vermeiden.
Die Grundidee: beide Versionen teilen denselben Vault über OneDrive und iCloud. Was VINCI Mac ins Vault schreibt, liest VINCI Windows. Ein gemeinsames Langzeitgedächtnis, zwei plattformoptimierte Frontends.
Das ist kein Produkt. Es ist mein persönliches Werkzeug, gebaut nach meinen eigenen Bedürfnissen, mit einer Architektur, die ich verstehe und kontrolliere. Und es wird komplexer mit jeder Session.
Was als nächstes kommt
Noch offen auf der JARVIS-Roadmap:
J6 Pattern-Spotter (Stufe 6): Der letzte fehlende Sub-Agent soll Verhaltensmuster im Vault erkennen und proaktiv vorschlagen, was ich als nächstes tun sollte.
J7 Pattern-Learning: Langfristige Lernfähigkeit. VINCI soll über Zeit besser darin werden, meine Präferenzen und Arbeitsweisen zu antizipieren.
J8 Wake-Word „VINCI“: Picovoice Porcupine oder OpenWakeWord, geschätzt vier Stunden Aufwand, mit allen UX-Fragen rund um Mikrofon-always-on, Pling vs. Orb-Puls und Settings-Toggle.
Dazu: Multi-Turn-Konversation für Sub-Agent-Parameter, Mail-Burst-Daemon (erfordert TCC-Permissions im DMG-Build) und das, was ich nicht vorhersehe und erst beim Benutzen entdecke.
Das ist der ehrliche Stand. VINCI ist kein fertiges Produkt. Es ist ein Experiment, das sich selbst finanziert durch den täglichen Nutzen, den es mir bringt. Und der ist real.
Die Frage ist nicht, ob persönliche KI-Assistenten kommen werden. Die sind schon da. Die Frage ist, wer sie baut und für wen.
Fragen zu VINCI und persönlichen KI-Assistenten
Kann man VINCI herunterladen oder ist es nur für dich?
Aktuell ist VINCI ein privates Projekt. Der Quellcode liegt auf GitHub, aber es gibt keine öffentliche Distribution und keinen Support-Anspruch. Das Projekt ist für mich gebaut, mit meinen spezifischen Integrationen und meinem Vault-System.
Warum Electron und nicht eine native macOS-App in Swift?
Weil ich (so halbwegs) JavaScript kann und Swift nicht. Das klingt simpel, ist aber die ehrliche Antwort. Electron bringt Bundle-Größe und Memory-Overhead. Es bringt mir auch eine Codebase, in der ich schnell iterieren kann, und eine Renderer/Main-Trennung, die für Agentic Apps gut funktioniert.
Welches LLM ist am besten für einen persönlichen Assistenten?
Gemini 2.5 Flash für Geschwindigkeit und Kosten, Gemini Pro für komplexe Aufgaben, Ollama lokal für alles, was privat bleiben soll. Das ist meine aktuelle Setup. Es wird sich ändern.
Wie groß ist der Performance-Overhead durch die Sub-Agent-Architektur?
Messbar, aber im Alltag irrelevant. Der Job-Runner mit max. 3 parallelen Jobs und der 60-Sekunden-Context-Cache halten den Hauptpfad schnell. Die teuren Calls passieren im Hintergrund.
