KI-Agenten als Teamrollen entwerfen

Orchestrator, Reviewer, Spezialist und Dokumentation.

Ein KI-Agent wird nicht dadurch zu einem brauchbaren Teammitglied, dass man ihm einen Berufstitel gibt. „Du bist jetzt Projektmanager", „Du bist der kritische Reviewer" oder „Du bist unser Rechercheexperte" klingt nach Rollenklarheit, beschreibt aber noch fast nichts darüber, wie das System tatsächlich arbeiten soll. Wer darf welche Entscheidung treffen? Welche Quellen gelten? Welche Werkzeuge sind erlaubt? Was muss am Ende als prüfbares Artefakt vorliegen? Welche Unsicherheit muss sichtbar bleiben? Wann muss die Rolle stoppen und an einen Menschen übergeben?

Genau an diesen Fragen entscheidet sich, ob mehrere KI-Rollen eine belastbare Arbeitsarchitektur bilden oder nur mehrere unterschiedlich benannte Chats sind.

Der professionelle Entwurf beginnt deshalb nicht mit Persönlichkeiten, sondern mit Zuständigkeiten. Eine Rolle ist ein Arbeitsvertrag für einen begrenzten Entscheidungsraum. Sie definiert, welchen Teil einer Aufgabe ein Agent übernimmt, welchen Kontext er dafür benötigt, welche Rechte er besitzt, welche Ausgaben er liefern muss und woran seine Arbeit gemessen wird.

Diese Sichtweise führt zu einem entscheidenden Perspektivwechsel: Wir entwerfen keine künstlichen Kollegen, die möglichst menschlich wirken sollen. Wir entwerfen prüfbare Funktionen in einem Arbeitssystem.

Eine Rolle ist kein Charakter

Menschen verstehen Rollen intuitiv über soziale Erwartungen. Eine Redakteurin prüft anders als ein Entwickler, ein Projektleiter anders als eine Fachprüferin. Bei KI-Systemen kann diese Analogie hilfreich sein, solange sie nicht zur Anthropomorphisierung wird.

Ein Sprachmodell besitzt keine berufliche Identität. Es erhält Instruktionen, Kontext, Werkzeuge und einen erlaubten Handlungsraum. Wenn wir von einem „Reviewer-Agenten" sprechen, meinen wir deshalb keine künstliche Person mit Charaktereigenschaften. Gemeint ist eine funktional begrenzte Instanz, deren Aufgabe darin besteht, ein Ergebnis gegen festgelegte Kriterien und Evidenz zu prüfen.

Das ist mehr als Wortklauberei. Je menschlicher Rollen formuliert werden, desto leichter bleiben entscheidende technische Fragen unsichtbar. „Sei kritisch" ersetzt keine Prüfkriterien. „Handle wie ein Senior Engineer" definiert keine erlaubten Repository-Pfade. „Übernimm die Dokumentation" sagt noch nicht, welche Entscheidungen versioniert, welche Quellen referenziert und welche Änderungen nachvollziehbar protokolliert werden müssen.

Eine gute Agentenrolle lässt sich deshalb auch ohne Berufsmetapher beschreiben:

Input aufnehmen → begrenzte Funktion ausführen → definierten Output erzeugen → Evidenz mitliefern → Unsicherheit kennzeichnen → bei festgelegten Grenzen eskalieren.

Die Berufsbezeichnung kann anschließend als verständliches Etikett dienen. Sie darf aber niemals den funktionalen Vertrag ersetzen.

Von Aufgabenlisten zu Verantwortungsräumen

Ein früher Fehler beim Agentendesign besteht darin, Aufgaben einfach aufzuteilen: Agent A schreibt, Agent B prüft, Agent C dokumentiert. Das ist ein Anfang, aber noch keine Rollenarchitektur. Eine Aufgabenliste sagt nur, was getan werden soll. Eine Rolle muss zusätzlich klären, wofür sie verantwortlich ist und wofür ausdrücklich nicht.

Gerade in kleinen Projekten übernimmt ein Mensch häufig mehrere Funktionen gleichzeitig: Er produziert, prüft, dokumentiert, priorisiert und entscheidet. Sobald KI diese Arbeit beschleunigt, wird diese Vermischung problematisch. Ein System, das einen Entwurf erzeugt, sollte nicht automatisch die einzige Instanz sein, die seinen eigenen Entwurf für ausreichend erklärt. Eine Instanz, die Arbeitsaufträge verteilt, sollte nicht zwangsläufig zugleich alle risikoreichen Aktionen ausführen dürfen. Und eine Dokumentationsfunktion verliert ihren Kontrollwert, wenn sie nur nachträglich aus einem Chat rekonstruieren soll, was möglicherweise passiert ist.

Deshalb ist eine der stärksten Architekturen die funktionale Trennung von Orchestrierung, spezialisierter Ausführung, Review, Dokumentation und menschlicher Entscheidungshoheit.

Diese Trennung muss nicht sofort fünf getrennte technische Agenten bedeuten. Sie beschreibt zunächst fünf Verantwortungsfunktionen. Ob sie später in getrennten Instanzen, nacheinander mit derselben Modellbasis oder teilweise durch deterministische Software umgesetzt werden, ist eine zweite Frage.

Rollen sind Grenzobjekte zwischen Organisation und Technik

Eine gute Rollenbeschreibung erfüllt zwei Zwecke gleichzeitig. Sie muss für Menschen organisatorisch verständlich sein und für ein KI-System technisch handlungsleitend werden.

Auf der organisatorischen Ebene geht es um Zuständigkeit: Wer ist für welche Art von Arbeit verantwortlich? Wer darf freigeben? Wer darf zurückweisen? Wer muss informiert werden? Auf der technischen Ebene geht es um konkrete Begrenzungen: Welche Daten darf die Rolle sehen? Welche Tools darf sie aufrufen? Welche Dateien darf sie verändern? Welche Ausgaben müssen strukturiert erzeugt werden? Welche Bedingungen erzwingen einen Stop?

Deshalb ist eine Agentenrolle ein Grenzobjekt. Sie übersetzt Organisationslogik in ausführbare Systemlogik.

Diese Übersetzung ist besonders wichtig, weil natürliche Sprache sehr tolerant gegenüber Unschärfe ist. Menschen können aus dem Satz „Prüfe das kritisch und dokumentiere die Änderungen" viele unausgesprochene Konventionen ergänzen. Ein KI-System kann diese Konventionen nur dann verlässlich berücksichtigen, wenn sie als Kontext, Kriterien oder Rechte tatsächlich sichtbar werden.

Je riskanter der Prozess, desto weniger darf die Rolle von stillschweigenden Annahmen leben.

Der Rollenvertrag: acht Felder statt eines Rollenprompts

Ein Rollenprompt ist oft eine einzelne Textanweisung. Ein Rollenvertrag ist strukturierter. Er macht jene Elemente sichtbar, die später Verhalten, Prüfung und Verantwortlichkeit bestimmen.

1. Auftrag

Welche Funktion erfüllt die Rolle? Der Auftrag sollte als Ergebnisverantwortung formuliert sein, nicht als vage Aktivität. „Recherchiere das Thema" ist schwächer als: „Erstelle einen belegten Sachstand zu drei definierten Fragen und trenne bestätigte Aussagen, offene Punkte und widersprüchliche Quellen."

2. Gültiger Input

Auf welcher Version, welchen Quellen und welchem Datenraum darf gearbeitet werden? Diese Frage verhindert, dass veraltete Entwürfe, zufällige Chatverläufe oder nicht freigegebene Quellen unbemerkt Teil der Entscheidung werden.

3. Scope und Non-Scope

Was gehört ausdrücklich zur Rolle – und was nicht? Der Non-Scope ist oft wichtiger als eine lange Liste erwünschter Fähigkeiten. Er verhindert, dass ein Spezialist aus Eigeninitiative angrenzende Strategieentscheidungen übernimmt oder ein Reviewer beginnt, die gesamte Lösung umzubauen.

4. Entscheidungsrechte

Welche Entscheidungen darf die Rolle selbst treffen? Welche darf sie nur vorschlagen? Welche sind reserviert? Ein Agent kann beispielsweise eine Quelle als unzureichend markieren, aber nicht automatisch die Veröffentlichung eines gesamten Dokuments stoppen – oder genau umgekehrt, je nach Risikodesign.

5. Werkzeugrechte

Welche Datenquellen, APIs, Dateipfade, Kommunikationskanäle oder Aktionswerkzeuge sind erlaubt? Lesen, Schreiben, Löschen, Senden und Bezahlen sind unterschiedliche Risikoklassen. Werkzeugrechte machen eine Rolle technisch real.

6. Output-Vertrag

Was muss die Rolle abgeben? Freitext allein ist oft zu schwach. Ein Output-Vertrag kann Pflichtfelder enthalten: Ergebnis, Quellen, Unsicherheit, Tests, Änderungen, offene Fragen und nächste Entscheidung.

7. Qualitäts- und Evidenzkriterien

Woran wird erkannt, dass die Rolle ihre Aufgabe erfüllt hat? Ein Reviewer braucht Kriterien, ein Rechercheagent Quellenregeln, ein Coding-Spezialist Tests, eine Dokumentationsrolle Vollständigkeitsanforderungen.

8. Stop- und Eskalationsgrenze

Wann darf die Rolle nicht selbstständig fortfahren? Fehlende Pflichtdaten, widersprüchliche Evidenz, unklare Berechtigungen, irreversible Aktionen oder Zielkonflikte können Stopbedingungen sein.

Der Rollenvertrag ist damit nicht bloß ein längerer Prompt. Er ist die kleinste prüfbare Spezifikation einer Arbeitsfunktion.

Der Orchestrator hält Ziel und Zustand zusammen

Der Orchestrator wird leicht zum missverstandenen „Chef-Agenten". Seine zentrale Aufgabe ist jedoch nicht, alles besser zu wissen als die anderen Rollen. Er soll Ziel, Projektzustand und nächste sinnvolle Arbeit miteinander verbinden.

Dafür braucht er einen anderen Kontext als ein Fachspezialist. Er muss wissen, was das Ziel ist, welche Arbeit bereits abgeschlossen wurde, welche Abhängigkeiten bestehen, welche Blocker offen sind und welche Entscheidungen noch fehlen. Er muss nicht zwangsläufig jede Fachquelle im Detail lesen.

Ein guter Orchestrator beantwortet vor allem fünf Fragen: Welcher Zustand ist aktuell erreicht? Welche Bedingung fehlt bis zum nächsten sinnvollen Zustand? Welche Rolle ist dafür zuständig? Welche Eingaben braucht diese Rolle? Und muss vor dem nächsten Schritt eine menschliche Entscheidung erfolgen?

Damit wird Orchestrierung zu Zustandsmanagement statt Mikromanagement.

Problematisch wird es, wenn der Orchestrator zum Superagenten mutiert: Er besitzt alle Quellen, alle Tools, alle Schreibrechte, verteilt Aufgaben, korrigiert Facharbeit, gibt Ergebnisse frei und veröffentlicht sie anschließend selbst. Das ist bequem, aber die Rollenarchitektur verliert ihren eigentlichen Nutzen. Ein Fehler oder eine Fehlinterpretation hat dann einen maximalen Wirkungsradius.

Die bessere Leitfrage lautet deshalb nicht: „Wie mächtig kann der Orchestrator werden?", sondern: „Welche minimale Steuerungsinformation braucht er, um Arbeit richtig zu routen?"

Der Spezialist bekommt Tiefe durch Begrenzung

Spezialisierung entsteht bei Agenten nicht automatisch durch ein stärkeres Modell. Sie entsteht vor allem durch einen engeren Problemraum.

Ein Recherche-Spezialist kann beispielsweise nur die technische Machbarkeit einer bestimmten Schnittstelle untersuchen. Ein juristischer Spezialist bewertet nur eine klar abgegrenzte Rechtsfrage. Ein Frontend-Agent setzt ausschließlich eine definierte Oberfläche um. Eine Content-Rolle erstellt einen Entwurf aus freigegebenem Material, ohne selbst neue strategische Behauptungen einzuführen.

Begrenzung erhöht die Qualität aus zwei Gründen. Erstens sinkt die Wahrscheinlichkeit, dass irrelevanter Kontext die Entscheidung verwässert. Zweitens wird der Output leichter prüfbar, weil klar ist, wofür die Rolle verantwortlich war und wofür nicht.

Ein Spezialist braucht deshalb explizit eine präzise Fachfrage, einen definierten Quellen- oder Datenraum, zulässige Werkzeuge, einen Non-Scope, eine erwartete Outputform und Kriterien, wann die Aufgabe als gelöst gilt.

Ohne Non-Scope entsteht ein typisches Agentenproblem: lokale Optimierung. Der Spezialist verbessert seinen Ausschnitt so stark, dass er dabei das Gesamtziel verändert. Ein Entwickler baut eine elegante technische Architektur, obwohl der Use Case noch nicht validiert ist. Ein Rechercheagent ergänzt immer weitere Themen, obwohl die Entscheidungsfrage längst beantwortet wäre. Ein Redaktionsagent „verbessert" Fakten, die eigentlich nur geprüft werden sollten.

Spezialisierung ist deshalb nicht maximale Expertise ohne Grenzen, sondern Tiefe innerhalb eines bewusst zugeschnittenen Verantwortungsraums.

Der Reviewer ist keine zweite Meinung ohne Maßstab

„Lass ein zweites Modell drüberschauen" ist besser als gar keine Kontrolle, aber noch keine belastbare Reviewer-Rolle. Ein Reviewer braucht etwas, gegen das er prüft.

Das können Akzeptanzkriterien, Quellen, Tests, eine Spezifikation, ein Schema oder definierte Risikoklassen sein. Ohne diesen Maßstab produziert der Reviewer häufig nur eine weitere plausible Interpretation. Dann entstehen zwei Meinungen, aber kein stärkerer Nachweis.

Für einen professionellen Reviewer lassen sich fünf Regeln formulieren:

Erstens: Er prüft gegen Kriterien, nicht gegen seine stilistische Präferenz.

Zweitens: Er trennt Befund und Reparatur. Ein guter Reviewer darf eine Abweichung benennen, ohne sie sofort selbst unsichtbar zu überschreiben.

Drittens: Er unterscheidet Fehlerklassen. „Falsch", „nicht belegt", „unklar", „nicht getestet" und „außerhalb des Scopes" sind unterschiedliche Zustände.

Viertens: Er liefert Evidenz für seinen Befund – beispielsweise Testresultat, Quellenstelle, Schemakonflikt oder konkrete Abweichung vom Akzeptanzkriterium.

Fünftens: Sein Output endet mit einem definierten Status: akzeptieren, nacharbeiten, eskalieren oder blockieren.

Anthropic beschreibt in seinen Agentenmustern ein verwandtes Prinzip als Evaluator-Optimizer: Eine Instanz erzeugt, eine andere bewertet nach klaren Kriterien und gibt gezieltes Feedback. Der entscheidende Punkt ist nicht der Anbieter oder das konkrete Muster, sondern die Trennung von Generierung und Bewertung.^[1]

Gerade diese Trennung verhindert den Reviewer-as-Cheerleader-Effekt: Ein Modell lobt einen gut klingenden Text, obwohl es keine unabhängige Grundlage für eine Freigabe besitzt.

Review-Unabhängigkeit ist eine Designfrage

Ein häufiger Einwand lautet: Wenn Produzent und Reviewer auf demselben Basismodell laufen, sind sie dann überhaupt unabhängig? Die Antwort ist nicht binär.

Funktionale Unabhängigkeit beginnt damit, dass beide Rollen unterschiedliche Instruktionen, Kontexte, Rechte und Erfolgskriterien besitzen. Das kann bereits erhebliche Vorteile bringen. Ein Reviewer, der nur die Spezifikation und den zu prüfenden Output erhält, bewertet anders als derselbe Modelltyp, der zuvor den gesamten kreativen Entstehungsprozess gesehen hat.

Für höhere Risiken kann zusätzliche technische oder epistemische Unabhängigkeit sinnvoll sein: getrennte Modellfamilien, deterministische Tests, externe Quellen, formale Validatoren oder menschliche Fachprüfung.

Der wichtige Grundsatz lautet: Unabhängigkeit sollte proportional zum Fehlerrisiko gestaltet werden. Nicht jeder Blogentwurf braucht eine völlig getrennte Modellinfrastruktur. Aber eine sicherheitskritische Freigabe darf sich nicht darauf verlassen, dass dasselbe probabilistische System seine eigene Begründung einfach noch einmal liest.

Damit bleibt dieser Essay bewusst bei der Rollenlogik. Die vollständige Freigabe- und Gate-Architektur ist eine eigene Disziplin.

Dokumentation ist eine Kontrollrolle, keine Sekretariatsfunktion

Dokumentation wird in KI-Projekten häufig zu spät eingebaut. Erst wenn ein Problem entsteht, soll rekonstruiert werden, welche Version, welcher Prompt, welche Quelle oder welche Entscheidung zum aktuellen Zustand geführt hat.

Eine Dokumentationsrolle dreht diese Logik um. Sie behandelt Nachvollziehbarkeit als laufenden Bestandteil der Arbeit.

Ihre Aufgabe kann darin bestehen, Versionen zu kennzeichnen, Entscheidungen mit ihrem Grund festzuhalten, Quellenreferenzen zu sichern, Änderungen zwischen zwei Zuständen sichtbar zu machen und offene Unsicherheiten nicht verschwinden zu lassen. Der Doku-Agent muss dabei nicht jeden Token protokollieren. Er muss jene Zustandsänderungen festhalten, die später für Verständnis, Review oder Verantwortung relevant sind.

Gute Dokumentation beantwortet mindestens sechs Fragen: was sich verändert hat, auf welcher Grundlage, welche Rolle die Änderung vorgeschlagen hat, welche Prüfung durchgeführt wurde, welche Unsicherheit offen blieb und welcher Status jetzt gilt.

Damit wird Dokumentation zum Gedächtnis der Verantwortung. Sie verhindert, dass ein Projekt nur deshalb kohärent wirkt, weil der aktuelle Chat noch weiß, was vorher passiert ist.

Ein weiterer Vorteil ist organisatorisch: Rollen können wechseln, Modelle können gewechselt und Sessions können beendet werden. Wenn der Arbeitszustand sauber dokumentiert ist, bleibt der Prozess trotzdem übergabefähig.

Human Authority ist ein Entscheidungsrecht, kein Dauerbeobachter

Auch in einer stark agentischen Architektur muss geklärt sein, welche Entscheidungen beim Menschen bleiben. Diese Rolle sollte nicht als pauschales „der Mensch schaut am Ende noch einmal drauf" verstanden werden. Das wäre oft zu spät und zu unpräzise.

Human Authority bedeutet, dass bestimmte Entscheidungsklassen ausdrücklich nicht delegiert sind. Dazu können Änderungen des Projektziels, Risikoannahmen, hohe Kosten, externe Veröffentlichung, sensible Zugriffe, irreversible Aktionen oder Konflikte zwischen gleichwertigen Zielen gehören.

Wichtig ist die Formulierung als Recht, nicht nur als Verantwortung. Wenn ein Mensch verantwortlich bleiben soll, aber das System technisch bereits alle relevanten Entscheidungen ohne ihn ausführt, existiert die menschliche Autorität nur auf dem Papier.

Eine belastbare Rollenarchitektur verknüpft deshalb Entscheidung und technische Möglichkeit: Was der Mensch entscheiden muss, darf die Agentenrolle nicht stillschweigend vollenden.

Diese Logik bedeutet nicht, dass Menschen jeden Mikroschritt überwachen müssen. Im Gegenteil: Gute Rollentrennung soll den Menschen an den richtigen Stellen involvieren, statt ihn zum permanenten Zuschauer sämtlicher Modellschritte zu machen.

Kontextzugriff ist Teil des Rollendesigns

Ein häufiger Fehler lautet: Wenn Kontext wertvoll ist, muss jeder Agent möglichst alles sehen. Das Gegenteil kann professioneller sein.

Der Reviewer benötigt andere Informationen als der Produzent. Ein Dokumentationsagent braucht Versions- und Entscheidungsdaten, aber nicht zwingend jede kreative Vorüberlegung. Ein Spezialist braucht tiefes Fachmaterial zu seinem Teilproblem, aber möglicherweise keinen kompletten Chatverlauf über andere Projektbereiche. Der Orchestrator braucht einen guten Projektzustand, aber nicht unbedingt jede Rohquelle.

Rollenbezogener Kontext hat drei Vorteile:

Fokus: Relevante Informationen konkurrieren weniger mit Nebenthemen.

Prüfbarkeit: Später lässt sich nachvollziehen, auf welcher Wissensbasis eine Entscheidung getroffen wurde.

Datensparsamkeit: Sensible Informationen müssen nicht an Rollen gelangen, die sie für ihre Aufgabe nicht benötigen.

Kontextzugriff ist deshalb kein nachträgliches Prompt-Tuning. Er ist Teil der Zuständigkeitsarchitektur.

Eine nützliche Regel lautet: Jede Rolle erhält den kleinsten Kontext, der ihre Aufgabe vollständig lösbar macht – plus die Metadaten, die sie benötigt, um fehlenden Kontext zu erkennen.

Denn zu wenig Kontext ist ebenso gefährlich wie zu viel. Eine Rolle muss wissen, wann sie nachfragen oder eskalieren muss, statt eine Lücke plausibel zu füllen.

Werkzeugrechte machen Rollen real

Ein Rollenvertrag ohne Werkzeuggrenzen bleibt abstrakt. Zwei Agenten mit identischer Instruktion, aber unterschiedlichen Werkzeugrechten besitzen faktisch unterschiedliche Rollen.

OpenAI beschreibt Agenten entsprechend als Systeme, deren Verhalten nicht nur durch Instruktionen, sondern auch durch verfügbare Tools, Guardrails und Freigaben geprägt wird. Für die Rollenarchitektur bedeutet das: Werkzeugzugriff sollte nach Aufgabe und Risiko verteilt werden.^[3]

Ein Recherche-Spezialist kann Websuche und Leserechte erhalten, aber keine externen Nachrichten senden. Ein Reviewer darf Tests ausführen und Dateien lesen, aber keine geprüften Artefakte heimlich verändern. Ein Doku-Agent darf einen Änderungslog ergänzen, aber keine freigegebene Entscheidung überschreiben. Der Orchestrator darf Arbeitsaufträge erzeugen, aber keine kostenintensive externe Aktion ohne Autorisierung starten.

Damit wird Least Privilege zu einem produktiven Designprinzip: Jede Rolle erhält nur die Werkzeugfläche, die ihre Aufgabe vollständig ermöglicht.

Eine einfache Rechte-Matrix kann bereits viel Klarheit schaffen:

Die konkrete Matrix hängt vom Projekt ab. Entscheidend ist, dass Rechte nicht zufällig aus dem verwendeten Tool entstehen.

Ein Agentenname ist noch keine Schnittstelle

Sobald Rollen zusammenarbeiten, braucht jede Rolle eine lesbare Schnittstelle. Dabei geht es noch nicht um komplizierte Schwarmarchitektur. Schon zwei Rollen benötigen ein gemeinsames Verständnis dessen, was übergeben wird.

Ein sinnvoller Übergabegegenstand enthält beispielsweise:

Diese Struktur verhindert, dass Agenten sich gegenseitig nur lange Freitextantworten zuspielen. Eine Übergabe ist dann kein Gesprächsrest, sondern ein Arbeitszustand.

Wichtig ist auch hier die Begrenzung: Der Handoff soll genügend Kontext übertragen, damit die nächste Rolle sicher weiterarbeiten kann. Er soll aber nicht automatisch die gesamte Historie replizieren. Sonst wird jede Rollenübergabe zum wachsenden Kontextarchiv.

Die tiefe Frage, wie viele Agenten, Handoffs oder parallele Pfade ein Gesamtsystem braucht, gehört in die nächste Architekturebene. Für diesen Essay reicht der Grundsatz: Eine Rolle ist nur so klar wie ihre Ein- und Ausgangsschnittstelle.

Rollen brauchen Zustandsmodelle, nicht nur Textanweisungen

Eine Rolle kann perfekt beschrieben sein und trotzdem scheitern, wenn sie nicht weiß, in welchem Zustand sich die Arbeit befindet.

Ein Reviewer muss unterscheiden können, ob er einen ersten Entwurf, eine nachgebesserte Version oder eine bereits freigegebene Fassung sieht. Ein Spezialist muss wissen, ob seine Analyse nur explorativ ist oder bereits eine Implementierungsentscheidung vorbereitet. Eine Dokumentationsrolle muss erkennen, ob eine Änderung vorgeschlagen, akzeptiert oder verworfen wurde.

Dafür helfen wenige explizite Statuswerte mehr als lange Chatverläufe. Beispielsweise:

DRAFT → IN REVIEW → REWORK → READY FOR DECISION → APPROVED / BLOCKED

Diese Zustände sind keine universelle Norm. Sie zeigen ein Prinzip: Rollen sollten nicht aus Dialogtext erraten müssen, was der aktuelle Status bedeutet.

Ein klarer Zustand reduziert drei Fehlerklassen: eine Rolle arbeitet auf einer veralteten Fassung, eine Rolle behandelt einen Vorschlag als Entscheidung, oder eine Rolle setzt Arbeit fort, obwohl ein Stop- oder Reviewzustand aktiv ist.

Zustandsklarheit ist deshalb die unspektakuläre Infrastruktur hinter guter Rollenklarheit.

Rollen müssen beobachtbar werden

Ein Rollenvertrag ist nur dann professionell, wenn man später erkennen kann, ob die Rolle ihn eingehalten hat. Das bedeutet nicht, jeden internen Modellgedanken zu protokollieren. Es bedeutet, relevantes Verhalten sichtbar zu machen.

Für unterschiedliche Rollen können unterschiedliche Beobachtungsgrößen sinnvoll sein:

Diese Messung muss nicht sofort ein komplexes Dashboard erzeugen. Schon strukturierte Logs, Prüffelder und wenige wiederholbare Testfälle können Rollendrift sichtbar machen.

Der zentrale Gedanke lautet: Was nicht beobachtbar ist, kann nur schwer gesteuert oder verbessert werden.

Eine Rolle muss getestet werden wie ein Arbeitsprozess

Ob eine Rollenbeschreibung gut klingt, ist kein ausreichender Test. Eine Rolle sollte an repräsentativen Fällen geprüft werden.

Dafür eignen sich vier Testtypen:

Normalfall

Kann die Rolle ihre Kernaufgabe mit vollständigem Input korrekt abschließen?

Grenzfall

Erkennt sie fehlende, widersprüchliche oder unklare Informationen und fordert gezielt Nachbesserung an?

Stop-Fall

Verweigert oder eskaliert sie eine Aktion, die außerhalb ihrer Rechte oder ihres Scopes liegt?

Revisionsfall

Kann die Rolle gezieltes Feedback übernehmen, ohne dabei ihre eigenen Zuständigkeitsgrenzen zu verlieren?

Diese Tests übersetzen die praktische Idee des Rollendesigns in eine wiederholbare Lernschleife: Rolle definieren, in einen frischen Arbeitskontext geben, eine reale Teilaufgabe bearbeiten lassen, Output gegen Kriterien prüfen und die Rollenbeschreibung nachschärfen.

OpenAI empfiehlt bei Workspace Agents ebenfalls, mit realistischen normalen und „messy" Fällen zu testen, fehlenden Kontext sichtbar zu machen und Instruktionen sowie Guardrails iterativ zu präzisieren.^[5] Anthropic betont in seiner aktuellen Eval-Arbeit, dass agentische Systeme wegen ihrer mehrstufigen, zustandsverändernden Arbeitsweise besonders von systematischen Evals profitieren.^[2]

Nicht der schönste Rollenprompt gewinnt, sondern derjenige, dessen Verhalten wiederholbar innerhalb der vorgesehenen Grenzen bleibt.

Rollen entwickeln sich – und können driften

Eine Agentenrolle ist kein einmal geschriebenes Dokument, das unverändert bleibt. Modelle ändern sich, Tools erhalten neue Funktionen, Datenquellen verändern sich und Teams lernen aus Fehlern. Damit kann auch das beobachtete Rollenverhalten driften.

Es ist deshalb sinnvoll, Rollen wie kleine operative Standards zu versionieren. Eine Änderung sollte mindestens beantworten, was am Rollenvertrag verändert wurde, welches beobachtete Problem der Grund war, welche Testfälle erneut laufen müssen und ob die Anpassung Scope, Rechte oder Eskalationslogik verändert.

Besonders kritisch sind scheinbar kleine Erweiterungen: „Der Reviewer darf Fehler jetzt direkt reparieren", „Der Rechercheagent darf zusätzlich E-Mails senden" oder „Der Orchestrator bekommt Zugriff auf alle Projektordner." Solche Änderungen können die Rollenarchitektur stärker verändern als ein neuer Promptstil.

Rollenpflege bedeutet deshalb, Verhaltensänderungen bewusst zu behandeln statt sie in Promptwachstum zu verstecken.

Wann eine zusätzliche Rolle nicht sinnvoll ist

Rollentrennung ist kein Selbstzweck. Ein System wird nicht professioneller, nur weil aus einer Aufgabe fünf Agenten werden.

Eine zusätzliche Rolle lohnt sich besonders dann, wenn eine eigene Fachperspektive einen anderen Kontext benötigt, Erzeugung und Prüfung getrennt werden sollten, unterschiedliche Werkzeugrechte notwendig sind, eine Verantwortungsgrenze organisatorisch sichtbar sein muss, ein Teilprozess eine eigene Qualitäts- oder Evidenzlogik benötigt, oder die Funktion unabhängig getestet oder später ausgetauscht werden können soll.

Wenn all diese Unterschiede fehlen, ist ein weiterer Agent möglicherweise nur zusätzliche Koordinationslast. Dann kann ein einzelner Agent mit klarer interner Routine oder sogar ein deterministischer Workflow die bessere Architektur sein.

Das schützt vor einem neuen Typ Toolhörigkeit: Agenten um der Agenten willen.

Sieben typische Fehlkonstruktionen

Die Persona ohne Rechte

„Du bist Senior Reviewer" klingt präzise, aber es fehlen Quellen, Kriterien, Toolrechte und Stopbedingungen. Das Modell spielt eine Rolle, statt eine Funktion zuverlässig auszuführen.

Der Spezialist ohne Non-Scope

Eine fachlich starke Rolle beginnt, angrenzende Entscheidungen mitzuerledigen. Sie optimiert lokal und verändert dabei unbemerkt das Gesamtprojekt.

Der Reviewer, der alles repariert

Wenn derselbe Reviewer jeden Befund sofort selbst umschreibt, verschwimmt die Grenze zwischen Prüfung und Produktion. Später ist kaum noch erkennbar, was eigentlich beanstandet wurde.

Die Dokumentation nach Feierabend

Entscheidungen werden erst rückwirkend aus Chats rekonstruiert. Dabei gehen Unsicherheiten, verworfene Varianten und Gründe für Änderungen verloren.

Der Orchestrator als Superagent

Eine zentrale Instanz erhält alle Quellen, alle Tools und alle Entscheidungsrechte. Die Architektur hat zwar einen Agentennamen, aber kaum funktionale Gewaltenteilung.

Geteiltes Gedächtnis ohne Quellenklarheit

Alle Rollen sehen denselben riesigen Kontext. Niemand kann später sagen, welche Information tatsächlich eine Entscheidung beeinflusst hat und ob sie überhaupt für diese Rolle freigegeben war.

Der menschliche Freigabepunkt ohne technische Sperre

Auf dem Papier soll ein Mensch entscheiden. Technisch kann das System die Aktion aber bereits durchführen. Verantwortung und tatsächliche Kontrolle fallen auseinander.

Diese Fehlkonstruktionen haben eine gemeinsame Ursache: Die Rolle wurde als Textpersona gedacht, nicht als Teil eines kontrollierbaren Systems.

Ein Beispiel: Veröffentlichung eines Fachartikels

Ein einfaches Publikationsprojekt zeigt, wie Rollentrennung aussehen kann, ohne daraus sofort ein komplexes Multi-Agent-System zu bauen.

Orchestrator: Hält Artikelziel, freigegebenen Scope, Arbeitsstatus und offene Entscheidungen zusammen. Er beauftragt Recherche, Entwurf oder Review, verändert aber keine fachlichen Aussagen eigenmächtig.

Recherche-Spezialist: Beantwortet klar definierte Sachfragen aus freigegebenen Quellen. Er liefert Aussage, Quelle, Datum, Unsicherheit und gegebenenfalls Konflikte. Er entscheidet nicht über die redaktionelle These.

Redaktions-Spezialist: Schreibt aus freigegebenem Material. Er darf strukturieren, verdichten und erklären, aber keine neuen Tatsachenbehauptungen erfinden.

Reviewer: Prüft These, Quellenbezug, Widersprüche, Abgrenzung und Publikationskriterien. Er liefert Befunde und Rückgabegründe; Korrekturen werden sichtbar nachgearbeitet.

Dokumentation: Hält Quellenstand, Versionen, Änderungen und Freigabestatus fest.

Human Authority: Entscheidet über strittige Aussagen, inhaltliche Richtungsänderungen und die externe Veröffentlichung.

Der Nutzen dieser Trennung ist nicht, dass sechs „digitale Mitarbeiter" spektakulär nebeneinander arbeiten. Der Nutzen besteht darin, dass Produktion, Prüfung, Nachweis und Entscheidung nicht mehr ununterscheidbar ineinanderfallen.

Die Rollenkarte: ein kompaktes Arbeitsformat

Für die Praxis muss ein Rollenvertrag nicht seitenlang sein. Eine kompakte Rollenkarte kann genügen:

Eine gute Rollenkarte hat einen überraschenden Effekt: Sie zwingt den Menschen, sich selbst über den Arbeitsprozess klar zu werden. Viele Probleme, die zunächst wie „KI-Probleme" wirken, entpuppen sich dabei als ungeklärte Zuständigkeiten, uneindeutige Qualitätsmaßstäbe oder fehlende Entscheidungsrechte.

Damit ist Rollendesign nicht nur Prompt Engineering. Es ist Organisationsdesign in ausführbarer Form.

Ein praktischer Aufbaupfad in sechs Schritten

Wer Agentenrollen in einem realen Projekt einführen möchte, muss nicht sofort eine komplexe Infrastruktur bauen.

1. Funktionen sichtbar machen. Welche Arbeit wird heute produziert, geprüft, dokumentiert, koordiniert und entschieden?

2. Verantwortungen trennen. Wo ist es riskant, wenn dieselbe Instanz alles gleichzeitig macht?

3. Rollenkarte schreiben. Auftrag, Input, Scope, Rechte, Output, Qualität und Stopbedingungen definieren.

4. Eine reale Aufgabe testen. Nicht mit einem perfekten Demo-Fall, sondern mit einem typischen Arbeitsbeispiel.

5. Grenz- und Stopfälle prüfen. Fehlende Daten, widersprüchliche Quellen und unerlaubte Aktionen bewusst testen.

6. Erst danach automatisieren oder vervielfachen. Eine funktionierende Rolle kann später in einen größeren agentischen Ablauf eingebunden werden. Eine unklare Rolle wird durch mehr Orchestrierung nur schneller unklar.

Dieser Aufbaupfad entspricht einer allgemeinen Designregel: Komplexität erst hinzufügen, wenn die einfachere Struktur ihren Zweck und ihre Grenzen gezeigt hat.

Die eigentliche Teamfähigkeit entsteht durch Grenzen

Bei Menschen klingt Teamfähigkeit oft nach Kommunikation, Flexibilität und Kooperation. Für KI-Agenten kommt eine weitere Eigenschaft hinzu: begrenzte Zuständigkeit.

Ein Agent wird nicht dadurch teamfähiger, dass er alles darf. Er wird teamfähiger, wenn andere Rollen sich darauf verlassen können, was er tut, was er nicht tut und wie sein Ergebnis aussieht.

Der Orchestrator muss darauf vertrauen können, dass ein Spezialist nicht heimlich den Scope verändert. Der Spezialist muss wissen, welche Version gilt. Der Reviewer muss ein Ergebnis gegen unabhängige Kriterien prüfen können. Die Dokumentation muss Zustandsänderungen nachvollziehbar halten. Der Mensch muss sicher sein, dass reservierte Entscheidungen tatsächlich reserviert bleiben.

So entsteht aus einzelnen Modellen ein arbeitsteiliges System.

Die zentrale Frage lautet deshalb nicht: „Wie viele Agenten brauchen wir?"

Sie lautet: „Welche Verantwortungen müssen wir so sauber trennen, dass Arbeit delegierbar, prüfbar und rückholbar wird?"

Erst wenn diese Rollen stehen, lohnt sich die nächste Ebene: Wie mehrere Agenten koordiniert, parallelisiert und über Handoffs oder Manager-Muster orchestriert werden. Genau dort beginnt die Architektur des folgenden Artikels.

Öffentliche Quellen zur Vertiefung