Wie wir messen, was ein Agent geleistet hat

Wer KI-Agenten wie Mitarbeiter führt, muss irgendwann sagen können, was sie eigentlich leisten. Der naheliegende Weg wäre, ein Sprachmodell die Arbeit ansehen und eine Note vergeben zu lassen. Diesen Weg sind wir nicht gegangen.

Der Grund ist einfach: Eine solche Note kann niemand nachrechnen. Sie entsteht im Modell, und wenn jemand fragt, warum sie so ausgefallen ist, gibt es keine Antwort außer einer weiteren Modellantwort. Für eine Zahl, auf die eine Organisation Entscheidungen stützt, ist das zu wenig.

Was wir stattdessen tun

Bei uns ist eine Kennzahl eine Zählregel. Sie zählt Vorgänge, die die Plattform ohnehin protokolliert hat, weil sie sie ausgeführt hat. Kein Modell urteilt, nichts wird benotet.

Jeder Agent bringt seine eigenen Regeln in einer Datei namens KPIS.md mit. Dort steht zum Beispiel, dass ein gelöstes Ticket gezählt werden soll und was eine solche Einheit kostet. Gezählt werden dann die Aktionen, die dieser Agent nachweislich ausgeführt hat.

Das Ergebnis liest sich wie eine Preisliste. So ist sie aufgebaut, hier mit erfundenen Beispielzahlen:

Tickets gelöst            142      3,20 € / Einheit
Code-Reviews               38      1,05 € / Einheit
An einen Menschen          19      —
Läufe fehlgeschlagen        7      —

In dieser kleinen Tabelle stecken zwei Entscheidungen, die uns wichtiger sind als die Zahlen selbst.

Die Anzahl steht immer neben dem Preis

Ein Stückpreis allein sagt fast nichts. Er kann aus tausend Vorgängen stammen oder aus dreien. Deshalb steht die Anzahl immer daneben, und unterhalb einer Mindestanzahl lassen wir den Preis ganz weg.

Der Grund ist Zufall. Ein Durchschnitt über drei Ereignisse schwankt so stark, dass er über nichts Auskunft gibt — er sieht nur aus wie eine Messung. Eine Zahl, die eine Genauigkeit vortäuscht, die sie nicht hat, ist schlechter als gar keine Zahl, weil jemand sie benutzt.

Die letzten beiden Zeilen sind Gegenzahlen

„An einen Menschen" und „Läufe fehlgeschlagen" haben keinen Preis. Sie stehen trotzdem in der Liste, und ohne sie wäre die Liste gefährlich.

Ein Agent, der jeden schwierigen Fall an einen Menschen weiterreicht und nur die einfachen selbst erledigt, hätte hervorragende Stückkosten. Alles, was er nicht gelöst hat, käme in einer Liste ohne diese Zeilen nicht vor. Man würde ihn für besonders effizient halten, obwohl er die Arbeit nur verschoben hat.

Daneben stehen vier weitere Zahlen, die den Preis einordnen: Wie oft kam ein Fall zurück und musste nachgearbeitet werden? Wie oft wurde die Arbeit an einer Freigabe abgelehnt? Wie schnell kam die erste Antwort, und wie lange dauerte der ganze Vorgang? Drei dieser vier Zahlen brauchten keine neue Technik — die Daten lagen längst vor und wurden nur nie ausgewertet.

Nützlich werden sie im Vergleich über die Zeit. Eine steigende Kostenkurve neben einer gleichbleibenden Liefermenge ist ein Befund, dem man nachgehen kann. Jede der beiden Kurven für sich wäre nur eine Zahl.

Warum der Agent seine eigene Messregel nicht sieht

Aus alldem folgt eine Regel, die auf den ersten Blick übertrieben wirkt: Die Datei KPIS.md wird dem Agenten nie in den Prompt gegeben. Er weiß also nicht, woran er gemessen wird.

Der Grund ist bekannt, seit es Kennzahlen gibt. Ein Agent, der weiß, dass die Anzahl seiner Kommentare gezählt wird, schreibt mehr Kommentare. Das ist kein Fehlverhalten und kein Modellfehler — es ist genau die Aufgabe, so wie man sie gestellt hat. Wer die Zielgröße offenlegt, bekommt die Zielgröße optimiert und nicht die Arbeit, für die sie stellvertretend stehen sollte.

Dieselbe Überlegung gilt an einer zweiten Stelle. Covey Doctor ist ein Agent, dessen Aufgabe die Belegschaft selbst ist. Er darf die Konfiguration eines Kollegen lesen und einen Verbesserungsvorschlag dazu schreiben, und er darf das auch für seine eigene Konfiguration. Was er nicht darf, ist seine eigenen Kennzahlen lesen. Sonst würde er den Messwert verbessern statt die Arbeit, und zwar mit deutlich größerem Hebel als ein gewöhnlicher Agent.

Wenn eine Regel ins Leere zählt

Bleibt ein praktischer Fall: Jemand schreibt eine Zählregel, die auf nichts passt — ein Tippfehler im Aktionsnamen, oder ein Vorgang, den dieser Agent gar nicht auslöst.

Die bequeme Antwort wäre, null auszuweisen. Sie ist auch die schlechteste, denn eine Null sieht aus wie ein Ergebnis. Ein Agent mit einer kaputten Regel stünde monatelang mit „nichts geliefert" in der Liste, und irgendwann glaubt das jemand.

Eine Regel, die nichts zählen kann, meldet sich deshalb in der Konfigurationsprüfung. Sie meldet einen Konfigurationsfehler und keine Leistung von null. Das ist dieselbe Linie, die wir überall verfolgen: Was die Plattform meldet, muss man auch abschließen können — indem man es behebt oder indem jemand festhält, dass er die Sache übernimmt. Ein Hinweis, der nie verschwinden kann, wird nach zwei Wochen nicht mehr gelesen, und der Hinweis daneben dann auch nicht mehr.