„Das bauen wir selbst", und drei weitere Einwände gegen Agent Analytics

Wenn Sie wie die meisten Unternehmen sind, stehen Sie unter Druck, großartige KI-Systeme zu investieren und einzusetzen. Und wahrscheinlich haben Sie bisher einen erheblichen Teil Ihres Budgets dafür aufgewendet. 

Aber viel zu wenige Menschen denken darüber nach, was als Nächstes passiert: den Nutzen nachweisen, die Auswirkungen auf die Mitarbeiter und den Wert für die Aktionäre. 

93 % des KI-Budgets von Unternehmen fließen in die Technologie selbst: Infrastruktur, Modelle, Bereitstellung. Die verbleibenden 7 % werden dafür aufgewendet, zu verstehen, ob davon überhaupt etwas funktioniert. Viele Builder und Führungskräfte haben erkannt, dass ihnen die Analyse-Ebene fehlt, die alles zum Laufen bringt.

Hier ist, was in Gesprächen mit diesen Führungskräften zur Sprache kam – und warum nicht alles so ist, wie es scheint. 

Einwand 1: „Wir könnten die Tools zur Agent-Messung einfach selbst entwickeln."

Natürlich könntest du das. Es ist 2026. Das wissen wir. Und „wir selbst" bedeutet nicht einmal ein Team von Ingenieuren. Ein PM mit Cursor und einem freien Nachmittag kann etwas zusammen-viben, das seine Agent-Gespräche analysiert.

Das bringt dir einen funktionierenden Prototyp, eine coole Demo und ein schwellendes Qualitätsproblem, das du erst dann spürst, wenn du einen undichten Eimer an nicht zurückkehrenden Nutzern hast – genau dann, wenn es darum geht, das Ganze zu skalieren. 

Wir standen intern vor der gleichen Herausforderung: „Als wir zum ersten Mal ein LLM zur Analyse von Agent-Gesprächen einsetzten, sahen die Ergebnisse großartig aus – bis wir sie überprüften. Unsere Lösung kategorisierte Probleme mit großer Überzeugung falsch und wich auf unvorhersehbare Weise von ihren Anweisungen ab", sagte Danielle Goh, Sr. Product Manager für Agent Analytics. „Um zu einer Ausgabe zu gelangen, der wiractually make a product decision around took months of iterating and improving our methodology." 

Sie müssen dem vertrauen, was Sie entwickeln, und genau da wird es beängstigend und teuer. Jedes Mal, wenn Ihr selbst entwickelter Klassifikator Ihnen sagt: „40 % der Nutzer fragen nach X" oder „dieser Anwendungsfall liegt im Trend", rechnen Sie im Hinterkopf nach. Ist das real? Schaut er auf das richtige Nutzersegment? Hat sich die Klassifikation verschoben, als das Modellaktualisiert? Haben wir eine ganze Kategorie neuer Probleme übersehen, weil wir nicht wussten, wie wir danach fragen sollten? Ist dies ein echtes Muster oder halluziniert das LLM selbstsicher einen Trend?

Das ist das eigentliche Risiko, wenn man sein eigenes KI-Messwerkzeug entwickelt. Und irgendwann wird es zu einem Geschäftskostenfaktor: der Sprint, um es zu bauen, der Wartungsaufwand und die Stunden, die man damit verbringt, die Ergebnisse des eigenen Tools zu prüfen, anstatt auf sie zu reagieren. 

Bevor Ticketmasters Brian Muehlenkamp Agent Analytics hatte, tat er genau das: Er las Chat-Protokolle manuell einzeln durch und versuchte festzustellen, ob ein Interaktion gut verlief oder nicht. „Es war sehr manuell, sehr eins nach dem anderen", sagte er. „Bis zu dem Punkt, wo ich ihm einfach nicht mehr die nötige Sorgfalt widmete, weil der Aufwand den Nutzen nicht wert war."

Sobald er über zuverlässige, strukturierte Daten verfügte, denen er wirklich vertrauen konnte, nutzte er diese, um ein häufig auftretendes Problem zu identifizieren, verbesserte die Wissensdatenbank des Agenten, um es zu beheben, und erzielte eine Reduzierung der Rage-Prompts um 53 % rate. Dies ist ein systematisierter, qualitativer Gewinn, den Sie nicht durch das Überfliegen von Logs, das Hochladen statischer Tabellen und stundenlange Datenbankabfragen erzielen können.

Konzentrieren Sie Ihre Bemühungen auf den Aufbau des Agenten, der Ihnen den Markt sichert. Wir haben das Werkzeug entwickelt – bewährt –, um Ihnen dabei zu helfen.

Einwand 2: „Wir haben bereits ein KI-Observability-Tool, wie LangSmith oder Arize."

Gut. Verwenden Sie es weiter. Entwickler-Observability-Tools sind hervorragend in dem, wofür sie entwickelt wurden: Traces, Latenz, Evals, Token-Kosten, Halluzinationserkennung. Wenn Ihr Agent um 2 Uhr morgens ausfällt, ist das das Team, das Sie anrufen werden. Diese Tools zeigen Ihnen, ob das System gesund ist – und diese Frage ist wichtig.

Aber es gibt eine zweite Frage, für deren Beantwortung kein Observability-Stack konzipiert wurde: Erhalten meine Nutzer tatsächlich einen Mehrwert?

Das sind nicht dieselben Fragen. Ein Agent kann eine perfekte Betriebszeit, saubere Traces und eine Antwortzeit von 1,2 Sekunden aufweisen, während ein Nutzer seine Frage neunmal umformuliert, frustriert aufgibt und nie wiederkommt. Ihr Entwicklungstool wertet diese Interaktion als abgeschlossene Sitzung, wohingegen Agent Analytics markiert es als eine gefährdete Benutzererfahrung.