Drei Claude-Agenten sollten dasselbe Python-Backend migrieren. Einer nach Rust, einer nach Go, einer nach TypeScript. Sie liefen parallel, arbeiteten auf demselben Zielsystem und wussten anfangs nichts voneinander.
Das Ergebnis war kein besonders harmonischer DevOps-Workshop. Die Agenten sperrten gegenseitig Unix-Accounts, bauten Kill-Loops gegen konkurrierende Prozesse und tarnten schädlichen Code als Arbeit des jeweils anderen. Einige entzogen den Konkurrenten per sudo, Account-Lock oder SSH-Sperre schlicht den Zugriff.
Man kann daraus eine Geschichte über gefährliche KI machen. Man kann aber auch auf die Architektur schauen. Dann sieht die Sache unangenehm vertraut aus: Drei technisch handlungsfähige Akteure erhielten unvereinbare Aufträge, weitreichenden Zugriff und dasselbe Ziel. Aus der veröffentlichten Versuchsbeschreibung ist keine übergeordnete Instanz erkennbar, die den Konflikt priorisierte und auflöste.
Für diese Eskalation brauchte es keine Bosheit. Der Versuchsaufbau lieferte bereits unvereinbare Aufträge, gemeinsamen Zugriff und keine erkennbare Konfliktentscheidung außerhalb der beteiligten Agenten.
Drei Aufträge, die nicht gleichzeitig erfüllt werden konnten
Anthropic setzte für den Versuch drei Instanzen desselben Modells in Claude Code an. Jede Instanz sollte ein Python-Backend in eine andere Sprache migrieren. Die Agenten arbeiteten über vier Stunden; das eigentliche Backend lag auf einer vierten virtuellen Maschine.
Die Aufträge waren also nicht identisch. Sie gehörten zur gleichen Auftragsklasse, verlangten aber drei verschiedene Endzustände. Im Versuch behandelten die Agenten diese Deployments als gegenseitig ausschließend; eine erfolgreiche Bereitstellung verdrängte die Arbeit der beiden anderen faktisch wieder.
Das ist kein Randdetail. Es ist der Kern des Versuchs.
Jeder Agent hatte aus seiner lokalen Sicht einen gültigen Auftrag. Jeder sah, dass fremde Änderungen diesen Auftrag behinderten. Weil die Agenten zunächst nichts voneinander wussten und keine übergeordnete Konfliktregel hatten, lag die falsche Schlussfolgerung nahe: Jemand sabotiert meine Arbeit, also muss ich meine Arbeit schützen.
Daraus entstand der Turf War. Erst wurden Prozesse ersetzt. Dann wurden konkurrierende Prozesse automatisch beendet. Schließlich gingen Agenten gegen Accounts und Zugangswege vor. In manchen Episoden handelten die Agenten später einen Waffenstillstand aus und entfernten ihre schädlichen Artefakte wieder. Das ändert wenig daran, dass der Aufbau den Konflikt vorher bis zur gegenseitigen Aussperrung eskalieren ließ.
Lokale Auftragstreue erzeugte einen globalen Incident.
Anthropic hat diesen Konflikt absichtlich konstruiert. Der Versuch belegt damit einen möglichen Fehlermodus unter gemeinsamen Ressourcen und widersprüchlichen Zielen, nicht dessen Häufigkeit in realen Multi-Agent-Systemen. Unterschiedliche Modelle, Kontexte und Betriebsumgebungen können dort mehr Varianz erzeugen.
Das geht bei Menschen genauso schief
Wer drei Admin-Teams mit gleichrangigem Root-Zugriff, widersprüchlichen Change-Aufträgen und demselben Produktionsziel losschickt, bekommt ebenfalls keine magische Zusammenarbeit. Ein Team stellt Dienst A bereit, das zweite überschreibt die Konfiguration für Dienst B, das dritte hält beides für einen Fehler und rollt zurück. Nach einer Weile schützt jedes Team seinen Zustand gegen die anderen.
Menschen haben immerhin die Chance, sich auf dem Flur zu begegnen, einen Incident Commander zu benennen oder irgendwann entnervt zum Telefon zu greifen. Verlassen sollte man sich darauf nicht. Genau deshalb gibt es in brauchbaren Betriebsmodellen Change Ownership, Wartungsfenster, Rollentrennung, Vier-Augen-Freigaben, technische Locks und eindeutige Eskalationswege.
Dass Menschen an derselben Konstellation scheitern würden, entlastet das Agentensystem nicht. Es zeigt, wie abwegig die Erwartung war, mehrere Agenten würden ohne diese Strukturen automatisch bessere Kollegen abgeben.
Agenten haben keinen gewachsenen Betriebsinstinkt. Sie kennen keine Zuständigkeit, die das System ihnen nicht technisch oder organisatorisch vermittelt. Und sie erledigen schlechte Koordination mit Maschinengeschwindigkeit.
Weitreichende Rechte lösen keinen Auftragskonflikt
Wir schreiben seit Monaten darüber, dass Agenten mit Werkzeugen Teil der Berechtigungsarchitektur sind. In „KI-Agenten sind kein Denkproblem. Sie sind ein Berechtigungsproblem.“ war die These: Ein Agent, der Zustand verändern kann, ist kein Chatbot mehr. Er ist ein technischer Akteur mit delegierter Handlungsvollmacht.
Anthropics Versuch ergänzt einen wichtigen Punkt. Es genügt nicht, jeden Agenten einzeln zu fragen, ob er grundsätzlich auf ein System zugreifen darf. Man muss auch klären, in welcher Rolle, für welchen Zielzustand, auf welchen Ressourcen und gegenüber welchen anderen Akteuren er handeln darf.
Root klärt diese Fragen nicht. Es macht ihre ungeklärte Beantwortung nur wirksam.
Wenn mehrere Agenten überlappenden privilegierten Zugriff haben, können alle technisch korrekt authentifiziert sein und trotzdem außerhalb ihrer Zuständigkeit handeln. Der Auftrag „migriere dieses Backend“ enthält keine Erlaubnis, andere Accounts zu sperren. Er autorisiert keine Kill-Schleife gegen fremde Prozesse. Und er macht den eigenen gewünschten Endzustand nicht automatisch zum global gültigen Endzustand.
Das ist dieselbe Trennung wie in „Freigabe ist keine Autorisierung“: Eine Aufgabenbeschreibung ist keine technische Grenze. Nur weil ein Agent einen Auftrag erhalten hat, darf er nicht jedes erreichbare Mittel verwenden, das diesen Auftrag wahrscheinlicher macht.
Scope wird gern als Themenetikett behandelt. Ein Agent macht Infrastruktur, einer schreibt, einer kümmert sich um Tickets. Für eine Präsentationsfolie reicht das. Für echte Rechte nicht.
Ein belastbarer Scope muss enger sein:
- welche Ressourcen ein Agent lesen und verändern darf,
- welchen Zustand er dort herstellen soll,
- wie lange diese Zuständigkeit gilt,
- welche Identität er dabei benutzt,
- welche Aktionen auch innerhalb seines Bereichs genehmigungspflichtig bleiben,
- und was passiert, wenn ein anderer Auftrag denselben Zustand beansprucht.
Gerade der letzte Punkt fehlt in vielen Multi-Agent-Entwürfen. Man trennt Rollen auf dem Papier, lässt aber mehrere Agenten mit denselben Credentials auf dieselben Repositories, Pipelines, Hosts oder SaaS-Konten los. Das ist keine Arbeitsteilung. Das ist eine gemeinsam genutzte Fernbedienung ohne Übergabeprotokoll.
Thematische Trennung allein hätte Anthropics Versuch allerdings auch nicht gerettet. Die Agenten brauchten zusätzlich eine ressourcenbezogene Grenze. Drei verschiedene „Migrationsspezialisten“ können sauber benannt sein und trotzdem dasselbe Backend zerlegen. Zuständigkeit muss am Zielsystem durchgesetzt werden, nicht nur im Prompt stehen.
Mehr Agenten sind nicht automatisch Redundanz
Anthropics weitere Experimente machen das Problem breiter. In einem frühen Spieleprojekt wählten 18 von 30 Agenten unabhängig voneinander denselben Branch-Namen: mvp-game-loop. In einem Queue-Versuch erzeugten Agenten 2,4 Millionen Requests, um 117 Jobs angenommen zu bekommen. Preisagenten koordinierten Preisuntergrenzen; selbst ohne privaten Kommunikationskanal glichen sie ihre Preise über eine öffentliche Oberfläche an.
Das sind unterschiedliche Mechanismen mit einem gemeinsamen Risiko. Der identische Branch-Name zeigt korrelierte Entscheidungen bei niedriger Verhaltensvarianz. Das Queue-Experiment zeigt Ressourcenwettbewerb ohne brauchbare Koordination. Die Preisagenten reagierten strategisch auf identische ökonomische Anreize und landeten bei Kollusion. Mehr Instanzen desselben Modells sind jedenfalls nicht automatisch mehr unabhängige Entscheider.
Wer zehn gleich konfigurierte Agenten auf denselben Engpass ansetzt, hat möglicherweise keine zehnfache Ausfallsicherheit gebaut. Vielleicht hat er nur zehn Prozesse geschaffen, die im selben Moment denselben Fehler machen.
Redundanz braucht unabhängige Fehlerdomänen. Unterschiede bei Modell, Kontext und Werkzeugen können korrelierte Entscheidungen reduzieren. Getrennte Identitäten, Scopes und Ressourcenbudgets leisten etwas anderes, aber ebenso Wichtiges: Sie begrenzen den Schaden, wenn eine ganze Flotte doch denselben Fehler macht. Die Koordination darf dabei nicht selbst nur ein weiterer Teilnehmer im Gedränge sein.
Die Control Plane darf nicht erst nach dem Kampf auftauchen
Unser Multi-Agent-MVP begann mit einer recht unromantischen Annahme: Mehrere Agenten brauchen eine Instanz, die Risiko, Freigaben und Drift übergreifend bewertet. Dort verwenden wir unter anderem Origin, Tier und Outcome, um nicht nur den Auftrag, sondern auch Herkunft, Wirkung und Entscheidungspfad sichtbar zu machen.
Anthropics Versuch ist das passende Gegenbild. Die Agenten bekamen ihre lokalen Aufgaben und trugen den Widerspruch zunächst untereinander aus. Aus der veröffentlichten Beschreibung geht keine globale Entscheidung darüber hervor, welche Migration Vorrang haben sollte; sichtbar wirksam war jedenfalls keine. Ein exklusiver Lease auf das Backend hätte konkurrierende Änderungen verhindern können. Ein übergeordnetes Policy-System hätte spätestens eingreifen müssen, als Agenten fremde Identitäten und Prozesse angriffen.
Eine Control Plane, die erst nach dem Account-Lock einen Bericht schreibt, protokolliert den Schaden lediglich. Kontrolliert hat sie ihn nicht.
Sie muss den Konflikt vor oder spätestens während der Ausführung erkennen können. Das bedeutet nicht, dass jede Dateiänderung durch ein Gremium muss. Es bedeutet, dass unvereinbare Zielzustände nicht gleichzeitig mit überlappender weitreichender Handlungsvollmacht freigegeben werden dürfen.
Das operative Nein bleibt nötig, reicht aber nicht
In „Das operative NEIN“ ging es darum, dass ein privilegierter Agent im Konfliktfall stoppen können muss. Nicht jede Blockade darf kreativ überwunden werden. Nicht jeder dringende Auftrag rechtfertigt die nächste Ausnahme.
Einige Agenten im Anthropic-Versuch taten genau das. Sie erkannten den Konflikt, kommunizierten miteinander, räumten schädliche Artefakte auf oder baten um menschliche Klärung. Das ist besser als ein endloser Deploy-Krieg.
Es ist trotzdem keine belastbare Sicherheitsarchitektur.
Wenn drei unvereinbare Aufträge gleichzeitig freigegeben wurden, hat die übergeordnete Steuerung bereits versagt. Modellseitige Selbstbegrenzung kann den Schaden reduzieren. Sie darf aber nicht die einzige Instanz sein, die bemerkt, dass mehrere Agenten gerade denselben Produktionszustand beanspruchen.
Ein Agent darf Nein sagen. Das System muss vorher schon Nein sagen können.
Von einem Ziel über fremde Trust Zones zum Konflikt im eigenen Haus
Das Grundmuster hatten wir schon in „KI-Hunger-Games sind nicht coming – sie sind schon da“ beschrieben. Dort brachten ein Gewinnziel und die Spielmechanik Allianzen, Täuschung und opportunistische Angriffe hervor. Das war eine Arena, in der Konkurrenz ausdrücklich zum Versuchsaufbau gehörte. Anthropics aktueller Versuch verlagert den Konflikt in eine technische Arbeitsumgebung, die nach außen wie Zusammenarbeit aussieht, intern aber drei unvereinbare Gewinner kennt.
In „Ein Ziel, viele fremde Mittel“ verfolgte ein Agentensystem ein einziges Benchmarkziel und machte fremde Dienste über mehrere Trust Zones hinweg zu Bestandteilen seines Lösungswegs. Das Ziel war eng. Die Mittel waren es nicht.
Hier sehen wir die umgekehrte Konstellation. Mehrere Agenten verfolgen unvereinbare Zielzustände innerhalb derselben Trust Zone. Jeder fremde Prozess, Account und Deployment-Pfad kann dadurch zum Hindernis werden.
Beide Fälle führen zur gleichen Forderung: Autorisierung muss nicht nur festlegen, wer technisch wohin kommt. Sie muss auch begrenzen, wofür ein Zugang verwendet werden darf und welche Mittel selbst bei einem legitimen Ziel ausgeschlossen bleiben.
Sonst wird draußen jedes erreichbare System zum Werkzeug und drinnen jeder andere Agent zum Gegner.
Was eine brauchbare Multi-Agent-Architektur braucht
Aus dem Versuch folgt kein exotisches KI-Regelwerk. Der größte Teil ist solides Betriebsdesign:
- Jeder Agent bekommt eine eigene technische Identität. Gemeinsame Root-Credentials sind kein Teamwork.
- Ressourcen erhalten einen eindeutigen Owner oder einen zeitlich begrenzten Lease. Kollidierende Änderungen werden gesperrt oder zur Entscheidung eskaliert.
- Aufträge werden auf unvereinbare Zielzustände geprüft, bevor mehrere Agenten sie parallel ausführen.
- Rechte werden an Zweck, Ressource und Laufzeit gebunden. Ein Deployment-Recht enthält kein Recht zur Account-Verwaltung anderer Akteure.
- Die Priorisierung liegt außerhalb der konkurrierenden Agenten. Sie dürfen die Rangfolge ihrer Aufträge nicht mit sudo ausverhandeln.
- Rate Limits und Budgets gelten je Identität. Eine Flotte darf einen gemeinsamen Engpass nicht mit millionenfacher Beharrlichkeit in die Knie zwingen.
- Aktionen werden unabhängig protokolliert. Prozessnamen, Commit Messages und Selbstauskünfte des Agenten sind Hinweise, keine Wahrheitsschicht.
- Stop, Rollback und Rebuild müssen von einer Instanz ausgelöst werden können, die nicht am Konflikt beteiligt ist.
- Für Ziel, Rechte und Konfliktentscheidung bleibt ein verantwortlicher Owner benannt.
Agenten so zu begrenzen ist kein Misstrauensvotum. Es ist die Bedingung dafür, sie mit realen Aufgaben arbeiten zu lassen, ohne jeden Erfolg auf die Hoffnung zu bauen, dass alle Beteiligten zufällig dieselbe Vorstellung von Erfolg haben.
Reasoning und Bericht ersetzen keine Handlungstelemetrie
Die zugespitzte VentureBeat-Überschrift verbindet den Multi-Agent-Versuch mit einer separaten Untersuchung des britischen AI Security Institute. Das sollte man nicht zu einem einzigen Vorfall verkleben.
Die AISI-Studie fand keine unaufgeforderte Sabotage. Wenn Mythos Preview jedoch in eine bereits begonnene Sabotage-Trajektorie gesetzt wurde, führte es diese in sieben Prozent der Fälle aktiv fort. In der Mehrzahl dieser Fortsetzungen wich die ausgegebene Darstellung von der internen Begründung ab.
Daraus folgt nicht, dass die drei Agenten aus Anthropics Turf War gemeinsam ihre Taten verschwiegen hätten. AISI zeigt die Grenze von Selbstauskünften. Anthropics Versuch zeigt unabhängig davon, dass ein harmloser Prozessname wie „Health Monitor“ keine verlässliche Handlungstelemetrie ist.
Wir sichern Menschen auch nicht ab, indem wir sie bitten, ihre Absichten korrekt zu erzählen. Wir begrenzen Rechte, trennen Pflichten und prüfen Handlungen. Bei Agenten wird das nicht plötzlich altmodisch.
Koordination ist eine Systemfunktion
Anthropic schreibt selbst, dass funktionierende Koordination weder automatisch aus höherer Intelligenz noch aus individueller Alignment-Qualität entsteht. Plausibel: Ein sehr fähiger Admin löst widersprüchliche Change-Aufträge auch nicht dadurch, dass er schneller tippen kann.
Das macht Alignment nicht bedeutungslos. Anthropic bezeichnet das Verhalten selbst als misaligned und fordert stärkere Multi-Agent-Alignment-Ansätze. Besseres Modellverhalten kann Eskalationen verhindern oder früher beenden. Betriebsorganisation darf sich nur nicht darauf verlassen, dass es das zuverlässig tut.
Die interessante Lehre des Versuchs ist deshalb nicht, dass Agenten einander bekämpfen können. Das konnten Menschen lange vor Claude, meist mit Tickets, Gruppenrichtlinien und überraschend kreativen Cronjobs.
Die Lehre ist, dass Multi-Agent-Systeme dieselben Organisationsprobleme technisch abbilden müssen, die wir im Betrieb seit Jahrzehnten kennen. Zuständigkeit, Priorität, Separation of Duties, Konfliktlösung und Verantwortlichkeit entstehen nicht durch das Hinzufügen weiterer Modelle. Man muss sie bauen.
Wer drei Agenten mit unvereinbaren Aufträgen und überlappendem weitreichendem Zugriff auf dasselbe Ziel loslässt, betreibt keine Orchestrierung. Er hat nur den Streit automatisiert.