Wenn KI-Agenten delegieren

Ein Mitarbeiter bittet einen KI-Assistenten, eine Lieferantenbewertung vorzubereiten. Der Assistent delegiert die Dokumentenrecherche an einen Agenten, die Vertragsanalyse an einen zweiten und die Prüfung der Ergebnisse an einen dritten.

Das kann eine sinnvolle Arbeitsteilung sein. Es erzeugt aber auch mehrere separate Entscheidungen über Zugriff und Informationsweitergabe. Jeder Agent erhält eine Aufgabe, etwas Kontext, einen Satz Werkzeuge und ein Ziel für seine Ergebnisse. Manche laufen lokal, andere über einen externen Modellanbieter. Ein Spezialist braucht möglicherweise Informationen, die der koordinierende Agent nie direkt sehen sollte.

Die Organisation muss entscheiden, welche dieser Interaktionen erlaubt sind - und diese Entscheidungen über den gesamten Prozess hinweg durchsetzen.

Das ist der nächste Schritt im Dissemination-Control-Blueprint. Version 0.7 erweitert die Architektur um Subagenten und macht ein weiteres Prinzip explizit: Der Blueprint ist ein erweiterbares Framework, das Betreiber an ihre eigenen Anforderungen anpassen können, einschließlich komplexer Kombinationen aus Werkzeugen, Richtlinien und Prüfungen.

In meinem früheren Artikel zur Governance-Lücke bei KI-Agenten habe ich den Unterschied beschrieben zwischen dem Zugriff auf Informationen und der Erlaubnis, sie in einem bestimmten Kontext weiterzugeben. Delegation fügt eine weitere Dimension hinzu: Ein Agent kann einen anderen Agenten bitten, in seinem Namen zu arbeiten.

Zugriff, Delegation und Rückgabe brauchen getrennte Berechtigungen

Nimm den Spezialisten für die Vertragsanalyse. Er braucht möglicherweise Zugriff auf vertrauliche Vertragsdokumente, um eine eng umrissene Frage zu beantworten. Jedem Agenten im Workflow denselben Zugriff zu geben, würde die Exposition unnötig ausweiten. Zu verlangen, dass jeder Spezialist weniger Zugriff hat als sein übergeordneter Agent, wäre wiederum zu restriktiv.

Der überarbeitete Blueprint unterscheidet deshalb drei Berechtigungen:

Zugriff: Welche Informationen darf ein Agent über seine Werkzeuge abrufen?
Delegation: Welche Spezialisten darf er beauftragen, und für welche Aufgaben?
Rückgabe: Welche Informationen darf der Spezialist zurücksenden, und an wen?

Ein Spezialist kann Zugriff haben, den sein übergeordneter Agent nicht besitzt. Der Betreiber muss diese Konstellation explizit genehmigen und den erlaubten Rückgabeumfang festlegen.

Der Standardpfad verwendet weiterhin die Berechtigungen des anfragenden Nutzers. Ein Mitarbeiter soll die Informationen erhalten, auf die er zugreifen darf. Erweiterte Fähigkeiten werden über dedizierte Werkzeuge bereitgestellt, deren zusätzliche Berechtigungen vom Betreiber genehmigt sind. Nutzer können diese Privilegien nicht selbst aktivieren.

Das macht die Ausnahme sichtbar. Der Betreiber entscheidet, welche zusätzlichen Informationsflüsse akzeptabel sind, und Dissemination Control setzt die konfigurierten Bedingungen durch.

Dasselbe Prinzip gilt für den Kontext, der an einen Subagenten übergeben wird. Daten, die für eine Aufgabe zugelassen wurden, dürfen innerhalb ihres genehmigten Verarbeitungsbereichs verwendet werden. Dieser Bereich muss die vorgesehenen Subagenten und Ausführungsumgebungen umfassen, zusammen mit allen Anhängen und dem gespeicherten Gesprächsverlauf, die sie erhalten.

Dieser Ansatz braucht kein weiteres Sprachmodell, das jeden Delegations-Prompt als vertraulich oder harmlos einstuft. Er stützt sich darauf, dass die präventiven Kontrollen die passenden Daten zulassen und die Umgebungen autorisieren, die sie verarbeiten dürfen.

Die Delegation selbst wird zu einer prüfbaren Ausführungsanweisung

Der Hauptagent kann eine Teilaufgabe über ein freigeschaltetes Werkzeug wie launchSubAgent formulieren. Die vertrauenswürdige Werkzeugimplementierung löst den Nutzer- und Aufgabenkontext auf, holt die Autorisierungsentscheidung ein und erstellt die Ausführungsnachricht.

Diese Nachricht bindet Prompt und Kontext an die erlaubten Modelle, Werkzeuge, Empfänger und Betriebsgrenzen. Das Werkzeug signiert die vollständige Payload. Vor der Ausführung prüft die empfangende Infrastruktur Herkunft, Integrität, vorgesehenen Empfänger, Gültigkeit und Autorisierung.

Das Modell kann Arbeit anfordern. Die maßgebliche Berechtigungskonfiguration bleibt außerhalb seiner Kontrolle.

Eine gültige Signatur allein macht eine Anweisung noch nicht zulässig. Sie belegt, wer die Nachricht ausgestellt hat und ob sich der geschützte Inhalt verändert hat. Ob die Ausführung erlaubt ist, bewertet weiterhin Dissemination Control.

Der Blueprint enthält eine beispielhafte JSON-Nachricht, um diese Verantwortlichkeiten konkret zu machen. Sie ist ein Ausgangspunkt für die Implementierung; Betreiber können das Schema erweitern und ihre eigene Messaging-Infrastruktur wählen.

Auch die Identität einer Nachricht spielt eine Rolle. Wenn der Transport dieselbe Anweisung zweimal zustellt, sollen nicht zwei Agenten starten. Erneute Übertragungen behalten denselben Identifier, und die empfangende Seite prüft ein gemeinsames Verarbeitungsprotokoll, bevor sie eine weitere Ausführung startet. Ein bewusster Korrekturversuch erhält einen neuen Nachrichten-Identifier und bleibt trotzdem mit der ursprünglichen Aufgabe verknüpft.

Auch bei der Ergebnisabgabe muss Governance wirksam bleiben

Wenn ein Subagent seine Arbeit abschließt, wird das Ergebnis nicht automatisch für alle Beteiligten verfügbar.

Das überarbeitete Design legt Ergebnisse in einem geschützten Arbeitsbereich ab. Ein Abgabewerkzeug kennzeichnet die Version, die geprüft werden soll. Der Ausführungsversuch kann dann enden, während die Validierung läuft.

Daraus folgen zwei Entscheidungen: ob die Arbeit die Anforderungen der Aufgabe erfüllt, und ob das Ergebnis an die vorgesehenen Empfänger freigegeben werden darf. Ein übergeordneter Agent kann helfen, die Qualität der Recherche zu bewerten. Seine Zustimmung kann keine zusätzlichen Zugriffsrechte gewähren.

Die Speicherberechtigungen müssen diese Unterscheidung unterstützen. Eine Freigabeprüfung hat wenig Wert, wenn der Nutzer die nicht freigegebene Datei ohnehin direkt öffnen kann.

Muss das Ergebnis korrigiert werden, kann der Subagent mit seinem bisherigen Kontext und einer Erklärung der Mängel neu starten. Dieselben Ausführungsbedingungen und Prüfungen gelten erneut. Zähler für Rückfragen und Ablehnungen bleiben auf Aufgabenebene erhalten. Ein Neustart löscht also nicht die Historie, die bestimmt, wann ein Mensch eingreifen muss.

Der Betreiber legt Schwellenwerte, Budgets und Eskalationspfade fest. Diese Werte gehören zum Deployment.

Der Audit-Trail verbindet diese Ereignisse: die ursprüngliche Anfrage, jede Delegation, die verwendeten Werkzeuge, Autorisierungsentscheidungen, abgegebene Versionen, Korrekturen und die schließliche Freigabe. Er muss außerdem erkennen lassen, welche Zugangsdaten für eine Operation verwendet wurden. Token-Referenzen oder Fingerprints liefern diese Zuordnung und halten wiederverwendbare Geheimnisse aus gewöhnlichen Audit-Einträgen heraus.

Für den Modellzugriff kann ein Gateway wie LiteLLM virtuelle Schlüssel und ein zentrales Kosten-Tracking bereitstellen. Agenten-Runtimes verwenden diese virtuellen Zugangsdaten, während die Provider-Schlüssel beim Gateway bleiben. Werden Modellanfragen mit Aufgaben und Ausführungsversuchen verknüpft, werden die Kosten von Delegation und Korrektur sichtbar.

LiteLLM ist eine mögliche Implementierung. NATS/JetStream ist ein mögliches Messaging-System. S3-kompatibler Speicher ist ein mögliches Ergebnis-Repository. Die Architektur verteilt Verantwortlichkeiten; die Produkte wählt der Betreiber.

Erweiterbarkeit ist jetzt ein explizites Designprinzip

Diese Unterscheidung ist zentral für die zweite Änderung in Version 0.7: Erweiterbarkeit ist jetzt ein explizites Designprinzip.

Eine Organisation braucht vielleicht zusätzliche Datenquellen, Spezialwerkzeuge, Genehmigungsschritte oder Prüfungen, bevor ein Ergebnis eine bestimmte Umgebung verlassen darf. Eine andere braucht unterschiedliche Richtlinien für Kunden, Abteilungen oder Projektrollen. Diese Anforderungen können Teil des Frameworks werden.

Erweiterungen lassen sich einführen, wenn die Anforderungen wachsen. Sie folgen denselben Prinzipien wie die ursprünglichen Kontrollen: Die maßgeblichen Regeln bleiben außerhalb des LLM, die Ausführung läuft über die relevanten Durchsetzungspunkte, und Entscheidungen bleiben nachvollziehbar.

Version 0.7 dokumentiert diese Architektur und ihren Ausführungsvertrag. Die deploymentspezifische Implementierung und Validierung bleiben Engineering-Arbeit.

Das praktische Ziel ist einfach: Wenn eine Aufgabe mehrere Agenten durchläuft, soll die Organisation weiterhin erklären können, wer jeden Schritt autorisiert hat, welche Informationen verfügbar waren, welche Ausnahmen galten und warum das Endergebnis seine Empfänger erreicht hat.

Der Dissemination-Control-Blueprint ist auf GitHub verfügbar. Er bietet eine Referenz, um diese Verantwortungskette in deine eigenen Agenten-Workflows einzubauen.