1. Überblick
Ich habe LIA so entworfen, dass sie bei dir läuft, auf bescheidener Hardware. Die Referenzplattform ist ein Raspberry Pi 5 (ARM64), und alles Weitere folgt daraus: eine einzige Maschine, eine lokale PostgreSQL-Datenbank und ein lokales Redis, keine anderswo gehostete Datenbank. Zugangsdaten und Schlüssel der Anbieter werden verschlüsselt gespeichert.
Drei Prinzipien leiten den Rest. Zuerst Transparenz: Observability ist von Anfang an Teil der Architektur, und jedes verbrauchte Token wird mit seinen Kosten erfasst. Dann Defence in Depth: Quoten, Bestätigungen und Schutzmechanismen gegen Halluzinationen sind voneinander unabhängige Schichten. Und schließlich Unabhängigkeit von den Anbietern: Jede Rolle im System kann einem anderen Modell anvertraut werden, was mich vor einer Preiserhöhung ebenso schützt wie vor einem Ausfall.
Der Stack ist bewusst klassisch:
| Schicht | Wahl |
|---|---|
| Backend | Python 3.14, FastAPI, durchgehend asynchron |
| Orchestrierung der Agenten | LangGraph 1.x |
| Daten | PostgreSQL mit pgvector: Daten, Checkpoints des Graphen und Vektorsuche |
| Cache und Koordination | Redis: Cache, Sitzungen, Ratenbegrenzung, Leader-Wahl |
| Frontend | Next.js 16 (App Router), React 19, striktes TypeScript |
| Modelle | OpenAI, Anthropic, Google Gemini, DeepSeek, Perplexity, Qwen und jedes lokale Modell über Ollama |
| Logs | Strukturiertes JSON, personenbezogene Daten gefiltert |
Ein lokales Modell läuft ohne API-Kosten, vollständig bei dir. Die API läuft in mehreren Workern; eine Leader-Wahl in Redis reserviert die geplanten Aufgaben für einen einzigen von ihnen. Jedes optionale Subsystem wird über ein Flag aktiviert, und die Konfiguration folgt einer einzigen Kaskade: Was der Administrator in der Anwendung einstellt, hat Vorrang vor der Umgebung, die wiederum Vorrang vor den Konstanten im Code hat. Ich wollte eine einzige Kaskade, weil eine Konstante, die stillschweigend von der tatsächlichen Konfiguration abweicht, die am schwersten zu erkennenden Bugs erzeugt.
Ein geführtes Installationsprogramm stellt ein paar Fragen, legt das Administratorkonto an, ohne ein Geheimnis im Klartext zu schreiben, prüft, dass die Installation wirklich funktioniert, und kann sie später neu konfigurieren, ohne die Schlüssel erneut abzufragen (LIA installieren).
In Größenordnungen: mehr als 350 ADR, Hunderte Prometheus-Metriken, Zehntausende automatisierte Tests, eine Oberfläche in sechs Sprachen (Französisch, Englisch, Deutsch, Spanisch, Italienisch, Chinesisch).
Weiterlesen: allgemeine Architektur · Selbst-Hosting · Modellanbieter · administrierbare Fähigkeiten
2. Ein nach Domänen gegliedertes Backend
Das Backend folgt dem Domain-Driven Design. Jede fachliche Domäne (Agenten, Konnektoren, Stimme, Gedächtnis, Erinnerungen, Gespräche…) ist ein isolierter Kontext in src/domains/, nach demselben Muster gegliedert: Router, Service, Repository, Modell, Schema. Daneben trägt ein übergreifender Kern (core) die Konfiguration und die gemeinsamen Regeln, und eine gemeinsame Infrastrukturschicht bündelt, was alle brauchen: die Modell-Factory, den Cache, den MCP-Client, den Browser, die Ratenbegrenzung, den Aufgabenplaner, die Observability.
Für die externen Dienste habe ich eine hexagonale Architektur gewählt. Die Werkzeuge kennen nur Python-Protokolle (Ports), und die Clients für Google, Microsoft, Apple oder Philips Hue setzen sie um (Adapter). Einen Anbieter hinzuzufügen berührt also nicht den Code, der ihn aufruft.
Das Repository ist ein Monorepo: apps/api für das Backend, apps/web für die Oberfläche, infrastructure/ für Docker und das Monitoring, docs/ für die Dokumentation. Ein Administrator, der in der Oberfläche ein Modell ändert, sieht die Änderung sofort wirksam, ohne neues Deployment, weil die laufende Konfiguration in der Datenbank liegt.
Weiterlesen: einen Konnektor erstellen · einen Agenten erstellen · ein Werkzeug erstellen · einen Kanal hinzufügen · einen Modellanbieter hinzufügen · eine proaktive Aufgabe hinzufügen
3. Der Weg einer Nachricht
Ich habe LangGraph für die Orchestrierung der Agenten gewählt, weil es drei Dinge mitbrachte, die ich brauchte: einen als Checkpoints in PostgreSQL gespeicherten Zustand, Zyklen und interrupt(), mit dem sich ein Durchlauf anhalten lässt, um eine Bestätigung einzuholen, und dann genau dort fortsetzen lässt, wo er stehen geblieben war. Ohne diesen Mechanismus gibt es keine ernsthafte menschliche Bestätigung.
Jede Nachricht geht zuerst durch einen Router, der sie als einfaches Gespräch oder als Anfrage einordnet, die eine Aktion verlangt. Ein Gespräch geht direkt zur Antwort. Eine Aktion folgt dem Modus, der im Kopf des Chats gewählt ist.
Im Modus Pipeline, dem Standardmodus, schreibt der Planer vor jeder Ausführung einen ExecutionPlan: einen Plan in JSON, dessen Schritte über ihre Abhängigkeiten verbunden sind. Ein zweites Modell, getrennt vom Planer, validiert diesen Plan, damit kein Modell seine eigene Arbeit beurteilt. Der Orchestrator führt die Schritte dann in parallelen Wellen aus. Der Modus ReAct lässt das Modell dagegen ein Werkzeug aufrufen, das Ergebnis lesen und über das Weitere entscheiden, Schritt für Schritt.
Ich habe beide behalten, weil sie zwei Bedürfnisse erfüllen. Die Pipeline plant, parallelisiert, kontrolliert sich selbst und sieht ihre Kosten voraus: ein Aufruf für den Planer und einer für die Antwort, gegenüber einem Aufruf pro Iteration bei ReAct, also 4- bis 8-mal weniger Tokens. ReAct passt sich jedem Ergebnis an, was für eine explorative Recherche oder eine mehrdeutige Anfrage besser ist. Beide Modi teilen sich die Werkzeug-Registry, die Bestätigungen, den Antwortknoten und die Observability.
Die Wahl der Domänen und Werkzeuge läuft über einen semantischen Router mit Embeddings statt über Schlüsselwörter oder das Modell allein: Er ist günstiger und irrt sich seltener. Jedes Werkzeug deklariert ein Manifest (Parameter, Ausgaben, Kosten, Berechtigungen, Schlüsselwörter in mehreren Sprachen), das der Planer und der Router lesen, und jede Werkzeugfamilie wird ein einziges Mal in einer zentralen Registry deklariert. Smart Services senken den Verbrauch weiter, indem sie die Analyse der Anfragen cachen und wiederkehrende Pläne lernen. Nach einem Durchlauf mit Aktion schaut ein Initiativ-Knoten, nur lesend, was das Ergebnis anderswo bedeutet: Angekündigter Regen verweist auf die Aktivitäten im Freien in deinem Kalender. Jeder andere Durchlauf überspringt ihn und kostet nichts zusätzlich.
Ein paar Regeln halten das Ganze ehrlich. Eine Anfrage ohne Handlungsabsicht kann keinen Plan erzeugen, der irgendetwas ändert, und das ist eine deterministische Regel, geprüft vor jedem Modellaufruf. Ein Änderungsplan, der seine Korrekturversuche aufgebraucht hat, wird nicht ausgeführt: LIA stellt eine Frage, statt falsche Daten zu schreiben. Eine Ablehnung oder ein Fehlschlag wird nie als erledigte Aktion dargestellt, und sobald der Plan ausgeführt ist, wird nichts hinter deinem Rücken wiederholt: Die Antwort nennt jeden Fehlschlag, welches Werkzeug, warum, und die genaue Gesamtzahl. Für einen Modus, der sich unterwegs selbst korrigiert, gibt es ReAct.
Die Antwort kommt Token für Token per SSE. Die Generierung ist von der Verbindung entkoppelt: Ein losgelöster Producer veröffentlicht in einen eigenen Redis-Stream für den Durchlauf, und die Seite ist nur einer seiner Abonnenten. Den Tab zu schließen hält also nichts an, und die Antwort wartet auf dich.
Weiterlesen: die zwei Modi · die Wahl von LangGraph · der Graph im Detail · der Router · der Plan und seine parallele Ausführung · der Planer und die Massenoperationen · der semantische Router · die Werkzeug-Manifeste · ein Fehlschlag der Pipeline wird genannt, nie wiederholt · die Wiedergabe von Werkzeugfehlern · Durchläufe, die den Tab überleben · der ReAct-Modus
4. Mit Vorsicht handeln
Für MCP bestimmst du Bestätigungen auf Konto-, Server- und Werkzeugebene. Die Verhaltensübersicht erklärt die wirksame Regel vor einer Änderung. Ein eigener Agent fragt vor seiner Aufgabe, wenn eines seiner Werkzeuge Zustimmung braucht; die Antwort gilt für seine Aufrufe dieser Aufgabe. „Nie fragen“ wird bei geänderter Deklaration ausgesetzt. Der Chat darf den Schutz verstärken; nur die Einstellungen dürfen ihn lockern. Eine Routine kann die Server nutzen, die du in ihrem Formular ausdrücklich vorab genehmigt hast.
LIA fragt vor dem, was wirklich geschehen wird: vor jedem Entwurf (eine E-Mail, ein Termin, eine Löschung), vor jeder Massenoperation, die mindestens ein Element ändert, vor jedem Werkzeug, das deklariert, dass es eine Bestätigung braucht. Die Bestätigung wird Aktion für Aktion eingeholt, dort, wo die Aktion vorbereitet wird, und nicht für den ganzen Plan. Umgekehrt fragt eine Aktion, die nichts umlenken kann, nach nichts: Eine E-Mail, die du dir selbst schickst, geht direkt hinaus.
Was du bestätigst, ist genau der zuletzt angezeigte Inhalt, und jede Änderung wird nur einmal ausgeführt. Mehrere Entwürfe desselben Durchlaufs werden einzeln geprüft. Du kannst frei formuliert antworten: Ein Modell ordnet deine Antwort als Zustimmung, Ablehnung oder Änderungswunsch ein. Außerhalb des Gesprächs holt ein Ticket seine Bestätigung auf dem Ticket selbst ein, und eine Routine, die läuft, während niemand vor dem Bildschirm sitzt, stellt keine Frage: Sie lehnt die Aktion ab und sagt es, sonst würde deine nächste Nachricht als Antwort gelten. Ein Befehl an den Chat („zeig meine Antworten als Karten“) folgt derselben Regel, und verlangt er eine Kontoverbindung, einen Schlüssel oder die Auswahl einer Datei, geschieht dieser Schritt im authentifizierten Browser. LIA prüft das verlangte Ergebnis an dem, was sie beobachten kann, aber eine Delegation an ein Werkzeug beweist für sich allein nicht alle seine internen Wirkungen. Ebenso verhindert eine Sperre eine doppelte Ausführung, ohne garantieren zu können, dass ein externer Anbieter nur einmal handelt.
Auch die Antwort selbst hat einen Rahmen: Das Modell schreibt nur auf Grundlage der echten Ergebnisse der Werkzeuge. Und alles, was LIA tut, wird in drei getrennte Register eingetragen: die Aktionen, die Abfragen und die Durchläufe. Ihre Summen lassen sich nicht addieren, denn ein Durchlauf kann fünf Quellen abfragen, ohne etwas zu ändern. Eine Aktion wird eingetragen, bevor sie stattfindet, und erst mit einem ausdrücklichen Ergebnis abgeschlossen. Ein Gespräch zu löschen entfernt die Dateien, die du darin gesendet hast, nicht die, die LIA für dich erzeugt hat.
Weiterlesen: die Bestätigungen · die Autoritätskette und die Register · die Register aus Nutzersicht · die Tickets · die Anwendungsbefehle · was eine Delegation beweist · Werkzeugbeispiele, E-Mail an sich selbst und Entwürfe · die Synthese der Antwort
5. Gedächtnis und Kontext
Wenn du ein Ergebnis nach Absender, Titel oder Position benennst, verwendet LIA zunächst die tatsächlich gezeigten Einträge. Passen mehrere, fragt sie nach. Auch eine geplante Suche, die den ersten von mehreren Treffern bearbeiten würde, wartet auf deine Auswahl und arbeitet dann mit diesem Eintrag weiter.
Der Zustand eines Gesprächs ist ein MessagesState, den LangGraph nach jedem Knoten als Checkpoint in PostgreSQL speichert. Dadurch lässt sich ein Durchlauf nach einer Bestätigung fortsetzen, auch Stunden später. Die Ergebnisse der Werkzeuge liegen nicht im Nachrichtenverlauf, sondern in einer eigenen Daten-Registry, sodass sie erhalten bleiben, wenn der Verlauf gekürzt wird. Ab einer Schwelle werden ältere Austausche zusammengefasst; ein Badge zeigt, wie voll der Kontext ist, und /resume löst diese Zusammenfassung auf Wunsch aus. Im ReAct-Modus wird, was eine Schleife bereits gelesen hat, als Checkpoint gespeichert und im Durchlauf wiederverwendet; ein Abbruch vor diesem Checkpoint kann dazu führen, dass eine Quelle erneut gelesen wird.
Das Langzeitgedächtnis, die Wissensräume und der Kontext der Werkzeuge liegen in derselben Datenbank, mit pgvector. Nach jedem Austausch extrahiert eine Hintergrundaufgabe die Erinnerungen aus der letzten Nachricht; Erinnerungen, die der Frage nahekommen, kehren in den nächsten Kontext zurück, und das Gedächtnis ist auch ein Werkzeug, das der Planer und ReAct befragen. Eine dauerhafte Anweisung („antworte kürzer“) wird angeheftet und ist sichtbar. Wird ein sensibles Thema berührt, verbietet eine Direktive, zu scherzen oder etwas herunterzuspielen.
Um dieses Gedächtnis herum habe ich mehrere Schichten ergänzt. Die Tagebücher sind LIAs Aufzeichnungen in der Ich-Form; aus ihnen ergibt sich ein Porträt der Person, mit den Quellen, aus denen es gespeist wurde, und es lässt sich nur über indirekte Hebel korrigieren. Die Psyche Engine gibt LIA einen psychologischen Zustand, der sich mit jedem Austausch verändert und in ihrem Stil durchscheint, ohne angekündigt zu werden; sie lernt außerdem, Bereich für Bereich, wo LIA verlässlich ist, anhand von Belegen; das ist ein Pilotversuch, für den vorerst kein Gewinn behauptet wird. Sie hat eine eingestandene Grenze: Sie meldet fast nie eine ruhige, wenig intensive Emotion, und dieser Teil ihrer Aktivierung bleibt gesperrt. Die Interessen werden in deinen Anfragen erkannt und aus mehreren Quellen gespeist. Die Gewohnheiten schließlich werden ohne trainiertes Modell gelernt, über statistische Tests, und dafür hatte ich drei Gründe, jeder für sich ausreichend: Ein Raspberry Pi hat kein Trainingsbudget, eine Formel lässt sich der Person offenlegen, die sie betrifft, und bei so kleinen Datenmengen würde ein Modell vor allem das Rauschen lernen.
Weiterlesen: die Checkpoints · die Daten-Registry · die Kompaktierung · die gesicherten Lesevorgänge von ReAct · das Gedächtnis in PostgreSQL · das Langzeitgedächtnis · das Gedächtnis als Suchwerkzeug · die dauerhaften Regeln · die Tagebücher und das Porträt · die Psyche Engine · ihre gemessene Grenze · die Psyche aus Nutzersicht · die aus Belegen gelernte Wirksamkeit · die Interessen · die Gewohnheiten · die Suche in den Tagebüchern und den Registern
6. Die Modelle
Eine einzige Factory instanziiert das Modell jedes unterstützten Anbieters und wendet seinen Adapter an. Jede Rolle hat ihren eigenen Modellplatz (das Gespräch, die Planung, das Bild, die Transkription, die Sprachsynthese…), der in der Administration ohne neues Deployment eingestellt wird. Der Modellkatalog liegt in der Datenbank und deklariert Modell für Modell seine Fähigkeiten, die Parameter, die es akzeptiert, und die Denkstufen, die es kennt; der Konfigurationsbildschirm bietet so nur an, was die API des Modells wirklich akzeptiert.
Manche Aufgaben sind keine Generierungen, sondern begrenzte Entscheidungen: ein Format wählen, eine E-Mail einstufen. Sie können einer nativen Entscheidungs-Engine anvertraut werden, jede hinter ihrem eigenen Schalter und einem Hauptschalter. Eine unsichere Entscheidung fällt auf die übliche Verarbeitung zurück, und weder Rechte noch Bestätigungen werden an sie delegiert. Ein Einstufungsurteil authentifiziert keinen Absender, und ein auf einem Testkorpus gemessener Gewinn ist kein Versprechen für jede Anfrage.
Jeder Modellaufruf, in der Pipeline wie in den Hintergrundaufgaben, wird erfasst und anhand der Tarife in der Datenbank bewertet, dann pro Durchlauf zusammengefasst. Bei den Kosten kommt die größte Ersparnis aus dem Cache der Anbieter. Jeder Prompt stellt seinen stabilen Inhalt vor eine Markierung und den anfragespezifischen Inhalt dahinter, und die Infrastruktur übersetzt diese Markierung in den Cache-Mechanismus jedes Anbieters. Da jeder Modellplatz das Modell wechseln kann, stimme ich diesen Cache nicht auf ein bestimmtes Modell ab: Ich ziele auf den besten Durchschnitt, und ein Modell ohne Cache zahlt nichts mehr. Die Untersuchungen zu anderen lokalen Engines (oMLX, llama.cpp, LM Studio) sind Qualifizierungen, keine ausgelieferten Integrationen: Es zählen nur die Anbieter, die die Instanz anbietet.
Weiterlesen: die Modellauswahl · der Katalog in der Datenbank · der Konfigurationsbildschirm · die nativen Entscheidungen · ihre Integration · die Einstufung von E-Mails · ein Prompt-Layout für alle Caches · die Filterung des Werkzeugkatalogs · die untersuchten lokalen Engines
7. Konnektoren und Werkzeuge
Jede Konnektor-Kategorie (E-Mail, Kalender, Kontakte, Aufgaben, Dateien, Zuhause) ist ein Python-Protokoll. Pro Kategorie ist jeweils nur ein Anbieter aktiv, und die OAuth-Einwilligung wird einmal pro Google- oder Microsoft-Konto erteilt. Die Dienste, die von der Person nichts verlangen (Wikipedia, das Lesen von Seiten, die Orte, das Wetter), gehören der Instanz und sind für alle aktiv. Bei E-Mails wird jede Nachricht einmal zusammengefasst und dann wiederverwendet, ein Anhang wird als Text oder über ein Vision-Modell gelesen, und ein Versand wird nach einer verlorenen Empfangsbestätigung nie wiederholt.
Die Werkzeuge beruhen auf fünf kombinierbaren Schichten: einer gemeinsamen Konnektor-Basis (OAuth, Cache, Injection), einem Decorator, Formatierern pro Domäne, dem Manifest, das der Planer liest, und einem Katalog-Loader. Die MCP-Werkzeuge werden in gewöhnliche LangChain-Werkzeuge umgewandelt und kommen in denselben Katalog, der von einer Nachricht zur nächsten erhalten bleibt, damit eine Nachricht in der Regel auf keinen Server wartet; ein MCP-Server muss HTTPS verwenden, seine Zugangsdaten werden verschlüsselt, und LIA glaubt einer Annotation, die eine Änderung ankündigt, nie aber einer, die behauptet, nur zu lesen. Plugins im Format Agent Plugins werden als Ganzes installiert, ohne lokalen Server. Skills nach dem Standard agentskills.io können eine kleine App im Chat darstellen oder ihre eigenen Befehle in einer Kopie ihres Ordners ausführen; ein Skill von anderswo läuft isoliert und erhält nie das Token eines Konnektors.
Wenn ein Schritt eine echte Berechnung braucht, kann der ReAct-Modus ein kurzes Python-Skript schreiben und es in einem Wegwerf-Container ausführen. Dieses Skript erreicht das Web nur über einen einzigen Proxy, sieht den Schlüssel der Person nicht (der Proxy setzt ihn nur auf dem erlaubten Host ein), und bei einem unbekannten Host wird nachgefragt, mit drei möglichen Antworten. In beiden Modi laufen Berechnungen, Zeitspannen und Währungsumrechnungen über exakte Werkzeuge statt über das Modell. Ein Agent kann auch einen Browser steuern (Playwright) oder eine Seite in Text umwandeln.
Die Dokumente der Wissensräume werden zerlegt, vektorisiert und in PostgreSQL abgelegt statt in einer externen Vektordatenbank, dann über eine hybride, semantische und lexikalische Suche wiedergefunden. Ein Raum kann einem Ordner aus Google Drive oder OneDrive samt Unterordnern oder einem Gmail-Label folgen, ohne das ganze Postfach zu indexieren. Es gibt keine Zeichenerkennung: Ein gescanntes PDF wird in dieser Form nicht indexiert. Von außen gesendete Daten (SMS, Schrittzahl, Herzfrequenz, von einem iPhone, einem Android-Gerät oder jedem System, das JSON senden kann) kommen über Endpunkte herein, die mit einem eingeschränkten, widerrufbaren Token authentifiziert werden, getrennt von der Sitzung.
Für eine komplexe Aufgabe delegiert LIA an kurzlebige, rein lesende Sub-Agenten. Sie erzeugt auch Dateien: Dokumente, Bilder, Screenshots, die in einer Galerie abgelegt, behalten, per E-Mail verschickt oder, bei einem Bild, mit einer Person geteilt werden, die mit der Instanz verbunden ist.
Weiterlesen: Tools · interaktive Seiten · die Konnektor-Patterns · die gebündelte OAuth-Einwilligung · die Dienste der Instanz · die Konnektoren aus Nutzersicht · die E-Mails und ihre Zusammenfassungen · die Anhänge · die Zeitlimits pro Modellplatz · die Basis der Werkzeuge · MCP · der Standard Agent Plugins · die Plugins · die Skills · die Skills aus Nutzersicht · Skills von Dritten · einen Skill ändern · eine Fähigkeit teilen · das kurzlebige Python · der Netzwerkausgang der Sandbox · die berechneten Antworten · der Browser · das Lesen von Seiten · die Wissensräume · ihr Leitfaden · ihre Nutzung · ein Drive-Ordner ist ein Baum · ein Gmail-Label als Quelle · die eingebaute FAQ · ein Dokument aus einem Raum anhängen · die Sub-Agenten · die Gesundheitsdaten · ihre Aufnahme · die Gesundheit aus Nutzersicht · die SMS · die Dokumentenerstellung · die Dokumente aus Nutzersicht · die Bilder · die erzeugten Dateien · eine Datei behalten · per E-Mail senden · die Anhänge im Eingabefeld · die behaltenen Antworten
8. Stimme, Live-Modus und Telefon
Die klassische Stimme besteht aus unabhängigen Bausteinen. Das Aktivierungswort „Dis LIA“ wird im Browser erkannt, und nichts wird gesendet, bevor es gehört wurde; vorerst wird nur das französische Modell ausgeliefert, in der Beta. Das Diktat wird in der Sprache des Kontos transkribiert, auf dem Server und offline mit Whisper, oder je nach Einstellung von einer entfernten Engine. Die Sprachsynthese hat mehrere Anbieter, standardmäßig das kostenlose Edge, und die Antwort wird schon Satz für Satz vorgelesen, während der Rest noch geschrieben wird. Ein experimenteller sprechender Avatar kann hinzukommen, mit dem Simli-Schlüssel der Person, über den auch die Stille berechnet wird, solange die Verbindung offen bleibt.
Der Live-Modus ist ein echtes Gespräch von Stimme zu Stimme. Ich habe ihm zwei Intelligenzen und eine einzige Naht gegeben: Das Sprachmodell führt das Gespräch, und jede Anfrage nach Daten oder einer Aktion geht über eine einzige Funktion, send_to_lia, an die Chat-Engine. Die Anfrage wird zu einem gewöhnlichen Chat-Durchlauf, mit seinen Bestätigungen, seinen Registern und seinen Quoten. Die Stimme besitzt weder ein Werkzeug noch Zugangsdaten noch ein eigenes Gedächtnis.
Eine Live-Sitzung schläft ein, statt zu sterben: Im Ruhezustand ist die Verbindung zum Anbieter geschlossen, und nichts wird berechnet. Die Kosten beim Live-Anbieter laufen über den Schlüssel der Person und werden von LIA nie erfasst. In Live direkt liest die Stimme deine Daten selbst, ohne etwas zu ändern.
Das Telefon übernimmt dieselben zwei Modi. LIA kann nach einer Bestätigung für dich eine dritte Person anrufen oder dich selbst unter einer verifizierten Nummer erreichen, und dann hast du am Telefon deine Daten und alle ihre Funktionen, wie im Chat. Wenn LIA eine dritte Person anruft, hat der Anruf-Agent nur ein lesendes Frei/Belegt-Werkzeug: Der Schutz deines Kalenders ist strukturell, er hängt nicht von einer Anweisung in einem Prompt ab. Am Telefon gibt es den Live-Modus nur, wenn der Anbieter deine Instanz erreichen kann.
Eine Besprechung wird im Browser aufgenommen: Das Audio geht in kleinen Segmenten hinaus, wird dann transkribiert und zu einem strukturierten Protokoll zusammengefasst, das in einem Wissensraum abgelegt wird. Das persönliche Radio schließlich produziert nur während einer Hörsitzung und behält nichts zum erneuten Anhören.
Weiterlesen: die Stimme aus Nutzersicht · der Live-Ruhezustand und das Aktivierungswort · die Stimmen und die Synthese · der sprechende Avatar · der Live-Modus · die Telefonie aus Nutzersicht · das Telefon als Kanal · das Radio · die Besprechungen · das strukturierte Protokoll · die Protokollvorlagen
9. Die Initiative
LIA ergreift die Initiative in drei Formen. Ein periodischer Heartbeat schaut sich deine Quellen an und schreibt dir nur, wenn ein Signal es rechtfertigt, und nennt dabei ein oder zwei geprüfte Fakten. Mit einer Quelle verbunden zu sein und zu akzeptieren, von ihr unterbrochen zu werden, sind zwei getrennte Entscheidungen. Eine Push-Benachrichtigung von Google kann diesen Heartbeat für eine einzelne Person wecken, und ein Moment (das Ende einer Besprechung, das Eintreffen einer erwarteten Mail) wird auf die Minute bedient statt beim nächsten Durchgang. Die proaktiven Gespräche schließlich verlangen eine Antwort, mit ihren eigenen Regeln: Uhrzeiten, ein Höchstmaß pro Tag, sensible Themen, die privat bleiben, Ausgaben, die reserviert werden, bevor sie anfallen.
Routinen werden nach einem Zeitplan oder bei einer Bedingung ausgelöst, nicht bei beidem, und eine Wochenansicht zeigt, was wirklich passiert ist. Eine Erinnerung kann sich wiederholen. Das Ticket-Board gibt einer Aufgabe einen Lebenszyklus, einen Verantwortlichen und ein Ergebnis.
Zwei Regeln begrenzen das Ganze. Die Initiative liest nur: Ein Schreibvorgang wird vorgeschlagen, nie von selbst ausgeführt. Und ein erneuter Versuch derselben Ausführung wird abgelehnt, sobald das Wirkungsregister zeigt, dass die Aktion schon ausgeführt wurde. Die Seite Aktivität zeigt an einem Ort alles, was LIA allein unternommen hat, mit exakten Summen.
Weiterlesen: der Heartbeat · die Erlaubnis zu unterbrechen · das Wecken per Push · die Momente und die Beobachtungen · die proaktiven Gespräche · ihre Zustellung · ihr Kontext · ihr Budget · die Routinen · die Woche der Routinen · die Erinnerungen · eine Erinnerung, die immer einen Text hat · die Initiative, nur lesend · das Ticket-Board · die Seite Aktivität · eine Benachrichtigung bewerten
10. Sicherheit und Privatsphäre
Die Sicherheit ist in unabhängigen Schichten gedacht, und jede Angriffsart hat ihren eigenen Schutz. Konten melden sich über OAuth 2.1 an, und die Rechte folgen Rollen. Für die Sitzungen habe ich das BFF-Pattern gewählt: ein HTTP-only-Cookie und eine Sitzung in Redis statt eines JWT, der, läge er im Browser, XSS ausgesetzt wäre, schwer zu transportieren und nicht widerrufbar. Ein Konto lässt sich mit Passkeys und einem zweiten Faktor schützen, jedes verbundene Gerät lässt sich widerrufen, und das Verknüpfen einer Google-Identität ändert nie den Status eines Kontos. Die Nutzungsgrenzen gelten an allen Zugängen, Routinen inklusive.
Alles, was für die Person ausgeführt wird, wird als feindlich behandelt: Der Code der Skills läuft in einem Wegwerf-Container, eine vom Modell geschriebene Seite in einem Rahmen ohne Ursprung und ohne eigenen Host, und eine Aufgabe auf einem entfernten Server wird vorbereitet und dann bestätigt. Ebenso bleibt alles, was LIA liest, Daten und wird nicht zu einer Anweisung. Die Herkunft ist eine Eigenschaft der Daten: Jeder Inhaltstyp wird einmal eingestuft, ein unbekannter Typ wird als extern behandelt, und ein Typ, den niemand eingestuft hat, verhindert den Start der Anwendung.
Oberhalb der Debug-Stufe trägt eine Logzeile Fakten (Zahlen, Kennungen, Codes, den Host einer Adresse), weder das, was du geschrieben hast, noch das, was ein Modell über dich geschrieben hat. Zwei Vorbehalte: Die Fehlermeldung eines externen Dienstes in einem unbekannten Format kann noch ein Bruchstück davon zitieren, und die Debug-Stufe, die in Produktion abgeschaltet ist, behält mehr davon. Die Datenbank wird automatisch gesichert: Mit den Standardeinstellungen kann höchstens ein Tag an Daten verloren gehen. Die Kopie außer Haus und die Anhänge bleiben außerhalb dieser Sicherungen.
Zwei Grenzen solltest du kennen. Diese Maßnahmen belegen für sich allein nicht die DSGVO-Konformität eines Deployments. Und das Löschen von Rohmesswerten, etwa deiner Gesundheitsdaten, löscht nicht die daraus abgeleiteten Erinnerungen, die ihre eigenen Kontrollen haben.
Weiterlesen: die Sicherheit · die BFF-Authentifizierung · die Passkeys · die Geräte · die Nutzungsgrenzen · die Sandbox · die Herkunft der Inhalte · die Privatsphäre aus Nutzersicht · Logs ohne personenbezogene Daten · eine Logzeile trägt Fakten · die Sicherungen · die Herkunft einer Erinnerung
11. Beobachten und messen
Das Monitoring ist Teil des Deployments: Prometheus und Grafana für die Metriken, Loki für die Logs, Tempo für die Traces, Langfuse für die Modellaufrufe, Alertmanager für die Alarme. Der Code definiert Hunderte Metriken, rund dreißig Dashboards werden einsatzbereit mitgeliefert, und das Ausgeben der Metriken ist defensiv: Eine Metrik, die fehlschlägt, bringt keine Anfrage zu Fall.
Das Debugging habe ich auch in die Oberfläche gebracht, weil ein Agent schwer zu debuggen ist: Das Debug-Panel zeigt für jeden Austausch die Absicht, den Plan, jedes Werkzeug und jeden Modellaufruf, und man sieht, warum eine Anfrage teuer war oder warum diese oder jene Domäne gewählt wurde, ohne Grafana zu öffnen.
Bei den Kosten wird jeder Euro, den die Plattform für eine Person zahlt, für sie nachverfolgt, angezeigt, zugeordnet und gezählt, egal, wie er ausgegeben wurde. Neben den Quoten pro Konto gibt es eine Ausgabenobergrenze für die Instanz, weil mehrere Konten mal ihre Quote immer noch eine unbegrenzte Ausgabe sind. Ein Betreiber schaltet eine Fähigkeit ab, ohne neu zu deployen: Was das Deployment erlaubt und was der Betreiber wählt, wirken zusammen, und die kleinere der beiden Grenzen gilt.
LIA liest auch ihre eigene Telemetrie, um sich selbst zu diagnostizieren: Jeder kritische Alarm wird mit seiner Vorgehensweise per E-Mail verschickt und wird zu einem Vorfall, und ihre Empfehlungen bleiben Vorschläge. Ein Administrator kann sogar Claude Code CLI aus dem Chat heraus steuern, um seinen Server zu untersuchen.
Eine Klarstellung zur Performance: Die gemessenen Latenzen sind die der Infrastruktur. Die Antwortzeit, die du spürst, hängt vor allem von der Abfolge der Modellaufrufe ab, von ein paar Sekunden bis zu mehreren Dutzend, je nach Anfrage und Hardware. Und die Skalierung über eine einzige Maschine hinaus (mehrere Knoten, Replikate, Redis im Cluster) bleibt eine mögliche Weiterentwicklung, keine Realität. Zwei Fragen bleiben offen: das Wachstum des Speichers eines Workers über mehrere Tage und die Aufbewahrung der Checkpoints von LangGraph.
Weiterlesen: der Observability-Stack · das Debug-Panel · seine Architektur · die Obergrenze der Instanz · jede Ausgabe untersteht zwei Obergrenzen · die Verwaltung per Arbeitsmappe · die gezielten Ankündigungen · die Demo-Instanz · die Selbstdiagnose · die Alarme und ihre Belastbarkeit · Claude CLI aus dem Chat · die Anatomie eines Workers · die vollständigen Auszüge der Register · die Organisation der Hintergrundaufgaben
12. Die Oberflächen
Die Schaltfläche in der Mitte der Chat-Kopfzeile öffnet die Hauptunterhaltung und die benannten Unterhaltungen. Vergib beim Erstellen einen Titel. In der Liste kannst du eine weitere Unterhaltung öffnen, umbenennen oder löschen. Die Hauptunterhaltung empfängt automatische Nachrichten und lässt sich zurücksetzen. Die Sitzungsanzeige zeigt Tokens, Kosten und Kontext der gewählten Unterhaltung. Einstellungen, Gedächtnis und Journal gelten für das ganze Konto.
Der Bereich Werkzeuge besitzt eigene REST-Endpunkte außerhalb des Gesprächsgraphen. Er verwendet dieselben Connector-Clients und veröffentlicht deren Funktionen und Grenzen für die Oberfläche. Datenbanksitzungen schließen vor Anbieteraufrufen; Übermittlungen sind gegen Wiederholungen geschützt, verlorene Antworten erscheinen als unbekannter Ausgang. HTML-Mails bleiben in einem isolierten Rahmen, der entfernte Inhalte blockiert. So bleibt eine manuelle Handlung von einer an LIA delegierten Aktion getrennt; worum ein Klick LIA auf diesen Bildschirmen bittet, läuft durch eine eigene Tür: ein Aufruf und ein Vorschlag, nie ein Schreibvorgang beim Anbieter.
Die Weboberfläche ist eine Next.js-Anwendung, die sich wie eine App installieren lässt (PWA). Der Chat aktualisiert das Gespräch ohne Neuladen, stellt mathematische Formeln und farbig hervorgehobenen Code dar, behält einen Entwurf pro Konto und lässt sich durchsuchen; die Einstellungen haben ihre eigene Suche, ein tiefschwarzes Design für OLED-Bildschirme, das deinen Uhrzeiten folgen kann, drei Symbolstile und eine einstellbare Textgröße. Eine einzige Auswahlschicht bedient jeden Bildschirm: Markierter Text wird erklärt, übersetzt oder an das gewohnte Formular übergeben, nie an ein zweites, und ein Ersetzen behält das Rückgängigmachen des Browsers.
In der Anzeige als Karten, einem der drei wählbaren Modi neben einfachem HTML und Markdown, wird eine Antwort mit Daten nicht vom Modell formatiert: Der Server stellt sie als deterministische Karten in HTML dar, unabhängig von Modell und Modus, und archiviert sie mit der Nachricht. Eine Karte zeigt einen empfangenen Fakt vollständig und erfindet nichts, und eine Aktion von einer Karte aus bereitet eine Anfrage vor, statt zu handeln. Damit die Oberfläche stimmig bleibt, habe ich Regeln geschrieben, die Tests prüfen: Ein Status bezieht seinen Farbton aus einer einzigen Tabelle, eine Aktion hat eine Wichtigkeitsstufe, und eine Listenzeile zeigt ihre Aktionen auf eine einzige Weise. Die Browser- und Barrierefreiheitstests zielen auf Stufe WCAG AA, ohne die Darstellung auf einem physischen Gerät oder die Treue der Übersetzungen zu zertifizieren.
Die mobilen Apps sind native Hüllen, einmal pro Store veröffentlicht. Sie laden die Serveradresse, die beim ersten Start eingegeben wird, und duplizieren die Oberfläche nicht, weil eine einzige App allen dienen muss, die LIA hosten. Unter Android laufen die Benachrichtigungen über das Firebase-Projekt deines eigenen Servers; unter iOS, wo nur der Herausgeber einer App benachrichtigen kann, weckt ein minimales Relay das Telefon. Einen Text oder einen Link vom Telefon aus mit LIA zu teilen bereitet einen Chat-Entwurf vor, der nicht von selbst abgeschickt wird.
Rund um den Chat reagiert ein Begleiter mit ausdrucksstarken Augen auf den ganzen Ablauf einer Antwort, und jede Antwort trägt einen kleinen Stimmungs-Avatar. LIAs Welt ist eine weitere Oberfläche: ein gemeinsames Haus mit Garten, in dem man herumspaziert, ohne dass ein Raum zusätzliche Rechte gewährt. Sprachübertragung zwischen Personen und Föderation zwischen Instanzen sind dort nicht umgesetzt. Das Präsentationsvideo wiederum zeigt Nachbildungen der Oberfläche und Demodaten.
Zwei Personen derselben Instanz können ihre Assistenten verbinden, damit diese einander Nachrichten übermitteln, und die Seite Beziehungen bündelt, was jede Person betrifft, mit einem vom Modell verfassten Debriefing.
Weiterlesen: der Chat aus Nutzersicht · die Einstellungen · die Suche in den Einstellungen · die ersten Schritte · der Chat, der dem Server folgt · die Karten · ihre Darstellung · die Orte und die Wege · der bekannte Standort · die Primitive und ihr Vertrag · die Android-App · die nativen Benachrichtigungen · die Apps aus Nutzersicht · die ausdrucksstarken Augen · die nativen Begleiter · das Präsentationsvideo · die Fähigkeitenkarte · die Welt · ihr Prototyp · die Verbindungen zwischen Assistenten · die Beziehungen · das Debriefing einer Beziehung · Telegram
13. Wie dieser Code gepflegt wird
Jede Änderung durchläuft lokale Prüfungen (vor dem Commit, vor dem Push) und dann die Continuous Integration auf GitHub Actions, die genau dieselben Befehle aufruft wie ein Entwickler. Die Python-Abhängigkeiten sind Absichtsmanifeste, kompiliert zu universellen Lockfiles, die den Hash jedes Pakets tragen: Derselbe Commit installiert immer dieselben geprüften Versionen, auf jeder Architektur.
Die Regeln des Projekts hängen nicht vom Gedächtnis derer ab, die gegenlesen: Automatische Wächter halten sie. Mehrere von ihnen berechnen den Schutz aus der Quelle der Wahrheit neu (den Code selbst, die tatsächlich eingebundenen Routen, die Konnektor-Registry), statt eine von Hand geschriebene Liste festzuschreiben, und wurden absichtlich ausgehebelt, um zu prüfen, dass sie wirklich fehlschlagen. Anderswo können Referenzlisten nur schrumpfen, damit keine technische Schuld unbemerkt wächst. Die Prompts sind versionierte Textdateien, eine pro Prompt, gelesen von einem einzigen Loader. Mehr als 350 ADR halten die Entscheidungen, die verworfenen Alternativen und die akzeptierten Kompromisse fest, und Zehntausende Tests, die Continuous Integration und die strikte Typisierung erlauben es, das System ohne Regressionen weiterzuentwickeln.
Ein vollständiges technisches 360-Grad-Audit ist samt Protokoll im Repository veröffentlicht, damit jeder es wiederholen kann. Wie dieser Code geschrieben wurde, fast vollständig von einer gelenkten und kontrollierten KI, erzählt der Erfahrungsbericht.
Weiterlesen: die Continuous Integration · das Sperren der Abhängigkeiten · die versionierten Prompts · das öffentliche Audit
14. Weiterlesen
Dieser Leitfaden stützt sich auf den Code, auf mehr als 800 technische Dokumente und auf die ADR. Zum Weiterlesen:
- der Index der Dokumentation und der Index der ADR;
- die Architektur der Agenten und der LangGraph-Graph;
- die lebendigen Karten, die die Funktionen, die Technik und die Geschichte der Entscheidungen zeigen;
- die FAQ für die tägliche Nutzung und der Erfahrungsbericht für die Methode.
Der Code steht unter AGPL-3.0, auf GitHub.