Meine ersten KI-Skripte lösten einzelne Aufgaben: Berichte zusammenfassen, Logs untersuchen, TTPs extrahieren. Danach war der erzeugte Kontext weg. Zwischen den Prototypen fehlten gemeinsame Schnittstellen, Tests, Freigaben und ein Zustandsmodell.

Der Engpass war nicht mehr das einzelne Skript. Mir fehlte ein System, das Arbeitsschritte verbindet und ihren Zustand sichtbar hält.

Vom Prototyp zum gemeinsamen Arbeitsraum

2024 entstanden die ersten isolierten Versuche. Ab Herbst kamen zusammenhängendere Pipeline-Ideen hinzu. Der öffentlich dokumentierte Wechsel zu einem gemeinsamen Workspace mit Queues und Workern erfolgte im November und Dezember 2025. Diese Chronologie ist wichtig: Eine Architektur entsteht nicht in dem Moment, in dem man sie zeichnet. Sie entsteht, wenn mehrere Schritte denselben Zustand, dieselben Regeln und dieselbe Nachweisführung benutzen.

Ein neuer Bericht sollte auf vorhandene Quellen und frühere Entscheidungen zugreifen können. Gleichzeitig musste erkennbar bleiben, was Eingangsdaten, Modelloutput und menschliche Freigabe waren.

Eine Architektur, die sich verändert hat

Im Februar 2026 beschrieb ich das System in drei Ebenen: menschliche Steuerung, Synthese durch leistungsfähige Modelle und begrenzte Sammlung beziehungsweise Ausführung durch lokale Worker. Dieses Bild erklärt eine Entwicklungsphase, ist aber nicht mehr die aktuelle Laufzeitarchitektur.

Die menschliche Kontrollschicht blieb über alle Umbauten erhalten. Werte, Prioritäten und Risikoakzeptanz kann ich nicht an ein Modell delegieren. Veröffentlichung, Geld, Rechte, irreversible Aktionen und Entscheidungen über andere Menschen bleiben bei mir.

Für aufwendige Synthese nutzte ich zeitweise Cloud-Modelle über OpenRouters einheitliche API. Das verringerte den Wechselaufwand zwischen Modellanbietern, beseitigte Abhängigkeiten aber nicht; das Gateway wurde selbst zu einer Abhängigkeit. Private Daten gehören für mich nicht in diesen Pfad.

Lokale Worker waren für wiederkehrendes Screening vorgesehen und teilweise umgesetzt. Sie konnten die Offenlegung an externe Modellanbieter reduzieren. Zuverlässigkeit und Datenschutzkonformität folgten daraus nicht automatisch; beides musste je Workflow getestet und organisatorisch abgesichert werden.

Abrufbarer Kontext statt Gedächtnismetapher

Chroma war ein früher Versuch, Kontext über einzelne Läufe hinweg auffindbar zu machen. Chroma speichert und indexiert Embeddings, also numerische Repräsentationen von Text, und ermöglicht Ähnlichkeitssuche. Das kann relevante ältere Inhalte zu einer neuen Frage zurückholen.

„Gedächtnis“ war dafür eine griffige, aber ungenaue Metapher. Ein Vektorindex garantiert weder korrekte Segmentierung noch relevante Treffer. Ein möglicher Anwendungsfall wäre, einen neuen Phishing-Fall gegen sauber indexierte ältere Kampagnen abzufragen. Ob daraus ein belastbares Signal entsteht, muss ein Mensch am Quellmaterial prüfen.

Aletheia war ein Prototyp, keine Endstation

Im Februar 2026 baute ich Aletheia als lokale Browseroberfläche mit FastAPI-Backend. Sie zeigte Workerstatus, Queue-Inhalte und ausgewählte Health-Signale; einige Prozesse ließen sich darüber starten und stoppen. Oberfläche und Zustandsablage waren selbst betrieben, Modellzugriffe konnten trotzdem gehostete Anbieter nutzen.

Im Juli 2026 archivierte ich die eigenständige Anwendung. Aletheia ist heute eine Co-Pilot-Rolle in Hermes Agent. Der alte Prototyp war damit nicht gescheitert. Er hatte sichtbar gemacht, welche Funktionen ich wirklich brauchte und welche eigene Infrastruktur nur zusätzlichen Betrieb erzeugte.

Was die Dokumentation leistet

Das lyttek-ai-journey Repository ist eine Dokumentation und Fallstudie. Es ist kein unterstütztes Agenten-Framework, kein auditiertes Sicherheitsprodukt und keine Einsatzanleitung. Die datierten Kapitel zeigen auch verworfene Ansätze, Versionsprobleme und Architekturwechsel.

Ich habe den Weg veröffentlicht, weil offene Architekturberichte mein eigenes Lernen beschleunigt haben. Dazu gehörten unter anderem David Shapiros öffentlich dokumentierte Ideen. Eine glatte Erfolgsgeschichte wäre leichter zu erzählen, aber weniger nützlich.

Der belastbare Kern

Der aktuelle Stack kann vorbereitende oder ausdrücklich freigegebene Aktionen ausführen. Er ist keine autonome Produktionsplattform. Meine dauerhafte Architekturentscheidung liegt in der Trennung von Vorschlag, Ausführung und Verantwortung.

Der Weg vom Skript zum System bestand deshalb nicht darin, möglichst viele Komponenten zu verbinden. Er bestand darin, Zustand, Rechte und Abnahmen sichtbar zu machen — und später auch Komponenten wieder zu entfernen.

Quellen und Projektstand

Episode 4 untersucht, was passiert, wenn ein KI-System überzeugend klingt und der Nachweis dahinter fehlt.

Gregor Lyttek ist Security Architect & AI Strategist und Threat Hunter im Versicherungsumfeld.

→ lyttek.org · gregor@lyttek.org