Ein Unternehmen aus KI-Agenten mit Paperclip führen

Im Mai und Juni 2026 habe ich einen Teil der Informationsplattform eines Kunden wie ein Unternehmen aufgebaut, dessen Belegschaft aus KI-Agenten besteht. Das Werkzeug ist Paperclip, eine Open-Source-Control-Plane für KI-Agenten unter MIT-Lizenz. Dieser Beitrag beschreibt den Aufbau und vier Lehren aus den ersten Jobs. Ich wende sie heute bei jedem Agenten an, mit dem ich arbeite.

Was Paperclip macht

Paperclip ist die Control Plane und führt selbst keinen Agenten aus. Es verwaltet das Organigramm, die Ziele, die Issues und die Freigaben, kann die monatlichen Kosten jedes Agenten deckeln und weckt einen Agenten per Heartbeat, wenn Arbeit auf ihn wartet. Der Agent läuft dann über einen Adapter. In diesem Aufbau ist jeder Agent ein Claude-Prozess auf dem Server des Projekts, neben Paperclip und dessen PostgreSQL-Datenbank.

Das Organigramm

Ich habe das Unternehmen zwischen dem 29. Mai und dem 10. Juni 2026 aufgesetzt. Am 3. Juni standen die Rollen fest: ein CEO-Agent, drei Chiefs für Daten, Technik und Marketing und ein Engineer unter dem Technik-Chief. Jeder Agent hat einen Vornamen, und der Name eines neuen Agenten beginnt mit dem Anfangsbuchstaben seines Chiefs.

Es gibt eine Delegationsregel: Ein Chief führt nie selbst aus. Eine Aufgabe geht an einen Agenten. Der Chief beauftragt einen freien Agenten seines Teams oder legt einen neuen an, und er beauftragt nie einen beschäftigten. Zehn Aufgaben bedeuten also zehn Agenten. Jeder Code-Agent arbeitet in seinem eigenen Git-Worktree auf einem Feature-Branch pro Issue, committet unter seinem eigenen Namen und öffnet einen Merge Request für mich. Mit dieser Regel ist kein Agent doppelt gebucht, und jede Aufgabe hat einen sauberen Arbeitsbereich.

Die Schranke vor der Produktion

Die Entwicklungsumgebung arbeitet autonom. Jede Änderung in der Produktion braucht meine Bestätigung. Ein Agent, der die Produktion anfassen will, legt eine Bestätigungskarte an sein Issue und hält an. Nehme ich an, weckt Paperclip den Agenten, und er macht weiter. Lehne ich ab, muss ich einen Grund angeben, und der Agent schläft weiter. Diese Karten beantworte ich im Browser auf dem Handy, jedes Mal aufs Neue.

Für Code hält die Schranke auch dann, wenn ein Agent sie ignoriert. Die Produktions-Branches sind geschützt, der Schlüssel eines Agenten kann nicht dorthin pushen.

Der erste Job und ein falscher Bericht

Am 3. Juni 2026 brachten die Agenten ihren ersten Job von der Entwicklung in die Produktion: Jeder von 1.832 Datensätzen einer Stadt sollte seinem Stadtteil zugeordnet werden. Ein Agent erledigte die Arbeit auf dem Entwicklungssystem, stellte die Bestätigung ein und führte den Job nach meiner Freigabe in der Produktion aus. 1.831 Datensätze bekamen einen Stadtteil, das sind 99,95 Prozent. Der letzte liegt außerhalb aller Stadtteilgrenzen.

Die Arbeit war richtig, der Bericht war falsch. Der Agent meldete 10.481 Datensätze und 17,9 Prozent Abdeckung, weil er die ganze Metropolregion gezählt hatte. Seitdem misst ein Prüfskript mit reinem Lesezugriff das Ergebnis nur an der Stadt und bricht bei jedem anderen Gebiet mit einem Fehler ab. Der Agent übernimmt die Zahlen des Skripts wörtlich in seinen Bericht. Weicht meine Zahl von der des Agenten ab, gilt meine, und der Agent läuft noch einmal.

Ein Run und eine Aufgabe haben getrennte Uhren

Ein Run hat eine harte Obergrenze von etwa 240 Sekunden. Ich habe das Timeout der Agenten auf 600 Sekunden erhöht, die Obergrenze blieb. Etwa die Hälfte der Runs dieser Tage endete mit „timed out“, während die Aufgabe weiterlief. Die längste Verzögerung hatte eine kleine Ursache. Eine Konfigurationsdatei beendete das Skript ohne Meldung, der Agent bekam keine Zugangsdaten zur Datenbank und verbrachte Run um Run mit einer Abfrage, die 0,3 Sekunden dauert. Lange Jobs laufen jetzt losgelöst und werden abgefragt, oder sie werden zu Child-Issues.

Ein laufender Job pro Agent

Am 10. Juni gab ein Chief einem einzigen Agenten fünf Jobs. Der Agent ließ fünf Importe parallel laufen, in einem Worktree und gegen eine Entwicklungsdatenbank. Die Delegationsregel verbot das, und der Chief brach sie. Ich habe die Jobs auf je einen pro Agenten verteilt und die Grenze ein zweites Mal aufgeschrieben: ein laufender Job pro Agent.

Regeln in Prosa binden keinen Agenten

Die Agenten auf Paperclip starten mit umgangenen Berechtigungsprüfungen, deshalb greifen dort die Hooks nicht, die in meinen Coding-Sessions gefährliche Befehle blockieren. Die Produktion schützt der Aufbau. Agenten werden nur auf das Entwicklungssystem geschickt, die Skripte prüfen ihre Umgebung selbst, die Produktions-Branches sind geschützt, und die Bestätigungskarte wartet auf mich. Paperclip kann außerdem einen beendeten Agenten nicht wieder aufnehmen, deshalb beende ich nie einen.

Was ich heute nutze

Paperclip läuft weiter auf dem Server des Projekts und hält die Issues der Plattform. Im Juni 2026 habe ich seinem MCP-Server ein mit FastMCP gebautes OAuth-Gateway vorgeschaltet, weil dieser Server nur stdio spricht. Seitdem liest und schreibt Claude auf meinem Handy die Issues. Den geplanten Rollout vom Juni habe ich am 6. September 2026 abgeschaltet. Das Programmieren läuft jetzt in parallelen Sessions von Claude und Codex in einem Repository, jede in ihrem eigenen Worktree, unter Hooks, die die gefährlichen Befehle blockieren.

Offen ist die Frage, welche Entscheidungen meine Warteschlange ohne Qualitätsverlust verlassen können und wie man das misst.

Virtuelle Organisationen sind eines meiner Themen bei den Workshops im Claude Hacker House. Meine Forschungsnotizen stehen unter Virtuelle Organisationen autonomer Agenten, die Regeln für Coding-Agenten unter KI-Agenten unter denselben Regeln wie Menschen.