Entwickler und Projektleitung prüfen Systemzustände auf mehreren Bildschirmen

Technologie für den Betrieb

Technologie

Der Stack folgt dem System.

LatentDrift entwickelt KI-Architekturen für agentische Systeme mit direkter oder latenter Kommunikation, Daten- und Evidenzschichten sowie Echtzeit-Interaktion. Wir übertragen aktuelle Forschung in konkrete Entscheidungen darüber, wie Agenten zusammenarbeiten, welche Informationen gespeichert werden, wie Ergebnisse geprüft werden und wann eine menschliche Entscheidung erforderlich ist. Modelle, Frameworks und Infrastruktur wählen wir anhand der Zugriffs- und Nutzungsrechte, möglicher Fehlerpfade und der Anforderungen an den Betrieb. So lässt sich neue Technologie gezielt einsetzen, ohne das Gesamtsystem vom jeweiligen Stack abhängig zu machen.

Angebot ansehen Projektmuster ansehen

Agentenkoordination

Arbeitsgedächtnis für Agenten.

Bei komplexen Agentensystemen liegt der Engpass häufig in der Übergabe von Zuständen, nicht im einzelnen Modell. Entscheidend ist, welche Informationen ein Agent weitergeben darf, was nur während des Laufs benötigt wird und was für spätere Prüfungen erhalten bleiben muss. LatentDrift trennt diese Ebenen und legt fest, wie Recherche-, Planungs- und Prüfagenten Informationen austauschen.

Geteiltes Arbeitsgedächtnis

Agenten bearbeiten Aufgaben, Zwischenergebnisse und interne Zustände in getrennten Arbeitsbereichen. Schreib- und Leserechte bestimmen, welche Informationen geteilt werden. Widersprüchliche Zwischenstände werden vor der Weitergabe abgeglichen. So muss nicht jeder interne Schritt ausführlich in Text übersetzt werden, ohne dass ein gemeinsamer, unkontrollierter Speicher entsteht.

Beispiel: In einem Agenten-Cockpit sammelt ein Rechercheagent Fundstellen, während ein Planungsagent nächste Schritte vorbereitet. Ein Prüfagent filtert Widersprüche und zeigt den fachlich Verantwortlichen nur die relevanten Ergebnisse und offenen Fragen.

Direkte und latente Kommunikation

Direkte oder latente Kanäle können Latenz und Tokenverbrauch senken, etwa wenn Agenten Embeddings, Hidden States oder KV-Caches austauschen. Solche internen Repräsentationen lassen sich jedoch nicht ohne Weiteres zwischen Modellen übertragen und erhöhen das Risiko unbeabsichtigter Datenweitergabe. Deshalb werden Kanäle voneinander getrennt, Rechte begrenzt und Fallbacks definiert, die kritische Übergaben in eine lesbare Form überführen.

Tests zeigen, ob der direkte Kanal tatsächlich Vorteile bringt und an welchen Stellen eine lesbare Zusammenfassung oder Freigabe erforderlich ist.

Nachvollziehbarkeit unsichtbarer Zustände

Nicht direkt lesbare Zustände brauchen eigene Prüfpunkte. Laufhistorien, State-Diffs, Modellversionen sowie Token- und Latenzgrenzen zeigen, was sich zwischen zwei Schritten geändert hat. Statt jeden internen Zustand vollständig zu speichern, hält ein State-Diff nur die relevante Veränderung fest.

Laufprotokolle verbinden interne Übergaben mit kurzen Zusammenfassungen, Zustandsänderungen, Modellversionen, Kosten und dem jeweiligen Prüfstatus.

Laufzeit und Kontrolle

Agentensysteme brauchen klare Laufzeitregeln.

Ein Agentensystem braucht mehr als Rollen und gute Prompts. Die Laufzeitschicht regelt Aufgabenverteilung, Systemzugriffe, Budgets, Prüfungen, Wiederanläufe und menschliche Freigaben. Entscheidend ist, welcher Agent wann handeln darf und wie sich ein Lauf stoppen, prüfen oder wiederholen lässt. Diese Regeln liegen in einer versionierten Konfiguration und können unabhängig vom Prompt angepasst werden.

Rollen und Prioritäten

Rollen und Zuständigkeiten bestimmen, wer plant, ausführt und prüft. Prioritäten regeln, welche Aufgaben zuerst bearbeitet werden und wann ein Lauf warten oder an einen Menschen übergeben werden muss. Diese Regeln bleiben versioniert und können angepasst werden, ohne die gesamte Promptlogik neu zu schreiben.

Systemzugriffe und Budgets

Für jeden Agenten wird festgelegt, welche Werkzeuge und Daten er nutzen darf, welche Kosten- und Laufzeitgrenzen gelten und ob er nur lesen, Vorschläge erstellen oder Änderungen schreiben darf. Schreibzugriffe werden enger gefasst als Recherche- oder Planungsschritte. So bleiben technische Rechte und fachliche Verantwortung klar voneinander getrennt.

Beispiel: In einem Recherche- oder Supportprozess dürfen Agenten Informationen sammeln und Optionen vorbereiten. Änderungen in der bestehenden Anwendung werden erst nach einer Freigabe ausgeführt.

Prüfung, Abbruch und Wiederanlauf

Kritische Zwischenergebnisse werden geprüft, bevor der nächste Schritt ausgeführt wird. Definierte Rücksetzpunkte begrenzen Fehler. Aktionen, die sich nicht gefahrlos wiederholen lassen, werden blockiert oder zur Freigabe vorgelegt. Bei wiederholbaren Schritten darf ein erneuter Lauf weder doppelte Einträge noch andere unbeabsichtigte Folgen auslösen.

Damit ist festgelegt, wann ein Lauf weitergeht, zurückgesetzt oder an einen Menschen übergeben wird.

Modellrouting ohne feste Anbieterbindung

Routingregeln bestimmen, welches Modell für einen Lauf infrage kommt. Maßgeblich sind Zugriffs- und Nutzungsrechte, Kontext, Kosten, Latenz und die benötigte Ergebnisqualität. Je nach Aufgabe kann die Verarbeitung über eine API, ein lokal betriebenes Open-Weights-Modell, einen Batch-Lauf oder einen Stream erfolgen. Modell-, Prompt- und Tool-Versionen bleiben mit dem Ergebnis verknüpft, damit ein Wechsel geprüft werden kann und nicht unbemerkt im Hintergrund geschieht.

Nachvollziehbarkeit

Nachweise gehören ins System.

Nachvollziehbarkeit sollte Teil der Architektur sein, nicht eine Ergänzung am Ende. Die Evidenzschicht verbindet Ergebnisse mit Datenquellen, Modelllauf, Prüfstatus und Zugriffsrechten. So wird sichtbar, auf welcher Grundlage eine Ausgabe entstanden ist und welche Informationen für Nutzung, Freigabe oder Prüfung gebraucht werden. Im öffentlichen Sektor und in regulierten Branchen hilft diese Zuordnung, plausible Antworten von belastbaren Ergebnissen zu unterscheiden.

Datenherkunft und Evidenzgraph

Für relevante Ausgaben werden Anfrage, Datenstand, Fundstelle, Modellversion, Prompt- und Tool-Konfiguration, wichtige Zwischenzustände und Freigaben erfasst. Der Evidenzgraph verknüpft diese Informationen mit dem Ergebnis und bildet so dessen Herkunft – die Provenienz – ab. Das erleichtert fachliche Korrekturen, technische Prüfungen und spätere Modell- oder Datenwechsel.

Beispiel: Bei einer anspruchsvollen Dokumentenprüfung verweist jede Empfehlung auf Fundstelle, Datenstand, angewandte Regel, Modelllauf und Prüfstatus. Fachliche und technische Teams greifen je nach Aufgabe auf dieselben Belege zu.

Erklärungen nach Rolle

Endnutzer, fachlich Verantwortliche und technische Teams brauchen unterschiedliche Erklärungen. Deshalb wird pro Rolle festgelegt, welche Quellen, Unsicherheiten, Grenzen und Systemschritte sichtbar sein müssen. Die Oberfläche zeigt nicht möglichst viele Details, sondern die Informationen, die für die jeweilige Entscheidung oder Prüfung relevant sind.

Evaluation und Freigabe

Testfälle, Fehlerklassen und Freigaberegeln bestimmen, wie weit das System selbstständig handeln darf. Bei RAG-Systemen werden Suche, generierte Antwort, Quellenbezug, Sicherheit, Kosten und Latenz getrennt bewertet. Auch eine plausibel klingende Erklärung wird geprüft, weil sie den tatsächlichen Systemlauf falsch darstellen kann.

Die Auswertung zeigt, welche Fehler auftreten, ob Quellen die Ergebnisse tragen und für welche Fälle eine menschliche Freigabe nötig bleibt.

Echtzeit-Interaktion

Echtzeit mit klaren Zuständen.

Die entscheidende Logik synchroner Systeme liegt unter der Oberfläche: Streaming, Sprecherwechsel, Unterbrechungen, Latenzen, Kontext und Freigaben. LatentDrift bildet diese Abläufe als klar definierte Zustände ab: Hören, Warten, Nachfragen, Sprechen, Unterbrechen und Übergeben. Ein Avatar ist dabei nur eine mögliche Oberfläche. Dieselbe Logik kann auch ein Cockpit, einen Sprachdialog oder einen Prüfprozess steuern. Zustände, Latenzgrenzen und die Übergabe an einen Menschen werden unabhängig von der Oberfläche festgelegt und getestet.

Beispiel: Ein Trainings- oder Serviceinterface reagiert auf Sprache, Unterbrechungen und Wartezeiten. Bei Unsicherheit fragt das System nach. Je nach Anwendung erscheint die Ausgabe als Avatar, im Cockpit oder nur als Sprache. Bei Bedarf übernimmt ein Mensch.

Technische Bezugspunkte

Datenherkunft, Sicherheit und Barrierefreiheit.

Für Datenherkunft, Anwendungssicherheit und barrierefreie Oberflächen orientieren wir uns an etablierten Spezifikationen und Leitlinien. Welche Anforderungen daraus für ein Projekt folgen, hängt vom System und seinem Einsatzbereich ab.

Herkunft und Evidenz

W3C PROV beschreibt Modelle und Formate, mit denen Quellen, Datenstände, Verarbeitungsschritte und beteiligte Akteure als Provenienz verknüpft werden können.

W3C PROV OverviewExterne Quelle

Zugängliche Oberflächen

WCAG 2.2 bietet Kriterien für zugängliche Webinhalte. Für KI-Oberflächen sind sie besonders relevant, wenn Zustände, Freigaben, Unterbrechungen und Erklärungen wahrnehmbar und bedienbar gestaltet werden sollen.

W3C Web Content Accessibility Guidelines 2.2Externe Quelle
Passende Projektmuster