Governance für Multi-Agent-Systeme: Koordination, Berechtigungen und Eskalationskontrolle

Idee in 30 Sekunden

Multi-agent governance ist Runtime-Kontrolle der Koordination zwischen Agenten: wer eine Subtask besitzt, wer delegieren darf und wann eine Handoff-Kette gestoppt werden muss.

Wann das nötig ist:
wenn mehrere Agenten in einem Workflow arbeiten und Risiko für doppelte Aktionen, Rollen-Konflikte oder unkontrollierten Fan-out besteht.

Problem

Ohne Governance geht ein Multi-Agent-System schnell in Chaos über: Agenten delegieren sich Aufgaben gegenseitig, duplizieren Aufrufe und verbrauchen ein gemeinsames Budget ohne finalen Fortschritt. Im Demo wirkt das oft "lebendig". In Production wird daraus Latenz, Mehrkosten und instabiles Ergebnis.

Typische Folgen:

eine Subtask hat mehrere Owner
Handoff-Kette wächst ohne Abschluss
shared budget wird für Duplikate verbraucht

Analogie: Das ist wie ein Team ohne Dispatcher. Alle sind beschäftigt, machen aber dieselbe Arbeit, während kritische Aufgaben in Übergaben hängen bleiben.

Und jede Minute ohne Koordinationsregeln erhöht das Risiko von Kaskadenfehlern zwischen Agenten.

Lösung

Die Lösung ist ein zentraler Policy-Layer für Multi-Agent-Orchestration in Runtime. Jede Delegation durchläuft Checks: role ownership, handoff limits, shared budgets und approval gate für riskante Aktionen.

Für Runtime braucht es ein einheitliches Outcome-Modell:

allow
stop
approval_required

Typische stop reasons im Multi-Agent-Kontur:

ownership_conflict
handoff_budget_exceeded
delegation_depth_exceeded
shared_budget_exceeded

Das ist kein Modell-Tipp, sondern erzwungene Ausführungskontrolle vor jeder neuen Delegation.

Multi-agent governance ≠ orchestration

Das sind unterschiedliche Systemschichten:

Orchestration definiert das Routing von Aufgaben zwischen Agenten.
Governance begrenzt dieses Routing mit Policy-Regeln.

Eins ohne das andere funktioniert nicht:

ohne orchestration gibt es keinen gesteuerten Workflow
ohne governance degradiert orchestration leicht zu Duplikaten, Konflikten und Loops

Beispiel:

orchestration: planner -> researcher -> writer
governance: max_handoffs=8, max_depth=3, ownership_lock=true

Komponenten der Multi-Agent-Governance

Diese Komponenten arbeiten bei jedem Handoff zwischen Agenten zusammen.

Komponente	Was sie kontrolliert	Zentrale Mechanik	Warum
Role ownership	Wer Owner der Subtask ist	role map ownership lock	Blockiert Duplikate und Verantwortungs-Konflikte
Handoff limits	Tiefe und Anzahl von Übergaben	`max_handoffs` `max_delegation_depth`	Stoppt Delegation-Loops vor Incident
Shared budgets	Gesamtkosten des ganzen Agent-Teams	shared `max_usd` shared `max_tool_calls`	Verhindert, dass mehrere Agenten gemeinsam das Budget reißen
Approval gates	Riskante Cross-Agent-Aktionen	`approval_required` TTL + explicit approver	Fügt menschliche Kontrolle vor irreversiblen Write-Operationen hinzu
Cross-agent audit trail	Transparenz von Delegationen und Entscheidungen	handoff log decision + reason + owner	Liefert reproduzierbare Ereigniskette für Incident Review

Beispiel-Alert:

Slack: 🛑 Multi-Agent run run_742 stopped: ownership_conflict, handoff=planner -> researcher, task=refund_check.

Wie das in der Architektur aussieht

Multi-Agent-Policy-Layer sitzt in der Orchestrator-Runtime-Loop zwischen Planung und Delegation von Subtasks. Jede Entscheidung (allow oder stop) wird im Audit Log erfasst. Das ist eine logische Policy-Schicht in Runtime, kein separater Service.

approval_required für riskante Write-Aktionen wird in einem separaten Approval-Flow über diesem Kontur verarbeitet.

Jeder Handoff passiert diesen Flow vor Ausführung:

orchestrator runtime bildet die nächste Subtask
policy prüft owner, handoff budget, delegation depth und shared budgets
allow -> Subtask wird an einen konkreten Agenten delegiert
stop -> orchestrator runtime wechselt in fallback (single-agent oder constrained mode)
beide Entscheidungen werden ins Audit Log geschrieben

Beispiel

planner delegiert refund_check an researcher, aber diese Subtask hat bereits owner=billing_agent. Policy gibt stop (reason=ownership_conflict) zurück.

Ergebnis:

Delegation wird nicht ausgeführt
run wächst nicht in Duplikate
in Logs ist Owner-Konflikt mit Stop-Grund sichtbar

Multi-agent governance stoppt den Incident vor Fan-out, nicht nach Budgetverlust.

Im Code sieht das so aus

Die vereinfachte Skizze oben zeigt den Haupt-Flow. Kritisch: Prüfung muss zentral laufen, sonst umgehen Agenten Limits über parallele Handoffs.

Beispiel für Policy-Konfiguration:

YAML

multi_agent:
  max_agents_per_run: 4
  max_handoffs: 8
  max_delegation_depth: 3
  shared_max_usd: 30
  shared_max_tool_calls: 120
  require_approval_for:
    - billing.refund.create

PYTHON

task = orchestrator.next_task(state)
decision = multi_agent_policy.check(task, state)

audit.log(
    run_id,
    phase="pre_handoff",
    decision=decision.outcome,
    reason=decision.reason,
    owner=decision.owner,
    from_agent=task.from_agent,
    to_agent=task.to_agent,
    depth=state.delegation_depth,
)

if decision.outcome == "approval_required":
    # approve/resume flow wird als separater Schritt geloggt:
    # approval_required -> approval_granted -> allow
    return stop("approval_required")

if decision.outcome == "stop":
    return stop(decision.reason)

result = orchestrator.delegate(task)

shared_budget.consume(
    usd=result.cost_usd,
    tool_calls=result.tool_calls,
)

post_budget_decision = shared_budget.check()
if not post_budget_decision.ok:
    audit.log(
        run_id,
        phase="post_handoff",
        decision="stop",
        reason=post_budget_decision.reason,
        owner=decision.owner,
        handoff_status=result.status,
    )
    return stop(post_budget_decision.reason)

audit.log(
    run_id,
    phase="post_handoff",
    decision=decision.outcome,
    reason=decision.reason,
    owner=decision.owner,
    handoff_status=result.status,
)

return result

Wie das während der Ausführung aussieht

Szenario 1: ownership conflict

planner bildet Delegation refund_check.
Policy sieht, dass Subtask-Owner bereits auf anderem Agenten gelockt ist.
Entscheidung: stop (reason=ownership_conflict).
Handoff wird vor Ausführung blockiert.
Konflikt wird im Audit Log erfasst.

Szenario 2: handoff budget exceeded

Run hat bereits 8 Subtask-Übergaben gemacht.
Nächste Delegation überschreitet max_handoffs.
Entscheidung: stop (reason=handoff_budget_exceeded).
Runtime wechselt in Fallback-Mode.
System geht nicht in unendlichen Delegation-Loop.

Szenario 3: normaler gesteuerter handoff

Runtime bildet neue Subtask mit validem Owner.
Policy prüft alle Limits: alles im Rahmen.
Entscheidung: allow.
Delegation wird ausgeführt und liefert Ergebnis.
pre_handoff- und post_handoff-Events werden in Audit Trail geschrieben.

Typische Fehler

mehrere Agenten ohne role ownership map starten
handoff ohne Limit für Tiefe und Anzahl erlauben
Budgets pro Agent statt shared pro run zählen
kein fallback bei stop
nur finales Ergebnis ohne Delegationshistorie loggen
orchestration- und governance-Regeln im Prompt mischen

Ergebnis: System wirkt skalierbar, verliert unter Last aber schnell die Kontrolle.

Selbstcheck

Schneller Multi-Agent-Governance-Check vor dem Production-Start:

Es gibt role map und ownership lock für jede Subtask
Es gibt Limits für max_handoffs und max_delegation_depth
Es gibt shared budget für den ganzen run, nicht nur per-agent
Riskante Aktionen laufen über approval_required
Jeder handoff hat expliziten outcome und reason
Es gibt fallback mode bei stop (single-agent oder constrained mode)
Alle handoff-Entscheidungen werden ins Audit Log geschrieben
Es gibt Alerts auf ownership_conflict und budget/depth stop reasons

Fortschritt: 0/8

⚠ Grundlegende Governance-Kontrollen fehlen

Vor production brauchen Sie mindestens Zugriffskontrolle, Limits, audit logs und einen Not-Stopp.

FAQ

Q: Wann ist ein Multi-Agent-Ansatz wirklich sinnvoll?
A: Wenn Subtasks wirklich unabhängig sind und unterschiedliche Expertise brauchen. Ist der Workflow kurz und linear, ist ein Agent oft einfacher und robuster.

Q: Wer sollte final entscheiden: orchestrator oder separater Agent?
A: Besser ein verantwortlicher orchestrator/policy layer. Sonst steigt Risiko für Konflikte und Ping-Pong zwischen Agenten.

Q: Können Agenten ohne Policy-Check direkt delegieren?
A: Für Production: nein. Jeder handoff sollte zentral auf ownership, limits und budget geprüft werden.

Q: Wie Budget in Multi-Agent-Run rechnen?
A: Als shared budget für alle Agenten zusammen. Sonst ist jeder Agent einzeln "im Limit", aber der Gesamt-Run reißt die Grenze.

Q: Ersetzt Multi-Agent-Governance step limits und rate limiting?
A: Nein. Es ergänzt sie: Governance steuert Koordination zwischen Agenten, step/rate controls steuern Ausführungsverhalten.

Wo Multi-Agent Governance im Gesamtsystem liegt

Multi-agent governance ist die Agent-Governance-Schicht für orchestrierte Agent-Teams. Zusammen mit RBAC, budget controls, approval, rate limiting und audit bildet sie kontrollierte Runtime für komplexe Workflows.