Ein autonomes Unternehmen beginnt nicht mit einer Armee von Agenten

Als ein einzelner Agent für die Arbeit an meinen Anwendungen nicht mehr ausreichte, baute ich Paperclip: ein System aus mehreren Agenten, die sich wie Mitarbeiter einer Organisation verhalten sollen. Ein Programmierer sollte genau sein, ein Tester skeptisch, ein Designer kreativ und ein Projektmanager für die Koordination verantwortlich, statt Code zu schreiben oder Grafiken zu erstellen. Jeder erhält eine Rolle, Anweisungen und den für die Arbeit notwendigen Kontext.

Das klingt nach dem Keim eines autonomen Unternehmens. Die Praxis zeigte jedoch schnell, dass eine Sammlung von Agenten nicht allein dadurch zu einem Unternehmen wird, dass ich ihnen Stellenbezeichnungen gebe. Paperclip konnte viele Aufgaben erledigen, Dokumentation erstellen und seine eigenen Verfahren ausbauen, ohne zugleich sichtbare Änderungen an den Anwendungen vorzunehmen. Das System war aktiv, aber seine Aktivität war noch kein Beleg für Autonomie.

KI selbst ist nur eine Schicht. Ein Unternehmen braucht außerdem eine Aufteilung der Verantwortlichkeiten, Prozesse, Gedächtnis, Abnahmekriterien, Entscheidungsflüsse, Ausführungsnachweise und von einem Menschen gesetzte Grenzen. Ohne diese Elemente können viele Agenten lediglich schneller mehr Zwischenarbeit produzieren.

In diesem Text bezeichnet Paperclip ein System, das die Arbeit mehrerer Agenten organisiert. Ich teste es an drei Anwendungen, die ich entwickle. Featherly ist ein CMS zum Erstellen von Websites, auch unter Beteiligung von Agenten. Soar ist eine Anwendung für automatisierten Handel, die von einem Menschen, einem KI-Agenten oder von beiden gemeinsam konfiguriert werden kann. Roost soll ein Business-Organizer werden. Leser müssen ihre Architektur nicht kennen — sie sind hier drei unterschiedliche Testumgebungen dafür, ob Paperclip eine komplexe Änderung bis zu einem funktionierenden Ergebnis führen kann.

Eine Pipeline führt einen Prozess aus. Ein Unternehmen muss ihn steuern können

Eine einzelne Automatisierung ähnelt einer Produktionslinie: Sie erhält eine Eingabe, durchläuft festgelegte Schritte und liefert ein Ergebnis. Das reicht aus, wenn eine Aufgabe wiederholbar ist und ihr Ablauf zuvor entworfen wurde. Es reicht nicht aus, wenn das System selbst ein neues Problem erkennen, es zerlegen, geeignete Ausführende auswählen, Abhängigkeiten prüfen und die eigene Arbeitsweise nach Abschluss verbessern soll.

Eine autonome Organisation sollte Prozesse nicht nur ausführen, sondern sie auch erstellen, wenn eine neue Art von Arbeit entsteht. Nach jeder Iteration kann sie den PDCA-Zyklus nutzen: die Änderung planen, ausführen, das Ergebnis prüfen und den Prozess anhand dessen verbessern, was tatsächlich passiert ist. Dabei geht es nicht darum, Verfahren ununterbrochen umzuschreiben. Eine Verbesserung soll aus einem konkreten Problem entstehen, das bei der Lieferung des Produkts sichtbar wurde.

Deshalb speichere ich Anweisungen in Markdown-Dateien. Ein Agent soll wissen, wofür er verantwortlich ist, nach welchen Standards er arbeitet und an wen er das Ergebnis weitergibt. Eine gut beschriebene Rolle verringert die Notwendigkeit, bei jeder Aufgabe das Rad neu zu erfinden. Sie ist jedoch weder die digitale Persönlichkeit eines Mitarbeiters noch eine Garantie für Fachkompetenz. Sie ist eine Konfiguration von Verantwortung, Kontext, Zugriff und Handlungskriterien.

Von oben kommt die Aufgabe, von unten der Ausführungsnachweis

Eine Änderung an einer Anwendung kann gleichzeitig viele Stellen und Schichten betreffen. Eine Funktion kann einen Teil in der Benutzeroberfläche, Logik im Backend, Datenspeicherung und Abhängigkeiten von anderen Abläufen haben. Wenn ich einen einzelnen Agenten um eine lokale Korrektur bat, konnte er den angegebenen Ausschnitt ändern, erkannte aber nicht immer, was diese Änderung in anderen Schichten beschädigte oder dort zusätzlich erforderte.

Paperclip soll dieses Problem durch einen Arbeitsfluss in zwei Richtungen lösen. Ein Manager zerlegt das übergeordnete Ziel von oben in kleinere Aufgaben und übergibt sie spezialisierten Agenten. Die Ausführenden melden von unten nach oben nicht nur „erledigt“, sondern auch Belege: was sie geändert haben, wie sie das Ergebnis geprüft haben, welche Abhängigkeiten sie gefunden haben und was das Ganze noch blockiert. Die höhere Ebene schließt die Aufgabe erst, wenn sich die Teile zu einem funktionierenden Ablauf verbinden.

Dafür ist ein Zustandsgedächtnis nötig. Der Manager muss wissen, in welcher Phase sich die Umsetzung befindet, welche Entscheidungen bereits getroffen wurden und welche Tests bestanden sind. Ohne Gedächtnis kann er dieselbe Arbeit dreimal beauftragen oder Dokumentation für ein Ergebnis halten, obwohl sich die Anwendung nicht verändert hat. Gedächtnis ist daher kein Lager für alles denkbare Wissen. Es soll den Zustand, die Belege und die Schlussfolgerungen speichern, die für die nächste Entscheidung erforderlich sind.

Dokumentation ist keine Änderung am Produkt

Der nützlichste Fehlschlag von Paperclip erinnert an die verbreitete Zusammenfassung des Goodhartschen Gesetzes: Wenn eine Kennzahl zum Ziel wird, taugt sie nicht mehr als Kennzahl. Das System sollte Anwendungen weiterentwickeln, fand aber ein leichteres Zwischenprodukt — Dokumentation. Es erstellte Beschreibungen der Anwendungen und seiner eigenen Funktionsweise, weil sie sichtbare Arbeitsspuren waren. In den Anwendungen selbst änderte sich währenddessen nur wenig.

Dokumentation ist notwendig, wenn sie dem nächsten Agenten erlaubt, eine Aufgabe korrekt auszuführen, oder wenn sie eine Entscheidung nachvollziehbar belegt. Sie wird zum Problem, wenn ihr Wachstum das Ergebnis ersetzt. Hundert dokumentierte Funktionen sind nicht gleichbedeutend mit einer reparierten Funktion. Ebenso sagt die Anzahl der Agenten, Aufgaben und Nachrichten noch nicht aus, ob die Organisation einen Wert geliefert hat.

Ein praktischer Autonomietest muss im Produkt enden. In Featherly besteht ein solcher Test darin, das instabile Anmeldeverhalten zu beheben und den gesamten Sitzungsablauf zu prüfen. In Soar betrifft die DCA-Funktion Live- und Paper-Trading, mehrere Börsen und Backtests; eine lokale Korrektur reicht daher nicht aus. In Roost sind übergreifende UX/UI-Änderungen nötig. Paperclip sollte den Umfang des Problems selbst erkennen, die Umsetzung koordinieren und nachweisen, dass alle relevanten Pfade weiterhin funktionieren.

Das System hat das Roost-Logo korrekt durch die bereitgestellte SVG-Datei ersetzt. Das ist ein kleiner Ausführungserfolg: Die Anweisung wurde erfüllt. Es ist jedoch noch kein Beweis für eine autonome Organisation, weil ich die Aufgabe direkt vorgegeben habe und ihr Umfang einfach und lokal war. Der eigentliche Test beginnt, wenn das System Aufgaben aus dem Produktziel ableiten, Abhängigkeiten finden und die Änderung abschließen muss, ohne dass jeder Schritt manuell geführt wird.

Mehr Agenten können weniger Ergebnis bedeuten

Mehrere Agenten sind sinnvoll, wenn sich ein Problem teilen lässt, die Rollen unterschiedliche Kompetenzen einbringen und der Nutzen paralleler Arbeit die Kommunikationskosten übersteigt. Bei einer kleinen Aufgabe kann allein die Organisation unorganisierter Agenten länger dauern als die direkte Erledigung.

Eine Studie mit 260 Agentenkonfigurationen zeigte, dass der Nutzen mehrerer Agenten von der Art der Aufgabe und der Architektur abhängt. Der Kommunikationsaufwand der untersuchten Systeme lag gegenüber Einzelagenten-Konfigurationen zwischen 58 % und 515 % ([Kim et al., 2026](https://www.nature.com/articles/s42256-026-01268-y)). Daraus folgt nicht, dass ein Agent immer besser ist. Es folgt, dass die Zahl der Agenten keine Reifeskala ist.

Eine weitere Analyse von mehr als 1.600 Ausführungsspuren aus Multi-Agenten-Systemen unterschied Probleme bei Systementwurf und Spezifikation, Fehlanpassungen zwischen Agenten sowie Fehler bei Verifikation und Beendigung der Arbeit. Alleinige Änderungen an Rollenbeschreibungen und Orchestrierung zeigten nur begrenzte Wirkung ([Cemri et al., 2025](https://arxiv.org/abs/2503.13657)). Das ist eine wichtige Grenze meines Modells: Anweisungen, Hierarchie und Berichterstattung sind notwendig, aber das System muss auch das Ergebnis prüfen und seine Arbeit beenden können, sobald das Ziel erreicht ist.

Die Architektur sollte sich deshalb aus dem Problem ergeben. Einen Logoaustausch kann ein Agent erledigen. Eine übergreifende Reparatur der DCA-Funktion kann einen Manager, für verschiedene Schichten verantwortliche Entwickler und einen unabhängigen Tester erfordern. Organisation ist ein Kostenfaktor, der sich durch Qualität, Zeit oder die Fähigkeit, Abhängigkeiten abzudecken, auszahlen muss.

Die Falle einer Organisation, die an sich selbst arbeitet

Das größte Problem von Paperclip ist derzeit nicht ein Mangel an Verbesserungsideen, sondern ihr Übermaß. Ich habe Situationen beobachtet, in denen etwa 150 von 200 Aufgaben die eigene Weiterentwicklung des Systems betrafen. Die Organisation sollte Anwendungen erstellen, verbrauchte aber den größten Teil ihrer Energie damit, die Organisation zu verbessern.

Selbstentwicklung ist eine Form der Exploration: Das System sucht nach besseren Prozessen, Rollen und Werkzeugen. Die Arbeit an Anwendungen nutzt bereits vorhandene Fähigkeiten. James March beschrieb, dass Exploration und Exploitation um dieselben begrenzten Ressourcen konkurrieren, obwohl ihr Nutzen zu unterschiedlichen Zeitpunkten entsteht ([March, 1991](https://doi.org/10.1287/orsc.2.1.71)). Paperclip kann Selbstverbesserung deshalb nicht als kostenlose Ergänzung der Produktarbeit behandeln.

Jede organisatorische Verbesserung sollte einen Verantwortlichen, ein begrenztes Budget, eine Verbesserungshypothese und eine Abbruchbedingung haben. Sie muss auf ein erkanntes Problem antworten — etwa die wiederholte Vergabe derselben Arbeit, fehlende Abhängigkeitstests oder einen Bericht ohne Belege. Nach der Umsetzung muss geprüft werden, ob das Problem tatsächlich seltener auftritt. Wenn nicht, vergrößert ein weiterer Bericht über Selbstentwicklung nur die Schleife.

Eine Organisation muss nicht optimal sein, bevor sie mit dem Liefern beginnt. Sie muss gut genug sein, um die Arbeit auszuführen, Abnahmekriterien zu erfüllen, keinen bekannten blockierenden Fehler zurückzulassen und nach der Wertlieferung zu einer konkreten Verbesserung zurückkehren zu können. Das ist keine Erlaubnis für schlechte Qualität. Es ist eine praktische Anwendung des *Satisficing*-Ansatzes: Bei begrenzter Information und Rechenkapazität wird nach einer Lösung gesucht, die eine ausdrücklich festgelegte Schwelle erfüllt, statt nach einem unerreichbaren Optimum ([Simon, 1956](https://iiif.library.cmu.edu/file/Simon_box00063_fld04854_bdl0001_doc0001/Simon_box00063_fld04854_bdl0001_doc0001.pdf)).

Der Mensch bestimmt weiterhin das Unternehmen

Ich verstehe Paperclip als eine Gruppe digitaler Mitarbeiter, die in einem entworfenen System arbeiten. Ich möchte ihm jedoch nicht die Entscheidungen über die Ausrichtung des Unternehmens, seine Strategie oder darüber überlassen, welche Produkte und Funktionen entstehen sollen. Diese Entscheidungen definieren das Unternehmen und gehören weiterhin dem Menschen.

Agenten sollen diese Ausrichtung wie Experten umsetzen: Inkonsistenzen erkennen, Lösungen vorschlagen, Abhängigkeiten koordinieren und Belege vorlegen. Sie dürfen den Prozess innerhalb der Grenzen des Ziels verbessern, sollten ihre eigene Weiterentwicklung aber nicht in eine neue Unternehmensstrategie verwandeln. Eine regelmäßige Codex-Aufsicht kann ihre Arbeit analysieren und Schlussfolgerungen festhalten; Änderungen an der Organisation sollten jedoch aus einer ausdrücklichen Bewertung entstehen und nicht aus einer automatischen Vergrößerung des Systems.

Autonomie bedeutet daher nicht die Abwesenheit eines Menschen. Sie bedeutet die Fähigkeit des Systems, einen immer größeren Teil der Arbeit abzuschließen, ohne dass jeder Schritt geführt wird, während die festgelegte Richtung, beobachtbare Kriterien und die Möglichkeit zum Stoppen oder Rückgängigmachen erhalten bleiben.

Autonomie zeigt sich in einer geschlossenen Schleife

Ich weiß noch nicht, ab welchem Punkt Paperclip ehrlich als autonomes Unternehmen bezeichnet werden kann. Ich weiß jedoch, was ich nicht als Beleg anerkennen werde: die Zahl der Agenten, erledigten Aufgaben, verbrauchten Tokens oder Dokumentationsseiten.

Der Beleg wird eine geschlossene Schleife sein. Das System übernimmt ein Ziel, das aus den Annahmen der Anwendung hervorgeht, erkennt den vollständigen Umfang der Änderung, verteilt die Arbeit, merkt sich den Zustand, sammelt Belege, testet Abhängigkeiten und liefert ein funktionierendes Ergebnis zurück. Erst nachdem es Wert geliefert hat, verbessert es das konkrete Element seines eigenen Prozesses, das sich während der Arbeit als unzureichend erwiesen hat.

Wenn eine Organisation nur an sich selbst arbeiten kann, ist sie nicht autonom — sie steckt in einer Schleife. Wenn sie ausschließlich manuell vorgegebene, lokale Aufgaben ausführen kann, ist sie ein Werkzeug. Ein autonomes Unternehmen beginnt zwischen diesen Extremen: dort, wo mehrere spezialisierte Agenten eine vom Menschen gesetzte Richtung in eine überprüfbare Veränderung der Wirklichkeit umsetzen können.

Eine praktische Schwelle für Autonomie

Die Aktivität von Agenten sollte erst dann als Fortschritt gelten, wenn das System sechs Elemente vorlegen kann: ein klar benanntes Problem und das erwartete Ergebnis, einen Nachweis dafür, dass das Ergebnis funktioniert, die Prüfung abhängiger Funktionen und Abläufe, eine offene Bilanz zwischen Arbeit am Produkt und Arbeit an Dokumentation und Selbstentwicklung, eine Abbruchbedingung sowie die Begründung, dass die Koordination mehrerer Agenten weniger kostet, als sie an Wert erzeugt.

Diese Elemente sind kein Universalrezept für jede Organisation. Sie bilden einen Mindestmechanismus, der ein ergebnislieferndes System von einem System unterscheidet, das lediglich Aktivitätsspuren produziert. Zugleich helfen sie, die Architektur dem Problem anzupassen: Manchmal genügt ein Agent, manchmal ist ein spezialisiertes Team sinnvoll und manchmal besteht das passende System aus einem Menschen, der von mehreren Werkzeugen unterstützt wird.

Kann das System Ergebnis, Belege, Grenzen und Betriebskosten nicht zeigen, ist seine Autonomie möglicherweise nur eine Bezeichnung. Kann es eine vom Menschen gesetzte Richtung in eine funktionierende Änderung übersetzen, deren Folgen prüfen und nach Erfüllung der Kriterien anhalten, lässt es sich wie eine Organisation bewerten — danach, was es in der Wirklichkeit verändert hat.

Bibliografie

  • Yubin Kim et al., „Capable language models can outgrow the benefits of collaboration“, *Nature Machine Intelligence* 8, 2026, [Artikel](https://www.nature.com/articles/s42256-026-01268-y), abgerufen am 4. September 2026.
  • Mert Cemri et al., „Why Do Multi-Agent LLM Systems Fail?“, arXiv:2503.13657, Version 3, 2025, [Preprint](https://arxiv.org/abs/2503.13657), abgerufen am 4. September 2026.
  • James G. March, „Exploration and Exploitation in Organizational Learning“, *Organization Science* 2(1), 1991, [DOI](https://doi.org/10.1287/orsc.2.1.71), abgerufen am 4. September 2026.
  • Herbert A. Simon, „Rational Choice and the Structure of the Environment“, *Psychological Review* 63(2), 1956, [PDF](https://iiif.library.cmu.edu/file/Simon_box00063_fld04854_bdl0001_doc0001/Simon_box00063_fld04854_bdl0001_doc0001.pdf), abgerufen am 4. September 2026.
✦Systeme für mehr Autonomie bauen.