Drei Dinge, die in der zweiten Jahreshälfte 2026 zählen
Nach der Arbeit mit Production Agent-Systemen über mehrere Client-Tracks hinweg sind es drei Disziplinen, die die stabilen Systeme von denen unterscheiden, die stillschweigend abgeschaltet werden.
1. Ein Messsystem pro Agent, nicht pro Produkt
Das Standard-Metric für die meisten ausgelieferten KI-Features ist Adoption. Wie viele Nutzer haben es geöffnet. Wie viele Sessions. Wie viele Lizenzen aktiviert. Das ist ein Product-Metric, kein Agent-Metric. Es sagt dir nichts darüber, ob der Agent das tut, wofür du ihn gebaut hast.
Nützliche Metriken liegen eine Ebene tiefer. Task Success Rate: hat der Agent die zugewiesene Aufgabe ohne menschliches Eingreifen oder Neustart abgeschlossen? Tool Call Accuracy: wenn der Agent nach einer Funktion oder API gegriffen hat, hat er die richtige mit den richtigen Argumenten aufgerufen? Cost per Outcome: nicht Cost per Token, nicht Cost per Session, sondern Kosten pro Einheit echten Wertes.
Das ist schwieriger zu instrumentieren, besonders wenn der Agent schnell für einen Demo zusammengezimmert wurde. Aber das sind die einzigen Zahlen, die dir sagen, ob das System seinen Platz verdient. Such dir zwei oder drei aus, bevor du live gehst. Du kannst später mehr hinzufügen. Mit nichts zu starten bedeutet, dass du ohne Instrumente fliegst.
2. Identität, Audit Logs, Rollback und Human Override sind das Minimum, nicht das Ziel
Jeder Production Agent muss wissen, in wessen Namen er handelt, eine Spur hinterlassen, was er getan hat, rückgängig gemacht werden können, wenn er mit schlechten Daten handelt, und einen klaren Weg für einen Menschen haben, um die Kontrolle zu übernehmen.
Diese vier Dinge sind kein Compliance-Checklistenpunkt. Sie sind die mechanischen Eigenschaften, die ein agenthaftes System sicher im großen Maßstab betreibbar machen. Ohne sie kann ein einzelner schlechter Lauf den Zustand korrumpieren, einen Kunden falsch berechnen, etwas Irreversibles löschen oder einen Downstream-Prozess auslösen, der Tage zum Entwirren braucht.
Der Widerstand, den ich normalerweise höre, ist, dass das Hinzufügen dieser Infrastruktur das Team verlangsamt. Das tut es, leicht, beim ersten Mal. Beim dritten Agent ist es ein Zwei-Stunden-Setup, weil die Muster schon vorhanden sind. Die Kosten für das Nachrüsten nach einem Incident sind um Größenordnungen höher.
Das ist die gleiche Logik, die Versionskontrolle für Code unverzichtbar machte. Niemand argumentiert mehr darüber. Audit Logs und Rollback für Agents werden dorthin kommen. Die Teams, die jetzt bauen und diese als optional behandeln, leihen sich einfach Zeit.
3. ROI auf der Outcome-Ebene, nicht auf der Tool-Ebene
Das ist der Punkt, wo viele Business Cases stillschweigend zusammenbrechen. Ein Team baut einen Agent, misst die Kosten seiner Betreibung (Compute, API-Aufrufe, Engineering-Zeit), vergleicht ihn mit den Lizenzkosten des SaaS-Tools, das er ersetzt, und nennt es einen Sieg.
Aber die Tool-Kosten waren nie die echten Kosten. Die echten Kosten waren die Zeit, die eine Person für eine Aufgabe aufbrachte, die ein Ergebnis produzierte. Die richtige Frage lautet: bringt der Agent dieses Ergebnis schneller, genauer und mit weniger nachgelagerten Korrektionen? Das ist ein Outcome. Da lebt der ROI.
Messung auf der Tool-Ebene ist bequem, weil die Zahlen leicht zu ziehen sind. Messung auf der Outcome-Ebene zwingt dich zu definieren, was ein gutes Ergebnis aussieht, was ein Gespräch über Qualität erzwingt, für das viele Teams nicht bereit sind. Führe dieses Gespräch vor dem Shippet. Es macht alles andere schärfer.
