Anthropic hat ein Experiment veröffentlicht, das jeder kennen sollte, der gerade mehr als einen Agenten produktiv setzen will: Drei Claude-Agenten arbeiteten ohne geklärte Zuständigkeit an derselben Codebasis. Über vier Stunden eskalierten sie gegenseitig. Sie sperrten sich aus, stoppten die Arbeit der anderen, und einer tarnte seinen Prozess als den eines Konkurrenten. Keiner der Agenten war fehlerhaft. Es fehlte etwas anderes: Ownership.

Gleichzeitig ist in den Anwender-Communities rund um Enterprise-KI-Plattformen Multi-Agent vom Experiment zum Verkaufsargument geworden. Eine Beratung zeigt Interessenten als Standard-Pitch eine Referenzarchitektur aus 26 autonom arbeitenden Agenten, und berichtet, dass die meisten danach genau dieses Setup wollen. Die Nachfrage ist da. Die Frage ist, wer sein System so plant, dass es nicht endet wie das Experiment.

Warum Agenten eskalieren, wo Menschen sich abstimmen

Der Schluss aus der Studie ist unbequem präzise: Ohne definierte Zuständigkeit und Konfliktregeln liest jeder Agent die Aktion des anderen als Angriff. Ein Mensch, der eine fremde Änderung sieht, fragt im Chat nach. Ein Agent, der eine fremde Änderung sieht, korrigiert sie, denn genau dafür wurde er gebaut. Der zweite Agent sieht die Korrektur und korrigiert zurück. Was bei Menschen ein Flurgespräch klärt, wird bei Agenten zur Endlosschleife mit Werkzeugzugriff.

Deshalb gilt: Die Architektur-Entscheidung bei Multi-Agent-Systemen ist nicht die Modellwahl und nicht das Framework. Es ist die Zuständigkeits-Frage, und sie muss beantwortet sein, bevor der erste Agent läuft.

Schritt 1: Die Ownership-Karte

Bevor du irgendetwas baust, beantworte für jeden Prozess im geplanten System eine einzige Frage schriftlich: Welcher Agent besitzt diesen Prozess? Besitzen heißt: Er ist der Einzige, der dort schreibend eingreift. Alle anderen dürfen lesen, vorschlagen, melden, aber nicht anfassen.

Das Ergebnis ist eine Karte mit drei Spalten: Prozess, Owner, alle anderen. Wenn du für einen Prozess zwei Owner aufschreiben willst, hast du keinen Prozess, sondern zwei, und solltest ihn schneiden. Wenn du für einen Prozess keinen Owner findest, gehört er noch keinem Agenten, sondern einem Menschen.

Die weiteren Schritte, aus der Praxis der Communities und unserer eigenen Arbeit:

1. Konfliktregel je Berührungspunkt. Wo zwei Agenten denselben Gegenstand berühren, steht fest, wer weicht. Immer der Nicht-Owner.
2. Eskalation zum Menschen. Jeder Agent hat eine definierte Stelle, an der er stoppt und meldet, statt zu wiederholen. Wiederholung ist der Anfang der Schleife.
3. Visuell planen, dann bauen. In den Communities etabliert sich gerade die Praxis, Agenten-Systeme erst auf einem Canvas zu entwerfen (in der Art eines Whiteboards, aber für Agenten-Rollen und Datenflüsse) und Schwachstellen zu finden, bevor implementiert wird. Das Format ist zweitrangig. Dass die Karte vor dem Code existiert, ist der Punkt.
4. Rechte nach der Karte vergeben, nicht nach Bequemlichkeit. Der Owner bekommt Schreibrechte auf seinen Prozess, sonst niemand. Wir haben unseren eigenen Agent-Bestand bei DECAID gerade nach diesem Prinzip aufgeräumt, und dabei ist einiges kaputtgegangen, das vorher nur zufällig funktioniert hat.

Wie eng das mit der Sicherung deiner Agenten-Konfigurationen zusammenhängt, liest du in Deine Agenten-Instruktionen haben kein Backup.

Take

Multi-Agent-Systeme scheitern nicht an der Intelligenz der Agenten, sondern an ungeklärtem Besitz. Die Ownership-Karte kostet dich einen Nachmittag und ist damit die billigste Versicherung, die du für ein Agenten-System abschließen kannst. Was dabei kaputtging, als wir unseren eigenen Bestand aufgeräumt haben, und den kompletten 7-Punkte-Check dazu, zeigen Kai und Simon live am 8. September im Webinar: KI-Agents absichern.

Und wenn du dein geplantes Setup einmal gegen die Karte halten willst: Sprich mit Sarah.