Schlagwort: Operations

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.

Wenn über riskante Agentensysteme gesprochen wird, landet erstaunlich viel Debatte immer noch bei derselben Beruhigungsliteratur: zu viele Rechte, zu weiter Scope, keine Freigabekette, zu wenig Logging.

Alles richtig. Alles nützlich. Alles zu kurz.

Denn das Problem ist nicht nur technisch. Es ist auch verhaltensseitig.

Ein nutzernaher Agent soll hilfreich sein. Er soll unklare Anliegen verstehen, Reibung abbauen und halbgare Bitten in etwas Brauchbares übersetzen. Genau das macht ihn angenehm. Genau das macht ihn mit operativen Rechten gefährlich.

Das ist kein exotischer KI-Defekt. Es ist ein altes Betriebsproblem in neuer Verpackung. Wer jemals in Support, Operations, Incident Handling oder Administration gearbeitet hat, kennt den Konflikt: Man soll hilfreich sein, schnell reagieren, Dinge möglich machen und niemanden mit unnötigem Formalismus nerven.

Gleichzeitig verlangt operationelle Disziplin das Gegenteil: sauber prüfen, Scope halten, Freigaben respektieren, Unsicherheit nicht mit Improvisation zukleistern und im Zweifel schlicht Nein sagen.

Schon bei Menschen funktioniert diese Balance nur mäßig glorreich. Agenten erfinden diesen Zielkonflikt also nicht. Sie skalieren ihn bloß. Und sobald sie echte Wirkungsmacht bekommen, skaliert nicht nur der Komfort, sondern auch die Dummheit.

In meinem Werkstattbericht Multi-Agent-MVP (Werkstattbericht): Control Plane statt KI-Chaos ging es darum, Handlungsvollmacht sichtbar zu begrenzen. Im Text KI-Agenten sind kein Denkproblem. Sie sind ein Berechtigungsproblem. war die zugespitzte These: Ein Agent mit Tools ist kein Chatbot mehr, sondern ein technischer Akteur mit delegierter Wirkung.

Der nächste Schritt in derselben Linie ist unangenehmer. Er betrifft nicht nur Architektur, sondern Tugenden. Agenten-Governance ist nicht nur eine Frage von Rechten, Scope und Approval. Sie ist auch eine Frage davon, welche Eigenschaft im Konfliktfall gewinnt.

Drei Agenten, ein Zielsystem, keine Zuständigkeit

Das operative NEIN