ServiceNow Yokohama Release: AI Agents im ersten Praxistest

Jetzt also Agenten. Mit dem Yokohama-Release rollt ServiceNow das Thema AI Agents breit aus, inklusive Agent Studio zum Bauen eigener Agenten und einem Orchestrator, der mehrere davon koordiniert. Ich habe die letzten zwei Wochen ausgiebig damit experimentiert, und das hier ist der Erfahrungsbericht, den ich mir vorher gewünscht hätte.

Was sich grundsätzlich ändert

Der Unterschied zu allem Bisherigen lässt sich in einem Satz fassen: Now Assist hat bisher formuliert, zusammengefasst und vorgeschlagen. Ein Agent führt aus.

Technisch bekommt ein Agent drei Dinge: ein Ziel, Anweisungen und Werkzeuge, also Flows, Skripte, Record-Operationen oder Retrieval auf Wissensquellen. Den Weg zum Ziel sucht er sich selbst, einschließlich der Entscheidung, welche Werkzeuge er in welcher Reihenfolge einsetzt. Das ist die eigentliche Neuerung und gleichzeitig die Quelle aller interessanten Fragen, denn ein System, das seinen Lösungsweg selbst wählt, verhält sich anders als jeder Flow, den wir bisher gebaut haben.

Mein Testfall: Incident-Triage

Als Versuchsaufbau habe ich eine klassische Triage gewählt. Der Agent sollte eingehende Incidents anreichern: ähnliche zurückliegende Fälle suchen, betroffene CIs aus der CMDB ziehen, daraus eine Einschätzung der Auswirkung ableiten, eine Priorität vorschlagen und alles nachvollziehbar in den Arbeitsnotizen dokumentieren.

Das Ergebnis nach einigem Feintuning: erstaunlich brauchbar. Der Agent kombiniert Informationen aus mehreren Tabellen ungefähr so, wie es ein erfahrener Dispatcher tun würde, nur in Sekunden statt Minuten. Besonders beeindruckt hat mich die Suche nach ähnlichen Fällen, die auch Formulierungsvarianten fand, an denen klassische Textsuche scheitert.

Genauso lehrreich waren die Momente, in denen es schiefging. Drei Beobachtungen daraus:

Vage Anweisungen führen zu kreativen Umwegen. Mein erster Anweisungstext war zu allgemein gehalten, und der Agent interpretierte ihn an einer Stelle so frei, dass er begann, verwandte Probleme gleich mitzulösen. Charmant gemeint, aber nicht sein Auftrag. Präzise, fast pedantische Anweisungen wirken hier Wunder.

Ein zu großzügiges Werkzeugset verführt. Anfangs hatte ich dem Agenten breiten Tabellenzugriff gegeben, einfach weil es bequem war. Prompt nutzte er ihn für Aktualisierungen, die nicht gefragt waren. Die Lektion: Werkzeuge so eng schneiden wie irgend möglich, nicht die Tabelle freigeben, sondern die konkrete Operation.

Und: Das Verhalten ist nicht deterministisch. Derselbe Incident kann an zwei Tagen leicht unterschiedlich behandelt werden. Für eine Triage-Unterstützung ist das verkraftbar, für andere Anwendungsfälle nicht. Diese Eigenschaft muss man je Use Case bewusst bewerten, statt sie zu verdrängen.

Man designt Grenzen, nicht Abläufe

Meine wichtigste übergreifende Erkenntnis: Die Arbeit verschiebt sich. Bei einem Flow designt man den Ablauf, Schritt für Schritt. Bei einem Agenten designt man die Grenzen: welches Ziel, welche Werkzeuge, welche Tabellen, wann ist ein Mensch dran. Der Ablauf dazwischen gehört dem Agenten.

Das fühlt sich für Plattform-Menschen zunächst falsch an, wir sind auf Kontrolle über jeden Schritt trainiert. Aber genau diese Eigenschaft macht Agenten dort wertvoll, wo der Weg eben nicht vorab bekannt ist: bei Analyse, Korrelation und Einschätzung. Wo der Weg bekannt ist, bleibt der Flow das richtige Werkzeug. Diese Abgrenzung wird uns, glaube ich, noch jahrelang beschäftigen.

Empfehlung für den Einstieg

Mein Rat nach diesen zwei Wochen: mit lesenden Agenten anfangen. Anreichern, analysieren, zusammenfassen, vorschlagen, alles Aktionen, deren schlimmster Fehler eine unnütze Notiz ist. Schreibende Aktionen erst, wenn man dem Verhalten über Wochen zugeschaut hat, und auch dann zunächst mit Freigabeschritt durch einen Menschen.

Wer jetzt startet, sollte außerdem von Tag eins protokollieren, was der Agent tut und warum. Nicht nur für die eigene Lernkurve, sondern weil die Governance-Fragen absehbar kommen: Wer verantwortet die Entscheidung eines Agenten? Nach welchen Regeln darf er handeln? Dazu demnächst mehr, das Thema verdient einen eigenen Beitrag.

Die Richtung ist jedenfalls klar. Die Frage für 2025 ist nicht mehr, ob KI im Service Management mitarbeitet, sondern wie viel Verantwortung man ihr überträgt und wie man das kontrolliert.