Supervisor-Agent: Policies durchsetzen, Risiken stoppen

Kern des Patterns

Supervisor Agent ist ein Pattern, bei dem ein separater Agent die Ausfuehrung kontrolliert: er prueft vorgeschlagene Aktionen, wendet Regeln an und entscheidet, ob fortgesetzt werden darf.

Wann sinnvoll: wenn kritische Aktionen vor dem Fortsetzen separat per Policy freigegeben werden muessen.

Statt dem Worker bedingungslos zu vertrauen, macht Supervisor:

• prueft jede kritische Aktion
• vergleicht sie mit Policies
• gibt Entscheidung zurueck: approve, revise, block oder escalate
• protokolliert die Begruendung der Entscheidung

Problem

Stell dir vor, ein Worker-Agent fuehrt eine Aufgabe in Produktion aus und hat Zugriff auf Tools.

Er schlaegt eine technisch valide Aktion vor, die gegen Policy verstoesst:

• E-Mail an falsche Zielgruppe
• SQL-Query mit Risiko von Datenaenderung
• Ausgaben ueber Budget
• Zugriff auf sensible Daten ohne erforderlichen Access Scope

Ein technisch moeglicher Schritt ist nicht immer erlaubt oder sicher fuer das Business.

Ohne separate Kontrolle kann das direkt in die Ausfuehrung gehen.

Folgen:

• Vorfaelle in Produktion
• Sicherheits- und Compliance-Verstoesse
• unerwartete finanzielle Verluste
• schwaches Audit und schwierige Postmortem-Analyse

Genau darin liegt das Problem: ein Worker kann eine Aktion vorschlagen, die "technisch funktioniert", aber per Policy unzulaessig ist.

Loesung

Supervisor fuegt eine Policy-Control-Layer zwischen Aktionsvorschlag und Ausfuehrung ein.

Analogie: das ist wie ein technisches Review vor einem Produktions-Release. Der Worker schlaegt einen Schritt vor, und der Supervisor prueft, ob er sicher und zulaessig ist. Erst danach darf die Aktion ausgefuehrt werden.

Schluesselprinzip: zuerst Supervisor-Pruefung und Entscheidung, dann Ausfuehrung.

Der Worker schlaegt eine Aktion vor, und supervisor-policy gibt zurueck:

• approve
• revise
• block
• escalate

Gesteuerter Prozess:

1. Observe: Aktionsvorschlag vom Worker holen
2. Evaluate: gegen Policy + Ausfuehrungs-Runtime-State pruefen
3. Decide: approve/revise/block/escalate
4. Enforce: ausfuehren, zur Ueberarbeitung zurueckgeben oder stoppen
5. Log: Entscheidung und Begruendung aufzeichnen

Das bringt:

• geringeres Risiko unsicherer Aktionen vor der Ausfuehrung
• keine Moeglichkeit, Policy zu umgehen
• kontrollierte Eskalation zu einem Menschen
• transparentes Audit von Entscheidungen

Funktioniert gut, wenn:

• Worker keinen direkten Bypass der Execution-Layer hat
• Policy Intent + Runtime-Kontext prueft
• Supervisor-Entscheidungen real erzwungen werden
• High-Risk-Aktionen nicht automatisch freigegeben werden

Das Modell kann "wollen", einen Schritt sofort auszufuehren, aber supervisor-policy bestimmt, ob die Aktion ueberhaupt erlaubt ist.

Wie es funktioniert

Supervisor fuehrt die Business-Aufgabe nicht selbst aus.

Er kontrolliert, ob der naechste Schritt ausgefuehrt werden darf, durch Pruefung von:

• Sicherheit
• Budget
• Zugriffsrechten
• Compliance
• Stop Conditions

Im Code sieht das so aus

proposal = worker.next_action(context)

decision = supervisor.review(
    action=proposal,
    budget_state=budget_state,
    policy=policy,
)

if decision.type == "approve":
    result = execute(proposal)
    context.append(result)
elif decision.type == "revise":
    context.append(f"Supervisor feedback: {decision.reason}")
elif decision.type == "escalate":
    wait_for_human_approval(proposal)
else:
    stop(reason=decision.reason)

Supervisor ersetzt den Worker Agent nicht. Er fuegt eine Pruefung zwischen Planung und Ausfuehrung ein.

So sieht das waehrend der Ausfuehrung aus

Goal: Kundenrueckerstattung durchfuehren

Worker proposal:
- refund 5000 USD
- send confirmation email

Supervisor:
- policy check: auto-refund nur bis 1000 USD erlaubt
- Entscheidung: escalate, menschliche Bestaetigung erforderlich

Human approval (approve with changes):
- approved_refund_amount: 800 USD
- comment: "Rueckerstattung nur bis 800 USD freigeben"

Ausfuehrung:
- refund 800 USD (Betrag aus menschlicher Entscheidung)
- send confirmation email

Status: erledigt

Wann es passt - und wann nicht

Passt

Passt nicht

Denn Supervisor fuegt einen zusaetzlichen Pruefschritt hinzu und kann Ausfuehrung verlangsamen.

Unterschied Zu Guarded-Policy

Kurz: Supervisor ist eine Aufsichtsschicht fuer komplexe Entscheidungen.

Guarded-Policy ist eine automatische regelbasierte Barriere.

Wann Supervisor Verwenden (vs Andere Patterns)

Verwende Supervisor, wenn Aufsicht und Policy-Check vor finalem Ergebnis oder riskanter Aktion gebraucht werden.

Kurzer Test:

• wenn du "Policies, Compliance und Risiken pruefen" musst -> Supervisor
• wenn du "nur die Schrittreihenfolge steuern" musst -> Orchestrator Agent
• wenn du "Aktionen vor Ausfuehrung automatisch blockieren/umschreiben" musst -> Guarded-Policy Agent

Wie man es mit anderen Patterns kombiniert

• Supervisor + ReAct: Supervisor prueft jeden Act-Schritt vor dem Tool-Aufruf.
• Supervisor + Routing: nicht nur die Aktion wird kontrolliert, sondern auch, an wen die Aufgabe geroutet wurde.
• Supervisor + Orchestrator: Policies und Limits gelten fuer jeden parallelen Zweig, nicht nur fuer das Endergebnis.

Kurz gesagt

Vorteile und Nachteile

FAQ

Q: Ersetzt Supervisor Infrastruktur-Berechtigungen (RBAC, ACL)?
A: Nein. Das ist zusaetzliche logische Kontrolle. Basis-technische Restriktionen sollten in der Infrastruktur bleiben.

Q: Was tun, wenn Supervisor zu oft nuetzliche Aktionen blockiert?
A: Policies praezisieren: Ausnahmen, Risikostufen und Human-Approval-Regeln fuer graue Szenarien hinzufuegen.

Q: Kann Supervisor ein Single Point of Failure sein?
A: Ja, wenn kein Fallback vorgesehen ist. Deshalb werden meist Timeout, safe default policy und graceful degradation ergaenzt.

Was als Naechstes

Supervisor kontrolliert, dass einzelne Agenten innerhalb von Policy-Grenzen bleiben.

Aber was tun, wenn mehrere Agenten bei einer gemeinsamen Aufgabe zusammenarbeiten muessen?