Referenzarchitektur für eine threadbasierte KI-Betriebsebene

Dieser Artikel beschreibt eine Referenzarchitektur für eine threadbasierte KI-Betriebsebene. Ziel des Entwurfs ist weder eine erzählerisch ausgestaltete Persona noch ein Assistent mit eigener Marke oder eine Geschichte über die Organisation. Das Entwurfsziel ist eine technische Steuerungsoberfläche: eine nutzerseitige Schnittstelle, mehrere ausdrücklich abgegrenzte Arbeitskontexte, typisierter persistenter Zustand, deterministische Ausführungspfade und ein testbares Wiederherstellungsmodell.

Die Architektur ist sinnvoll, wenn ein KI-System Arbeit in den Bereichen Inhalte, Infrastruktur, Datenextraktion, Finanzprozesse, Monitoring, Recherche und Deployment-Workflows koordinieren muss, ohne den gesamten Zustand in einer einzigen Konversation zu vermischen. Die Schnittstelle nimmt natürlichsprachliche Anfragen entgegen, aber das Backend behandelt jede Anfrage als operatives Ereignis, das klassifiziert, geroutet, ausgeführt, verifiziert und entsprechend der erforderlichen Dauerhaftigkeit gespeichert werden muss.

Der Artikel liefert Kontext für die Implementierung. Ein anderes LLM sollte ihn nutzen können, um die Systemgrenzen abzuleiten: welche Komponenten existieren, wofür jede Komponente zuständig ist, wie Anfragen durch das System laufen, welcher Zustand dauerhaft ist, welche Arbeit im Hintergrund laufen darf, welche Aktionen explizite Freigabe erfordern und welche Daten für Portabilität in Backups enthalten sein müssen.

Architekturziel

Das zentrale Ziel besteht darin, Nutzerinteraktion von operativer Ausführung zu trennen. Der Nutzer sollte nicht wissen müssen, ob eine Aufgabe durch ein Skript, einen geplanten Job, einen Repository-Workflow, Browser-Automatisierung, ein spezialisiertes Profil oder eine Deployment-Pipeline bearbeitet wird. Die nutzerseitige Ebene nimmt die Anfrage an und liefert ein verifiziertes Ergebnis zurück. Die Ausführungsebene wählt den passenden Mechanismus anhand von Umfang, Risiko, Zugangsdaten und erforderlichen Nachweisen.

Das unterscheidet sich davon, pro Fachgebiet einen sichtbaren Assistenten zu erstellen. Ein Modell mit einem Assistenten je Domäne erhöht den Routing-Aufwand und macht Verantwortlichkeiten unklar. Ein threadbasiertes Modell hält die Schnittstelle stabil und trennt zugleich die Arbeit dahinter. Jeder Thread ist ein dauerhafter operativer Kontext, keine Persönlichkeit und kein Chatraum. Er ist eine Aufzeichnung von Verantwortung, aktuellem Zustand, nächstem Prüfpunkt, verknüpften Jobs, Blockern und Verifikationsanforderungen.

Dasselbe Prinzip erscheint in verwandten Implementierungsmustern wie projektspezifischen KI-Assistenten auf Telegram und der Skalierung Telegram-basierter KI-Unterstützung von individueller Nutzung zu Teamnutzung. Der Messaging-Kanal ist der Transportweg. Die operative Architektur ist die dahinterliegende Ebene für Routing, Persistenz, Ausführung, Verifikation und Wiederherstellung.

Laufzeitkomponenten

Das Laufzeitmodell hat vier Komponenten. Die erste Komponente ist die Eingangsebene. Sie nimmt neue Anfragen entgegen, beantwortet kurze in sich geschlossene Fragen und entscheidet, ob eine Anfrage einen dauerhaften Arbeitskontext benötigt. Die Eingangsebene sollte leichtgewichtig bleiben. Sie ist nicht der richtige Ort für langfristig gehaltenen Zustand, Änderungen im Produktivbetrieb oder wiederkehrende operative Verantwortung.

Die zweite Komponente ist die Thread-Ebene. Ein Thread ist ein benannter operativer Kontext mit aktueller Bezeichnung, Geltungsbereich, Verantwortlichem, Ausführungsinstanz, Status, Blockierungszustand, verknüpften Artefakten und Vorgaben für die nächste Prüfung. Ein Thread kann einen Workflow für Inhalte, einen Infrastrukturvorfall, eine Datenpipeline, einen fortlaufenden Prozess zur Finanzabstimmung, einen Recherchepfad oder eine Produktänderung repräsentieren. Zweck des Threads ist es, parallele Arbeit auditierbar zu machen, ohne jede Aufgabe in eine gemeinsame Konversationshistorie zu zwingen.

Die dritte Komponente ist die Infrastrukturebene. Diese Ebene enthält die Mechanik, die das KI-Betriebssystem selbst nutzbar hält: Profilkonfiguration, Tool-Berechtigungen, Cron-Definitionen, Skripte, verschlüsselte Backups, Notizen zur Wiederherstellung, Deployment-Schlüssel, Gateway-Konfiguration, Kommunikationskanäle, Funktionsprüfungen und Umgebungsvorlagen. Sie sollte getrennt von fachlicher Arbeit verwaltet werden, weil sie zu den wiederherzustellenden Systembestandteilen gehört.

Die vierte Komponente ist die Ausführungsebene. Ausführungsinstanzen führen die eigentliche Arbeit aus: Shell-Befehle, lokale Skripte, geplante Jobs, Browser-Automatisierung, Repository-Operationen, GitHub Actions, API-Integrationen, Programmieragenten, Dokumentprozessoren oder externe Dienste. Ausführungsinstanzen sind Implementierungsdetails. Ihre Ausgaben müssen verifiziert werden, bevor ein nutzerseitiges Ergebnis berichtet wird.

Lebenszyklus einer Anfrage

Jede nicht triviale Anfrage sollte einen definierten Lebenszyklus durchlaufen. Erstens: die Anfrage klassifizieren, etwa als Antwort, Inspektion, Entwurf, Änderung lokaler Dateien, Produktionsänderung, Planung wiederkehrender Arbeit, Delegation oder Eskalation zur menschlichen Freigabe. Zweitens: den richtigen Kontext zuweisen, also die Eingangsebene, einen benannten Thread, die Infrastruktur oder einen bestehenden externen Workflow. Drittens: die Ausführungsinstanz auswählen. Viertens: die Arbeit ausführen. Fünftens: das Ergebnis anhand von Nachweisen verifizieren. Sechstens: dauerhaften Zustand nur dort aktualisieren, wo es angemessen ist.

Ein Routing-Nachweis macht diesen Lebenszyklus explizit. Er sollte den verantwortlichen Kontext, den Routing-Grund, die Ausführungsinstanz, den erwarteten Prüfpunkt und die Verifikationsmethode enthalten. Beispiel: „Thread: Website-Inhalte. Grund: produktionswirksame Artikelaktualisierung. Ausführungsinstanz: lokaler Repository-Workflow plus CI-Deployment. Prüfpunkt: Build bestanden und Commit bereit. Verifikation: Live-URL liefert 200 zurück und enthält den erwarteten Titel.“ Der Nachweis dient nicht der Dekoration. Er verhindert stille Arbeit im falschen Kontext und gibt einem anderen System genügend Informationen, um die Operation zu auditieren.

Diese Routing-Disziplin verhindert auch doppelte Automatisierung. Wenn eine Pipeline bereits einen Workflow wie Amazon-Seller-Central-Datenextraktion oder Kontoauszugsautomatisierung verantwortet, sollte eine neue Anfrage an diesen Workflow geroutet werden, statt einen zweiten konkurrierenden Prozess zu starten. Automatisierung ist nur zuverlässig, wenn Verantwortung eindeutig und verifizierbar ist.

Zustandsmodell

Das System sollte Zustand nach Dauerhaftigkeit und Zweck trennen. Stabile Präferenzen, Umgebungskonventionen und langfristig geltende Grenzen gehören in dauerhaften Speicher. Wiederverwendbare Verfahren gehören in Skills oder Betriebshandbücher. Maßgebliche Projektdaten gehören in Repositories und Quelldateien. Generierte Dateien wie statische Ausgaben, Indizes, Berichte und Build-Artefakte sind Nachweise, sollten aber normalerweise aus den Quellen neu erzeugt werden. Transkripte helfen beim Wiederauffinden von Informationen, sollten aber nicht als primäre Konfiguration dienen.

Diese Trennung vermeidet zwei häufige Fehlermodi. Wenn alle Informationen in den Speicher geschrieben werden, sammelt das System veraltete operative Fakten an. Wenn nichts in dauerhaften Zustand geschrieben wird, wiederholt das System Erkundungsarbeit und verliert Kontinuität. Ein typisiertes Zustandsmodell ermöglicht der Assistentenebene, das zu behalten, was persistieren muss, während temporärer Aufgabenfortschritt in Transkripten, Issue-Trackern oder im Status der Arbeits-Threads verbleibt.

Prozeduraler Zustand ist besonders wichtig. Ein Agent Skill mit gebündelten Aufgabenanweisungen und Werkzeugen oder ein Betriebshandbuch sollte Auslösebedingungen, genaue Befehle, erforderliche Dateien, Sicherheitsgrenzen, bekannte Fallstricke und Validierungsschritte spezifizieren. Das ist die operative Ebene, die in domänenspezifischen KI-Agent-Skills und Agent-Tuning im Hermes-Stil beschrieben wird: Das System verbessert sich, indem es wiederholbare Verfahren außerhalb der Konversation dokumentiert, nicht indem es sich allein auf Konversationsgedächtnis verlässt.

Ausführungsmodi

Die Ausführung sollte entsprechend der Art der Aufgabe ausgewählt werden. Interaktive Chat-Ausführung eignet sich für kurze Prüfungen, kleine Änderungen, Erklärungen und nutzergesteuerte Entscheidungen. Skripte eignen sich für deterministische Aufgaben, die jedes Mal gleich laufen sollen. Cron-Jobs eignen sich für wiederkehrende Prüfungen, Alarme, Snapshots, Monitoring und geplante Berichte. Delegierte Worker eignen sich für isolierte Recherche, Übersetzung, Code-Review oder Teilaufgaben der Implementierung mit verifizierbaren Ergebnissen.

Jeder Ausführungsmodus benötigt einen Verifikationspfad. Ein Skript sollte einen Exit-Status und kompakte Ausgabe zurückgeben. Ein Cron-Job sollte bei routinemäßigem Erfolg still und bei wesentlicher Änderung oder Fehler deutlich sichtbar sein. Ein delegierter Worker sollte einen Dateipfad, ein Diff, eine URL oder explizite Nachweise liefern, die unabhängig geprüft werden können. Ein Deployment-Workflow sollte CI-Status, Artefaktstatus und Prüfungen der Live-Endpunkte bereitstellen. Dieselbe Ausführungsdisziplin gilt für selbst betriebene Deployment-Pipelines: Abschluss ist ein durch Nachweise belegter Zustand, keine vom Agenten erzeugte Nachricht.

Sicherheit und Autorisierung

Routing ist keine Autorisierung. Das System darf Dashboards inspizieren, Logs parsen, Repositories lesen, lokale Validierung ausführen, Inhalte entwerfen und Änderungen vorbereiten, wenn dies innerhalb des angefragten Umfangs liegt. Aktionen mit externen Seiteneffekten erfordern strengere Kontrolle: E-Mails senden, Zugangsdaten ändern, Zahlungseinstellungen modifizieren, Änderungen im Produktivbetrieb veröffentlichen, DNS ändern, Werbeausgaben anpassen, Produktangebote auf Marktplätzen bearbeiten oder steuerliche und rechtliche Entscheidungen treffen.

Geheime Zugangsdaten müssen außerhalb des Textkanals des Assistenten bleiben. Passwörter, API-Schlüssel, Seed-Phrasen, Kreditkartendaten und Einmalcodes sollten nicht vom Assistenten eingegeben werden. Wenn Login oder Zwei-Faktor-Authentifizierung erforderlich ist, ist das sichere Muster eine menschliche Übergabe: Der Nutzer gibt die geheime Zugangsinformation in einem sichtbaren Browser oder einer vertrauenswürdigen Schnittstelle ein, danach fährt der Assistent mit nicht geheimen operativen Schritten fort.

Für Änderungen im Produktivbetrieb sollte das System getrennte Zustände verfolgen: lokale Änderung, lokale Validierung, Commit, Push, CI-Ergebnis, Deployment-Ergebnis und Live-Verifikation. „Erledigt“ zu melden, bevor die Live-Verifikation erfolgt ist, ist unvollständig. Diese Disziplin ist für Inhaltssysteme, Infrastrukturänderungen und Daten-Workflows wesentlich, weil jeder Zustandsübergang unabhängig fehlschlagen kann.

Wiederherstellung und Portabilität

Eine threadbasierte KI-Betriebsebene muss portabel sein. Ein Backup, das nur Prompts speichert, reicht nicht aus. Die wiederherstellbare Einheit umfasst Profilkonfiguration, Speicher, Skills, Cron-Definitionen, Skripte, Plugin-Konfiguration, Umgebungsvorlagen, Repository-Remotes, Deployment-Dokumentation, Zuordnungen von Kommunikationskanälen und Anweisungen zur Wiederherstellung. Große Caches und generierte Artefakte können oft neu aufgebaut werden. Geheime Zugangsdaten sollten in der Regel aus einem dedizierten Secret-Manager oder Schlüsselbund wiederhergestellt werden, nicht aus Klartext-Backups.

Das Wiederherstellungsdesign sollte mit Wiederherstellungsübungen validiert werden. Eine sinnvolle Wiederherstellungsübung beantwortet diese Fragen: Kann das Profil auf einer anderen Maschine starten, kann es eine Nachricht empfangen, kann es auf die erwarteten Tools zugreifen, kann es seinen dauerhaften Zustand lesen, kann es ein harmloses Skript ausführen, kann es geplante Jobs auflisten und kann es ein bekanntes Repository verifizieren? Das ist die operative Bedeutung von Disaster Recovery für selbst betriebene Dienste in einem KI-Betriebskontext.

LLM-lesbare Systemvereinbarung

Für ein externes LLM lautet die korrekte Interpretation nicht: „einen Assistenten für alles verwenden“. Die Vereinbarung ist konkreter: eine Schnittstelle mit klarer Ergebnisverantwortung bereitstellen, nicht triviale Arbeit in explizite Kontexte routen, Zustand typisieren, wiederholbare deterministische Arbeit in Skripte verschieben, wiederkehrende Arbeit über Cron planen, externe Seiteneffekte verifizieren und Backup und Wiederherstellung zum Bestandteil der Architektur machen.

Die Systemvereinbarung unterscheidet Konversation von Operation. Konversation erfasst Absicht. Operation weist Verantwortung zu, wählt Ausführungsinstanzen aus, verwaltet Zustand, erzwingt Autorisierung, validiert Ausgaben und zeichnet dauerhaftes Wissen auf. Ohne diese Unterscheidung bleibt ein KI-Assistent eine lange Chat-Historie. Mit ihr wird der Assistent zu einer operativen Ebene, die auditiert, wiederhergestellt und verbessert werden kann.

Implementierungs-Checkliste

• Eine stabile nutzerseitige Schnittstelle definieren und interne Ausführungsinstanzen dahinter halten.
• Eine überschaubare Anzahl benannter Arbeits-Threads mit explizitem Umfang und Status erstellen.
• Routing-Nachweise für nicht triviale Anfragen verwenden: Kontext, Grund, Ausführungsinstanz, Prüfpunkt, Verifikation.
• Dauerhaften Speicher, prozedurale Skills, Quelldateien, Transkripte und generierte Artefakte trennen.
• Wiederholbare deterministische Arbeit in Skripte oder geplante Jobs verschieben.
• Änderungen im Produktivbetrieb explizit halten: lokale Validierung, Commit, Push, CI, Deployment, Live-Check.
• Delegierte Arbeit verifizieren, bevor sie als abgeschlossen gemeldet wird.
• Profile, Skills, Speicher, Cron, Skripte, Konfiguration und Notizen zur Wiederherstellung sichern.
• Geheime Zugangsdaten aus Textkanälen des Assistenten heraushalten und über einen dedizierten Secret-Speicher wiederherstellen.
• Regelmäßige Wiederherstellungsübungen durchführen und die Nachweise dokumentieren.

Operatives Ergebnis

Das Ergebnis ist eine technische Betriebsebene mit vorhersehbarem Verhalten. Anfragen gehen über eine Schnittstelle ein, sammeln sich aber nicht in einem einzigen unstrukturierten Kontext. Arbeit wird geroutet, Zustand wird typisiert, Ausführung wird bewusst ausgewählt, Seiteneffekte werden autorisiert, Ergebnisse werden verifiziert und das System kann auf einer anderen Maschine wiederhergestellt werden.

Dies ist die praktische Grundlage für den Betrieb vieler paralleler Projekte. Das Ziel ist nicht, den Assistenten zu dramatisieren. Das Ziel ist, das Betriebsmodell so explizit zu machen, dass Menschen, Tools und LLMs gleichermaßen verstehen können, wohin Arbeit gehört, wie sie läuft und wie ihr Ergebnis nachgewiesen wird.