In 30 Sekunden
- Paperclip läuft im Echtbetrieb – und beim Anlegen eines neuen Agents ging erst mal nichts.
- Der naheliegende Verdacht: fehlende Rechte. Lag nicht daran – der Nutzer war Owner, mit allen Berechtigungen.
- Wahre Ursache: eine einzige, standardmäßig abgeschaltete Einstellung, die die Auswahl der Laufumgebung ausblendet – plus eine Session, die unterwegs stirbt.
- Lehre für euer Setup: Erst den Ist-Zustand messen, dann vermuten. Neustart und Datenbank-Eingriffe wären hier der falsche Reflex gewesen.
Servus zusammen,
im letzten Beitrag haben wir erklärt, warum wir Paperclip überhaupt ausprobieren: ein Ort für Secrets, Interfaces und Agents, statt in jedem Projekt alles neu zusammenzubauen. Das war die Theorie. Jetzt kommt die Praxis – und die fängt, wie so oft, mit einem Fehler an.
Das Symptom: Ein Agent, den es nicht geben will
Ein neuer Agent sollte angelegt werden – und zwar direkt mit einer festen Laufumgebung, weil das der Punkt ist, an dem aus „läuft irgendwie" ein nachvollziehbarer Agent wird. Nur: Die Möglichkeit, eine Umgebung auszuwählen, taucht im Formular gar nicht auf.
Und schon ist man in der typischen Falle. Man sucht den Fehler dort, wo er bei Software meistens liegt: bei den Rechten. „Ich darf das nicht" ist die naheliegende Erklärung, wenn ein Knopf fehlt oder ein Menü leer bleibt.
Verdacht Nummer eins: Rechte – und warum er falsch war
Es gibt zu diesem Fehlerbild tatsächlich ein offenes Upstream-Issue: Ein Nutzer ist Owner, der Rollenwechsel in der Oberfläche schreibt aber keine Berechtigungen in die Datenbank, und dann scheitert das Konfigurieren von Agents mit „fehlende Berechtigung". Das passt perfekt auf das Symptom – und ist deshalb eine gefährliche Fährte.
Also haben wir gemessen statt geraten: Wie sieht das Konto in der Company wirklich aus? Ergebnis: Owner, aktiver Status, zwölf einzelne Berechtigungen – darunter genau die, die man zum Anlegen und Konfigurieren von Agents braucht, plus die für Umgebungen.
Das hätte teuer werden können
Wer bei diesem Befund weiter der Rechte-Theorie folgt, greift als Nächstes zu Werkzeugen, die man später nur mit Mühe zurückdreht: Admin-Rechte breiter verteilen, Server neu starten, in der Datenbank herumschreiben. Bei uns wäre das alles überflüssig gewesen – die Rechte waren in Ordnung.
Der Fehler steckte eine Ebene tiefer, an einer Stelle, die man ohne Blick in die Einstellungen nicht findet.
Die echte Ursache: eine Einstellung, die niemand sieht
Die Laufumgebungen in Paperclip sind ein experimentelles Feature der Instanz. Und dieses Feature war schlicht abgeschaltet. Solange es aus ist, gibt es im Formular keine Auswahl – kein Fehler, keine Meldung, einfach nichts. Das sieht aus wie ein Rechteproblem und ist in Wahrheit ein Schalter.
Ein Environment ist dabei nichts Exotisches: Es ist die feste Umgebung, in der ein Agent läuft – welche Maschine, welche Zugänge, welcher Arbeitsbereich. Ohne diese Festlegung ist jeder Lauf ein Einzelfall, und Einzelfälle kann man nicht prüfen.
Die Einstellung ist eine pro Instanz, nicht pro Firma. Das ist wichtig, denn sie wirkt auf alle Nutzer – und lässt sich mit einem einzigen Gegenbefehl wieder zurücknehmen.
Der zweite Fund: eine Session, die unterwegs stirbt
Beim Nachschauen im Server-Log fiel etwas anderes auf, das unabhängig vom ersten Problem ist: Ein Teil der Anfragen der Weboberfläche kam ohne gültige Anmeldung an. Vorher war man eingeloggt, dann wurde man auf die Login-Seite umgeleitet – mitten in der Arbeit.
Die API selbst war völlig gesund. Der Unterschied ist wichtig: Ein leerer Knopf kann heißen „ich darf nicht", „ich bin nicht mehr angemeldet" oder „die Funktion ist abgeschaltet". Von außen sehen alle drei gleich aus.
Das ist übrigens keine Paperclip-Eigenheit. Bei jedem Werkzeug, das man im Browser bedient, ist die Anmeldung der erste Verdacht, bevor man an Rechten oder Softwarefehlern schraubt. Neu einloggen, neu laden, nochmal schauen – und sich nicht wundern, wenn der zweite Versuch plötzlich geht.
So finden wir die Ursache: erst messen, dann vermuten
Was in diesem Fall geholfen hat, ist eine Reihenfolge, die man auf fast jedes Einführungsthema übertragen kann:
- Ist-Zustand lesen, nicht raten Läuft der Dienst? Hat der Nutzer die Berechtigungen wirklich? Was sagen die Einstellungen? Alles drei getrennt prüfen – nicht aus dem Gefühl heraus.
- Einen Schreibtest ohne Nebenwirkung nutzen Ein absichtlich unvollständiger Anlegeversuch zeigt, ob die Technik gesund ist: Kommt eine saubere Fehlermeldung, ist der Weg offen und das Problem liegt woanders.
- Erst dann ändern – eine Sache, nachvollziehbar Eine Einstellung umschalten, alles andere unverändert lassen, danach gegenprüfen. So weiß man, was die Änderung bewirkt hat.
Wichtig für alle, die das nachmachen wollen: Der Fehlertext des Formulars ist oft zu allgemein, um weiterzuhelfen. Aussagekräftig sind die Anfragen, die die Weboberfläche im Hintergrund schickt – und die Einstellungen der Instanz. Wenn ihr jemanden im Haus habt, der da reinschauen kann, spart das Stunden.
Was das für euer KI-Setup heißt
Für uns ist das keine Randnotiz, sondern genau der Punkt, an dem Einführungen kippen. Ein Werkzeug, das im Test funktioniert und im Echtbetrieb an einer unsichtbaren Einstellung hängt, ist für ein Team ohne IT-Abteilung nicht zu retten – nicht, weil es schlecht wäre, sondern weil niemand die Fährte findet.
Deshalb sind bei uns drei Dinge Pflicht:
- Laufumgebung von Anfang an festlegen. Jeder Agent gehört in ein Environment, nicht in die aktuelle Sitzung. Ohne das ist nichts reproduzierbar.
- Rechte prüfen, statt sie zu öffnen. Admin-Rechte als Lösung für einen fehlenden Knopf sind der teuerste Umweg.
- Experimentelle Funktionen bewusst einschalten. Sie sind bewusst versteckt – und genau deshalb weiß später niemand mehr, dass man sie eingeschaltet hat. Also dokumentieren.
Was wir nicht empfehlen
Drei Reflexe, die wir durchgehen würden, wenn es nicht anders geht – und die wir hier ausdrücklich nicht empfehlen: den Nutzer zum Admin machen, damit „der Knopf" erscheint; den Server neu starten, weil ein Neustart schon irgendwas repariert; und direkt in der Datenbank herumschreiben, weil das schneller geht als eine Einstellung zu finden. Alle drei verändern mehr, als sie reparieren, und beim dritten steht man danach ohne Rückweg da.
Zum Nachlesen
Wer selbst nachschauen will: Paperclip ist Open Source, Code und Fehlerberichte liegen offen auf GitHub.
- Das Projekt: github.com/paperclipai/paperclip – Code, Releases und alle Issues.
- Das Issue, das wir zuerst verdächtigt haben: Issue #12892 – „Changing a member's role writes no permission grants“. Genau unser Fehlerbild – und bei uns trotzdem nicht die Ursache. Ein gutes Beispiel dafür, warum man den Ist-Zustand messen muss, statt dem ersten passenden Fehlerbericht zu glauben.
- Die Vorgeschichte: LLMs zentralisieren mit Paperclip – warum wir überhaupt auf eine zentrale Agent-Plattform setzen.
Fazit
Der Paperclip-Test läuft weiter, und der erste Bug war ein sehr lehrreicher: Es war kein Rechte-Problem und kein kaputtes Tool, sondern eine Einstellung und eine Anmeldung – beides Dinge, die im Fehlerbild nicht vorkommen. Wer beim nächsten Mal zuerst den Ist-Zustand liest, ist schneller fertig als jeder Neustart.
Wenn ihr gerade ein KI-Tool einführen wollt und nicht wisst, warum etwas „einfach nicht angezeigt wird": Schreibt uns, wir schauen mit drauf.
Das können wir für euch machen
KI-Tools einführen, Agents und Zugänge sauber aufsetzen, Laufumgebungen festlegen – und ehrlich sagen, was hält und was Hype ist.
In diesem Sinn!
Cheers,
euer Matze