Human-in-the-Loop: Approval-Gates für KI-Agenten

Vollautomation klingt nach dem Ziel, ist aber selten eins. Bei jedem Agenten-System, das ich gebaut habe, kam früher oder später dieselbe Frage: an welchen Stellen darf das System eigenständig handeln, und wo muss ein Mensch zustimmen, bevor etwas passiert? Das ist die Approval-Frage, und sie ist eine der zentralen Architektur-Entscheidungen beim Bau produktiver Coding-Agenten.

Die Asymmetrie zwischen Lesen und Schreiben

Lesende Operationen sind billig: ein Agent liest eine Datei, ruft eine API ab, durchsucht Logs. Wenn er falsch läuft, kostet das Tokens und etwas Zeit. Schreibende Operationen sind teuer: eine gelöschte Datei ist weg, ein commit-pushed ist öffentlich, eine versendete Nachricht lässt sich nicht zurückholen. Dieser Asymmetrie folgt die einfachste Approval-Heuristik: lesend autonom, schreibend mit Approval.

Aber die Heuristik bricht, sobald die Realität komplexer wird. Eine Datenbank-Query "nur lesend" kann das System lahmlegen, wenn sie versehentlich SELECT * über Milliarden Zeilen macht. Eine "schreibende" Operation wie das Anlegen einer Wegwerf-Branch ist trivial reversibel. Die Heuristik braucht Verfeinerung — und genau dort kollabiert die meisten Agenten-Implementierungen.

Vier Stufen statt zwei

Im DCO (Dynamic Central Orchestrator), den ich seit März 2026 produktiv betreibe, habe ich vier Approval-Stufen statt der binären Aufteilung:

Autonom — der Agent führt aus, ohne zu fragen. Lesende Operationen mit klar definierten Limits, idempotente Schreibvorgänge in einem Sandbox-Scope.
Notify — der Agent führt aus, schickt aber eine Telegram-Nachricht. Ich kann nachträglich revidieren, aber muss nicht warten. Gut für Aktionen mit hoher Vertrauenslage und geringem Schaden.
Confirm — der Agent stoppt, schickt einen Vorschlag, wartet auf "ja" oder "nein". Standard für schreibende Operationen ausserhalb der Sandbox: git push, Slack-Nachricht, Datei löschen.
Veto — der Agent darf das nicht. Punkt. Hartcodiert in der Tool-Auswahl. Beispiel: rm -rf überhaupt nicht aufrufbar, auch nicht mit Approval.

Diese Stufen sind kein theoretisches Modell, sondern direkt in den MCP-Tools des DCO codiert (MCP: die Schnittstelle, über die Agenten Werkzeuge ansprechen). Jedes Tool deklariert seine Approval-Stufe, und der Orchestrator-Layer entscheidet basierend darauf, ob er ein Telegram-Inline-Button sendet oder einfach weiterläuft.

Confirm ist die schwierigste Stufe

Autonom ist trivial: einfach machen. Veto ist trivial: einfach blockieren. Notify ist trivial: machen + senden. Aber bei Confirm entscheidet die Wartezeit darüber, ob die Stufe im Alltag trägt oder nervt.

Wenn ein Agent bei jedem zweiten Schritt anhält und auf Bestätigung wartet, ist das Erlebnis kaum besser als manuelles Arbeiten. Die Confirm-Stufe braucht drei Eigenschaften, damit sie produktiv ist:

Sub-Sekunden-Roundtrip, wenn der User antwortbereit ist. Im DCO heisst das: Telegram-Inline-Buttons, kein Form, kein Tippen.
Sinnvolles Default-Verhalten, wenn der User nicht antwortet. Timeout, der zurück auf "Abbruch" fällt, niemals stillschweigend ausführen.
Begründung in der Frage, nicht nur "Soll ich X tun?". Stattdessen "Soll ich X tun? Effekt: Y. Risiko: Z. Default bei keiner Antwort: Abbruch."

Die dritte Eigenschaft ist die wichtigste. Ein Agent, der auf Bestätigungen wartet, ohne den Effekt zu erklären, wird entweder per Reflex bestätigt oder per Reflex abgelehnt. Beides ist ein Failure-Mode.

Approval-Pfade als Architektur, nicht als Patch

Der häufigste Fehler beim Bau eigener Agenten ist, Approval als Nachgedanke zu implementieren — als ob-Block um den Tool-Aufruf, der "frag mal nach". Das hat zwei Probleme: erstens ist die Approval-Logik dann über den Code verstreut, statt zentral verwaltet zu werden. Zweitens kann man die Approval-Regeln nicht änderbar machen, ohne den Code anzufassen.

Die Lösung ist, Approval als zentrale Architektur-Schicht zu verstehen. Jedes Tool meldet beim Registrieren seine Approval-Stufe an den Orchestrator. Der Orchestrator entscheidet beim Aufruf, was zu tun ist. Änderungen an Approval-Regeln passieren am Tool, nicht an der Aufruf-Stelle. Das macht Approval testbar, versionierbar und auditierbar.

Was ich nicht gelöst habe

Drei Probleme bleiben offen, und ich erwähne sie ehrlich, weil sie der eigentliche Lern-Stoff sind:

Stille Änderungen sichtbar machen. Wenn ein Tool eine Datenbank im Hintergrund modifiziert, ohne dass ein Approval-Knopf gedrückt wurde, wie merkt der User es? Mein aktueller Hack: ein "Audit-Log"-Kanal in Telegram, der jeden Schreibvorgang nachträglich postet. Das ist Notify-Stufe über alle Schreiboperationen — funktioniert, aber laut.
Approval-Stufen veraltern. Was heute "Confirm" ist, könnte morgen "Notify" sein, weil ich mehr Vertrauen in das Tool habe. Wie versioniere ich diese Aenderung sauber, ohne dass alte Sessions noch die alte Regel nutzen? Im DCO ist das aktuell hartcodiert mit manuellem Edit — keine elegante Lösung.
Approval-Fatigue. Wenn der User 50 Bestätigungen am Tag bekommt, klickt er irgendwann "ja" ohne zu lesen. Gegenmittel: Approval-Stufen verschärfen, Notify aggressiv einsetzen, Aktionen bundlen ("Soll ich diese 5 Schritte machen?" statt 5 einzelne Fragen).

Approval-Pfade sind kein gelöster Bereich. Sie sind der Punkt, an dem Engineering-Disziplin und Produkt-Sinn aufeinandertreffen, und an dem Agentensysteme den Unterschied zwischen Spielzeug und Werkzeug machen.

An den eigenen Approval-Entscheidungen überrascht einen am Ende meist etwas anderes als erwartet. Wenn du selbst Agenten baust und das Thema dich umtreibt, schreib mir — ich sammle Ansätze.