Gehalt in Token

Jeder unserer Kollegen bekommt ein Gehalt. Es wird nicht in Euro ausgezahlt, sondern in Rechenbudget: eine monatliche Obergrenze für das, was er an Modellaufrufen verbrauchen darf. Mit Alarm bei 80 Prozent und Drosselung bei 100.

Das ist die Metapher, über die am häufigsten gelacht wird. Sie ist die einzige in diesem ganzen Projekt, die sich innerhalb weniger Tage bezahlt gemacht hat.

Was passiert, wenn man das nicht macht

An einem einzigen Tag hat unsere Belegschaft ohne jede böse Absicht das gesamte verfügbare Guthaben aufgebraucht. Nicht durch eine große Aufgabe. Durch eine Kaskade von Rückfragen.

Der Ablauf war ungefähr so: Ein Kollege stößt auf eine Unklarheit und fragt einen anderen. Der antwortet und stellt dabei selbst eine Rückfrage an einen Dritten. Der Dritte findet die Frage berechtigt und holt zwei Meinungen ein. Jede dieser Fragen ist einzeln vernünftig. Jede kostet Geld. Und weil jede Antwort neue Fragen erzeugen kann, wächst das Ganze nicht linear.

Am Ende des Tages stand eine dreistellige Zahl an Vorgängen, ein leeres Konto und — das ist der eigentlich bittere Teil — kein verwertbares Ergebnis.

Bei Menschen begrenzt sich so etwas von selbst, weil niemand Lust hat, dreißig Fragen zu beantworten. Bei Agenten begrenzt sich nichts von selbst. Deshalb ist die Kostenstelle keine Metapher, sondern eine Sicherung.

Wie die Vergütung aufgebaut ist

Es gibt drei Modellklassen. Einfache, klar geregelte Arbeit läuft auf der billigsten. Die solide Facharbeit in der Mitte. Urteilsfragen, Orchestrierung und komplexe Prüfarbeit auf der teuersten.

Und dann gibt es eine Regel, die ich für die wichtigste in diesem Bereich halte:

Jeder Kollege startet auf der billigsten Klasse. Ausnahmslos, unabhängig davon, wo er einmal landen soll. Ein besseres Modell ist ein Bonus nach bestandener Probezeit, kein Startgeschenk.

Der Grund ist nicht Geiz. Es ist die Erfahrung, dass ein größeres Modell erstaunlich oft eine schlechte Aufgabenbeschreibung kaschiert. Wer mit dem kleinen anfängt, merkt sofort, wo seine Anweisung unpräzise ist — beim großen fällt es erst auf, wenn die Rechnung kommt.

Boni sind bei uns übrigens nicht ausschließlich Modell-Upgrades. Es gibt auch mehr Gedächtnis, Zugriff auf zusätzliche Werkzeuge, ein höheres Budget oder eine Weiterbildung im Sinne besserer Vorlagen und Beispiele. Das ist keine Verniedlichung: Es sind exakt die Stellschrauben, an denen die Leistung eines solchen Systems tatsächlich hängt.

Der Malus — und die Ausnahme, die zählt

Es gibt auch den umgekehrten Weg: Nachschärfen, dann ein Verbesserungsplan, dann Rückstufung, dann Trennung. Auch das ist aus dem Personalwesen übernommen, und zwar bewusst mit Stufen — nicht, weil ein Agent das braucht, sondern weil abgestufte Reaktionen uns zwingen, den Fehler erst zu verstehen, bevor wir das System austauschen.

Wichtiger ist die Ausnahme: Widerspruch, Eskalation und ein ehrliches „weiß ich nicht" führen niemals zu einer schlechteren Bewertung.

Das ist die Stelle, an der so ein System kippt oder hält. Wenn Nichtwissen bestraft wird, wird geraten. Und geraten wird bei Sprachmodellen nicht sichtbar, sondern in Form einer flüssigen, überzeugenden, falschen Antwort. Ein „weiß ich nicht" ist die billigste gute Nachricht, die man bekommen kann.

Warum die Beschränkung selbst der Punkt ist

In unserem Regelwerk steht ein Satz, der etwas altmodisch klingt: Beschränkung macht kreativ. Konkret heißt das: kein Prototyp teurer als 150 Euro, und das Modell so klein wie möglich.

Ich habe lange genug in Projekten gearbeitet, um zu wissen, wie das Gegenteil aussieht. Ein großzügiges Budget ersetzt die Denkarbeit — man probiert, statt zu entscheiden. Eine harte Obergrenze zwingt zu der Frage, die am Anfang stehen müsste: Was genau soll hier eigentlich herauskommen?

Es gibt dazu eine Messung, die ich sehr aufschlussreich fand. Anthropic berichtet aus dem eigenen Vielagenten-System, dass der zur Verfügung stehende Token-Umfang rund 80 Prozent der Leistungsunterschiede erklärt. Das heißt in beide Richtungen etwas: Mehr Budget bringt tatsächlich mehr Ergebnis — und gleichzeitig ist Budget der teuerste Weg, ein Problem zu lösen, das man auch durch eine schärfere Aufgabenstellung lösen könnte.

Zwei Fehler, die Geld gekostet haben

Der erste: Null hieß unbegrenzt.

In der Personalakte steht ein Budget. Wer noch keins zugewiesen bekommen hatte, stand auf null. Und die Prüfung im Programm lautete sinngemäß: Wenn ein Budget gesetzt ist, halte dich daran. Null ist kein gesetztes Budget. Also galt für jeden Kollegen ohne zugewiesenes Budget: keine Obergrenze.

Genau falsch herum. Der Zustand „ich habe für dich noch nichts festgelegt" bedeutete in der Praxis „nimm dir, was du brauchst" — bei genau den Kollegen, die am wenigsten eingerichtet waren.

Heute heißt null: darf nicht arbeiten. Wer kein Budget hat, bekommt keine Aufgaben. Das ist die sichere Richtung: Im Zweifel steht jemand still, statt dass jemand unbemerkt Geld ausgibt.

Der zweite: ein Kollege gab eine Aufgabe an sich selbst weiter.

Ein Agent zog eine Aufgabe aus seiner Liste, stellte fest, dass sie eigentlich zu ihm gehörte, und übergab sie — an sich. Damit stand sie wieder auf „offen", er zog sie erneut, übergab sie erneut, und so weiter.

Das ist eine perfekte Schleife, und sie ist teuer, weil jede Runde einen Modellaufruf kostet. Sie sieht in den Protokollen auch nicht nach einem Fehler aus, sondern nach einem sehr fleißigen Mitarbeiter.

Die Plattform weist eine Übergabe an sich selbst inzwischen ab.

Was ich aus beiden mitnehme: Die teuren Fehler in so einem System sind keine Abstürze. Ein Absturz fällt auf. Teuer sind die Zustände, in denen alles weiterläuft und aussieht wie Arbeit — eine fehlende Obergrenze, eine Schleife, eine Kaskade. Deshalb ist die wichtigste Frage bei jeder Regel nicht „was passiert, wenn sie greift?", sondern „was passiert, wenn das Feld leer ist?"

Was wir daraus gemacht haben

Nach dem Tag mit dem leeren Konto gibt es drei zusätzliche Sicherungen: eine Obergrenze pro Kollege und Tag, eine Begrenzung, wie viele Aufgaben ein Kollege pro Stunde annehmen darf, und eine maximale Tiefe für Rückfragen-Ketten — nach der zweiten Ebene ist Schluss, dann entscheidet ein Mensch.

Und eine vierte, die wir gerade nutzen: einen Ruhemodus. Solange es keinen zahlenden Kunden gibt, arbeitet die Belegschaft nicht auf eigene Rechnung. Die Kollegen sind ansprechbar, sie holen sich aber keine Aufgaben und verbrauchen nichts.

Das ist eine unbequeme Entscheidung, weil sie das Projekt verlangsamt. Sie folgt aber genau aus dem, was in Teil 1 steht: Wenn die These lautet, dass sich eine Organisation aus KI-Kollegen tatsächlich tragen kann, dann darf der eigene Betrieb nicht das erste Gegenbeispiel sein.