Mehrere KI-Agenten ohne definierte Zuständigkeitsregeln scheitern lautlos. Ein Agenten-Team wird durch Trigger-Zuständigkeit — welcher Agent auf welches Ereignis reagiert — und Schreibberechtigung — welcher Agent welches Datenfeld ändern darf — strukturiert. Beides muss vor dem Start des zweiten Agenten festgelegt werden. Wer das überspringt, bemerkt die Probleme erst, wenn das CRM bereits widersprüchliche Datensätze enthält.
Drei Wochen nach dem Start eines zweiten Agenten stellte eine Recruiting-Firma fest, dass Kandidaten am selben Tag sowohl als „sourced" im Kontaktdatensatz als auch als „uncontacted" in der Pipeline-Ansicht markiert waren. Beide Agenten hatten korrekt gearbeitet. Das CRM enthielt zwei verschiedene Versionen der Wahrheit.
Genau das passiert, wenn Agenten Infrastruktur ohne definierte Zuständigkeiten teilen. Die Struktur eines KI-Agenten-Teams ist keine Funktionskarte — es ist eine Karte aus Trigger-Zuweisungen und Schreibberechtigungen. Beides muss vor dem Start des zweiten Agenten festgelegt werden.
Was ein Agenten-Team von einer Agenten-Sammlung unterscheidet
Mehrere KI-Agenten, die ohne Zuständigkeitsregeln dieselbe Umgebung teilen, sind kein Team — sie sind eine Sammlung von Agenten, die darauf warten zu kollidieren. Ein Team hat definierte Zuständigkeiten. Eine Sammlung hat definierte Aufgaben.
Der Unterschied ist wichtig, weil Aufgaben auf der Infrastrukturebene überlappen, auch wenn sie auf der Workflow-Ebene völlig getrennt erscheinen. Ein Intake-Agent und ein Follow-up-Agent scheinen völlig verschiedene Aufgaben zu erledigen. Beide lesen das CRM. Beide schreiben in Kontaktdatensätze. Ohne definierte Zuständigkeiten können beide gleichzeitig auf demselben Datensatz operieren — und widersprüchliche Ausgaben produzieren, ohne Fehler, ohne Benachrichtigung, ohne Hinweis, dass irgendetwas falsch gelaufen ist.
McKinseys State of AI Survey 2025 ergab, dass weniger als 10 % der Unternehmen KI-Agenten über eine einzige Geschäftsfunktion hinaus skaliert haben.[¹] Koordinationsfehler sind ein zentraler Faktor. Die meisten Multi-Agenten-Deployments stocken nicht, weil der zweite Agent in Isolation scheitert — sondern weil der zweite und der erste Agent auf eine Weise interagieren, die nie definiert wurde.
Die zwei Entscheidungen, die die Rolle jedes Agenten definieren
Die Rolle eines Agenten ist keine Stellenbeschreibung. Sie ist eine Trigger-Zuweisung und eine Schreibbeschränkung — welche Ereignisse ihn aktivieren und welche Datenfelder er ändern darf. Alles außerhalb dieser Definitionen liegt außerhalb seines Zuständigkeitsbereichs.
Jeder Agent in einem Multi-Agenten-System hat zwei definierende Eigenschaften: auf welche Trigger er reagiert und welche Datenfelder er schreiben darf.
Trigger-Zuständigkeit beantwortet: Welche Ereignisse aktivieren diesen Agenten? Eine Inbox-Nachricht, ein neuer CRM-Eintrag, eine Formulareinreichung, ein geplanter Zeitpunkt — jeder Trigger gehört genau einem Agenten. Wenn zwei Agenten theoretisch auf denselben Trigger reagieren könnten, entscheidet eine Routing-Regel, welcher zuständig ist. Die Regel lautet nicht „beide Agenten prüfen den Trigger, der erste gewinnt." Die Regel lautet: „Nur ein Agent ist für dieses Ereignis autorisiert."
Schreibberechtigung beantwortet: Welche Datenfelder darf dieser Agent ändern? Ein Agent darf jedes Feld lesen, das er für seine Arbeit benötigt. Ein Agent darf nur die Felder schreiben, die ihm explizit zugewiesen wurden. Wenn ein Agent ein Feld aktualisieren muss, das einem anderen Agenten gehört, erstellt er eine Aufgabe für diesen Agenten, anstatt direkt zu schreiben.
Diese zwei Entscheidungen — Trigger-Zuständigkeit und Schreibberechtigung — sind die Rollendefinition jedes Agenten im System. Sie werden vor dem Deployment festgelegt, dokumentiert und durchgesetzt.
Wie eine strukturierte Agenten-Team-Konfiguration in der Praxis aussieht
Das Trigger-Zuständigkeits- und Schreibberechtigungsmodell wird konkret, wenn es auf ein reales Setup angewendet wird. Die folgende Tabelle zeigt eine Standard-3-Agenten-Konfiguration für ein gründergeführtes Dienstleistungsunternehmen — Intake, Follow-up und Reporting — mit der vollständigen Rollendefinition jedes Agenten.
| Agent | Trigger-Zuständigkeit | Schreibberechtigung | Lesezugriff | Eskalationsauslöser |
|---|---|---|---|---|
| Intake-Agent | Neue Formulareinreichung, neuer CRM-Kontakt erstellt | Kontaktdatensatz, Lead-Qualifikationsfelder, Anfangsstatus | Template-Bibliothek, Kalenderverfügbarkeit | Eingabe entspricht keinem definierten Kontaktmuster |
| Follow-up-Agent | CRM-Status ändert sich auf „kontaktiert", geplante Kadenz-Ereignisse | Outreach-Aktivitätsprotokoll, Follow-up-Statusfeld | Kontaktdatensatz, Lead-Status (nur lesen), Pipeline-Ansicht | Lead-Antwort außerhalb definierter Antwort-Template-Typen |
| Reporting-Agent | Geplanter Zeitauslöser (täglich oder wöchentlich) | Bericht-Ausgabeziel (E-Mail, Notion, Slack) | Vollständiger CRM-Lesezugriff, Aktivitätsprotokoll, Pipeline | Datenlücke, die die Berichtsgenerierung verhindert |
Drei Dinge sind in dieser Struktur zu beachten. Erstens schreiben Intake-Agent und Follow-up-Agent nie in die Felder des anderen — der Intake-Agent besitzt den Kontaktdatensatz, der Follow-up-Agent besitzt das Aktivitätsprotokoll. Zweitens liest der Reporting-Agent nur; er hat keine Schreibberechtigung außer für sein eigenes Ausgabeziel. Drittens haben alle drei unterschiedliche Trigger — keine zwei Agenten reagieren auf dasselbe Ereignis.
Häufige Agentenrollen in Dienstleistungsunternehmen. Die drei Agenten oben decken die häufigste Konfiguration ab. Der Intake-Agent wird typischerweise zuerst eingesetzt — er übernimmt das strukturierteste hochvolumige Arbeitsvolumen und produziert schnell sichtbare Ergebnisse. Der Follow-up-Agent ist zweiter — er ist auf die sauber strukturierten Kontaktdatensätze des Intake-Agenten angewiesen. Der Reporting-Agent ist üblicherweise dritter — er fügt die Sichtbarkeitsebene hinzu, sobald die ersten beiden stabil sind und die von ihnen produzierten Daten vertrauenswürdig sind.
Ein vierter Agententyp, der bei höheren Volumina auftaucht: ein Routing-Agent, dessen einzige Aufgabe es ist, eingehende Ereignisse zu lesen und an den richtigen nachgelagerten Agenten weiterzuleiten. Der Routing-Agent besitzt keine eigenen Trigger — er sitzt vor der Trigger-Ebene und setzt die Regel „ein Trigger, ein Agent" durch, was bei vier oder mehr Agenten zur manuellen Wartungsaufgabe wird.
Wohin Eskalationen gehen, wenn kein Agent entscheiden kann
Das Team-Struktur-Problem ist nicht, wie viele Agenten Sie betreiben. Es ist, welcher wofür zuständig ist.
Jeder Agent wird irgendwann eine Eingabe erhalten, für die er nicht ausgelegt wurde. Eine Nachricht, die keinem definierten Trigger entspricht. Ein Kontaktdatensatz in einem unerwarteten Zustand. Ein Sonderfall, der zwischen den definierten Zuständigkeitsbereichen zweier Agenten fällt.
Ohne definierten Eskalationspfad wird diese Eingabe entweder nicht verarbeitet — als Ausnahme protokolliert, ohne dass eine Aktion erfolgt — oder der Agent rät und produziert eine Ausgabe, die vor dem Versand nicht geprüft wurde.
Der Eskalationspfad ist einfach: Jede nicht verarbeitete Eingabe wird in eine benannte Warteschlange geleitet, die ein Mensch nach einem definierten Zeitplan überprüft. Die Warteschlange ist kein Fehlerprotokoll. Die Warteschlange ist ein Entscheidungs-Eingang. Jeder Eintrag erfordert eine von drei Antworten: Der Zuständigkeitsbereich des Agenten wird erweitert, der Mensch behandelt diesen Fall direkt, oder die Eingabe wird als außerhalb des Zuständigkeitsbereichs klassifiziert.
Der Überprüfungszeitplan ist wichtig. Eine wöchentlich überprüfte Warteschlange findet Sonderfälle, nachdem sie sich angesammelt haben. Eine täglich überprüfte findet sie, bevor sie sich häufen. Für die meisten Servicebetriebe mit einem oder zwei Agenten reicht eine tägliche fünfminütige Überprüfung nicht verarbeiteter Eingaben aus.
Wann die Struktur bereit ist für Erweiterungen
Einen zweiten Agenten hinzuzufügen, bevor der erste stabil ist, löst das falsche Problem. Wenn der erste Agent inkonsistente Ausgaben produziert, verstärkt das Hinzufügen eines zweiten Agenten diese Probleme, anstatt sie zu lösen.
Die Bereitschaftssignale für die Erweiterung auf einen zweiten Agenten sind konkret: Der erste Agent hat mindestens vier Wochen ohne manuelle Eingriffe in seinen Kernworkflow gearbeitet; seine Trigger-Zuständigkeit und Schreibberechtigung sind dokumentiert, nicht nur angenommen; die Eskalationswarteschlange wird von einer benannten Person nach einem definierten Zeitplan überprüft.
Wenn diese drei Bedingungen erfüllt sind, ist die Struktur des ersten Agenten stabil genug, um Infrastruktur sicher zu teilen. Die Rolle des zweiten Agenten wird dann auf dieselbe Weise definiert: Welche Trigger gehören ihm, welche Datenfelder darf er schreiben, und wo eskaliert er. Der Prozess ist identisch — er gilt für den zweiten Agenten und jeden weiteren danach.
Der Skalierungspfad von einem auf drei Agenten folgt einer vorhersehbaren Abfolge:
| Stufe | Aktive Agenten | Neue Infrastruktur | Gate zur nächsten Stufe |
|---|---|---|---|
| Stufe 1 | 1 (Intake oder Follow-up) | Trigger-Zuständigkeitsdok., Schreibberechtigungsdok., Eskalationswarteschlange mit benanntem Prüfer | Erster Agent stabil seit 4+ Wochen, keine manuellen Eingriffe in den Kernworkflow |
| Stufe 2 | 2 (Intake + Follow-up) | Trigger-Routing-Regel, gemeinsames Prüfprotokoll, agentenübergreifende Lesezugriffsberechtigungen definiert | Beide Agenten stabil, Eskalationswarteschlange täglich überprüft, keine Koordinationsfehler in 2 Wochen |
| Stufe 3 | 3 (+ Reporting oder Spezialworkflow) | Audit der agentenübergreifenden Datenabhängigkeiten | Beide vorherigen Agenten stabil, alle Zuständigkeitsdokumente aktuell |
| Stufe 4+ | 4 oder mehr | Formelles Governance-Dokument, benannter Governance-Verantwortlicher | Erst nach Stabilität von Stufe 3 — siehe KI-Agent-Governance |
Gartner prognostiziert, dass 40 % der agentischen KI-Projekte bis Ende 2027 abgebrochen werden, wobei Projektkomplexität und Koordinationsfehler als Haupttreiber genannt werden.[²] Die Komplexität entsteht meist, wenn der zweite oder dritte Agent gestartet wird, bevor die Struktur des ersten dokumentiert ist. Die Lösung ist keine ausgefeiltere Koordinationsebene — es ist die Dokumentation, die von Anfang an hätte existieren sollen.
Mindestdokumentation vor dem Start des zweiten Agenten
Für ein Unternehmen, das derzeit einen Agenten betreibt und plant, innerhalb der nächsten drei Monate einen zweiten hinzuzufügen, sind vier Dokumente vor dem Start des zweiten Agenten erforderlich.
Trigger-Zuständigkeitskarte. Eine Liste aller Ereignisse, auf die beide Agenten theoretisch reagieren könnten — eingehende Nachrichten, CRM-Statusänderungen, geplante Zeiten, Formulareinreichungen — mit einem Agenten für jedes Ereignis. Falls ein Ereignis nicht zugewiesen ist, vor dem Start des zweiten Agenten zuweisen.
Schreibberechtigungskarte. Eine Liste aller Datenfelder, in die beide Agenten schreiben, mit einem Agenten als Schreiber für jedes. Wenn dasselbe Feld in beiden Agentenkonfigurationen erscheint, vor dem Start des zweiten Agenten einen Schreiber bestimmen.
Gemeinsames Prüfprotokollformat. Eine definierte Struktur, wie beide Agenten ihre Aktionen protokollieren — betroffene Entität, ausgeführte Aktion, Zeitstempel, Ergebnis. Beide Agenten verwenden dasselbe Format, damit die Fehlersuche eine Suche ist, keine Rekonstruktion.
Eskalationswarteschlangen-Verantwortlicher. Eine benannte Person, die nicht verarbeitete Eingaben nach einem definierten Zeitplan überprüft. Die Warteschlange ist nicht optional — jedes Multi-Agenten-System produziert Eingaben, die zwischen Agenten-Zuständigkeitsbereichen fallen.
Für eine vollständige Behandlung dessen, was schiefläuft, wenn mehrere Agenten Infrastruktur ohne Zuständigkeitsregeln teilen, und wie man Fehler im Nachhinein zurückverfolgt, siehe mehrere Agenten gleichzeitig betreiben. Für Anleitungen zur Skalierung über zwei Agenten hinaus, siehe wie man ein KI-Agenten-System skaliert.
Häufig gestellte Fragen
Was ist KI-Agenten-Teamstruktur? KI-Agenten-Teamstruktur ist der Satz definierter Zuständigkeitsregeln, die regeln, wie mehrere Agenten dieselbe Umgebung teilen. Eine Agenten-Teamstruktur legt fest, auf welche Trigger jeder Agent reagiert (Trigger-Zuständigkeit) und welche Datenfelder jeder Agent schreiben darf (Schreibberechtigung). Ohne diese Definitionen werden Agenten, die dasselbe CRM, denselben Posteingang oder denselben Kommunikationskanal teilen, irgendwann kollidieren.
Wie definiert man Rollen für KI-Agenten in einem Multi-Agenten-System? Weisen Sie jedem Agenten vor dem Deployment zwei Eigenschaften zu: welche Ereignisse ihn aktivieren (Trigger-Zuständigkeit) und welche Datenfelder er ändern kann (Schreibberechtigung). Ein Agent darf jedes Feld lesen, das er benötigt, aber nur explizit zugewiesene Felder schreiben. Wenn ein Agent ein Feld aktualisieren muss, das einem anderen gehört, erstellt er eine Aufgabe für diesen Agenten, anstatt direkt zu schreiben.
Wann sollte man einen zweiten KI-Agenten hinzufügen? Wenn der erste Agent mindestens vier Wochen ohne manuelle Eingriffe gearbeitet hat, seine Trigger-Zuständigkeit und Schreibberechtigung dokumentiert sind und die Eskalationswarteschlange nach einem definierten Zeitplan überprüft wird. Das Hinzufügen eines zweiten Agenten vor diesen Bedingungen führt Koordinationskomplexität zusätzlich zu ungelösten Problemen des ersten Agenten ein.
Was ist ein Eskalationspfad in einem Multi-Agenten-System? Ein Eskalationspfad ist die Routing-Regel für Eingaben, die außerhalb des definierten Zuständigkeitsbereichs jedes Agenten liegen. Jede nicht verarbeitete Eingabe wird in eine benannte Warteschlange geleitet, die von einem Menschen nach einem definierten Zeitplan überprüft wird. Jeder Eintrag führt zu einer von drei Entscheidungen: Der Zuständigkeitsbereich des Agenten wird erweitert, der Mensch behandelt den Fall direkt, oder die Eingabe wird als außerhalb des Zuständigkeitsbereichs klassifiziert.