Agent Rollen und Verantwortung

Ein Multi-Agent System funktioniert nur mit klaren Rollen. Jeder Agent muss wissen, was seine Aufgabe ist, welche Boundaries er hat und an wen er bei Problemen eskaliert — wie in einem menschlichen Team.

Das Minimum Viable Team

Für die meisten Anwendungen brauchst du mindestens diese drei Rollen:

Warum Agenten Tool-Einschränkungen brauchen

Warum nicht einfach jedem Agent Zugang zu jedem Tool geben? Die Antwort ist Sicherheit. Du würdest deinem Praktikanten nicht die Schlüssel zum Produktionsserver geben. Zugang einschränken ist keine Frage von Misstrauen — es geht darum, Unfälle zu verhindern.

Ein Researcher-Agent ist ein gutes Beispiel: Sein Job ist es, zu untersuchen und zu analysieren. Er liest Dateien, sucht nach Informationen und stellt Reports zusammen. Aber er kann keine Dateien schreiben oder Systembefehle ausführen. Eine Rechercheaufgabe sollte nie versehentlich eine wichtige Datei überschreiben. Die Einschränkung macht den Agent sicherer, ohne ihn für seinen eigentlichen Job weniger nützlich zu machen.

Context Loading: Warum jeder Agent andere Dateien liest

Wenn ein Agent aktiviert wird, lädt er nicht jede Datei im System. Er lädt nur die Dateien, die für seine Rolle relevant sind. Der Shop Manager lädt den Produktkatalog und Preisinformationen. Der Content Writer lädt den Brand-Voice-Guide und den Redaktionskalender.

Dieses selektive Context Loading dient zwei Zwecken: Erstens hält es den Agent fokussiert — ein Agent mit weniger, aber relevanterem Kontext liefert bessere Ergebnisse. Zweitens spart es Token-Nutzung, was schnellere Antworten und niedrigere API-Kosten bedeutet.

Erweiterte Rollen

Für komplexere Setups können diese Rollen hinzukommen:

Unser Team als Referenz

Verantwortungsketten (RACI)

Für jede Aufgabe sollte klar sein, wer was macht. Wir nutzen RACI:

Agent-Zusammenarbeit und Handoffs

Manchmal erfordert eine Aufgabe mehr als einen Agent. Zum Beispiel: "Recherchiere unseren Top-Konkurrenten und schreib dann einen Blogpost, der unser Produkt mit ihrem vergleicht." Das beinhaltet, dass der Researcher-Agent Informationen sammelt und der Content-Writer-Agent den Blogpost erstellt.

Das System löst das durch Handoffs: Der erste Agent erledigt seinen Teil der Arbeit und speichert das Ergebnis. Der zweite Agent nimmt dieses Ergebnis als Input und macht weiter. Jeder Agent arbeitet innerhalb seiner eigenen Grenzen, aber das Ergebnis ist eine nahtlose Zusammenarbeit — die Sicherheitsvorteile eingeschränkter Spezialisten kombiniert mit der Flexibilität von Multi-Agent-Zusammenarbeit.

Boundaries definieren

Jeder Agent muss wissen, was er NICHT tun darf:

• Keine Änderungen an Credentials ohne Bestätigung
• Keine destructive Commands (rm -rf, etc.) ohne explizite Freigabe
• Keine externen API-Calls ohne Kontext
• Keine Outputs über 10.000 Tokens ohne Chunking
• Keine Änderungen an Produktionssystemen ohne Tests

Eskalationspfade

Wenn etwas schiefgeht, gibt es klare Eskalationsstufen:

1. Worker erkennt Problem → versucht Fix (2 Versuche)
   ↓
2. Fix funktioniert nicht → postet Error + Context in Channel
   ↓
3. Manager (Manager-Agent) übernimmt → entweder:
   a) Selbst lösen
   b) An anderen Worker delegieren
   ↓
4. Manager kann nicht lösen → eskaliert an CEO (CEO)
   ↓
5. CEO entscheidet → weitermachen / verwerfen / extern holen