Agentic AI
Mai 19, 2026
Max Schreiber 
ServiceNow baut einen Agenten-Generator direkt in die Entwicklungsumgebung. Klingt nach einem Quantensprung. Ist es auch einer – aber nur, wenn Sie die Grenzen kennen.
Seien wir ehrlich. Die meisten Enterprise-IT-Abteilungen haben jahrelang ITSM-Prozesse in ServiceNow gebaut – Change-Workflows, Incident-Routinen, Request-Kataloge. Das Ergebnis: solide deterministische Maschinen, die funktionieren, solange nichts Unvorhergesehenes passiert. Jetzt kommt ServiceNow mit dem Versprechen, diese bestehenden Strukturen per Knopfdruck in KI-Agenten-Fähigkeiten zu verwandeln.
Der Build Agent ist ein generativer Assistent, der direkt in der ServiceNow-Entwicklungsumgebung sitzt. Sie beschreiben in natürlicher Sprache, was ein KI-Agent tun soll – und das System generiert daraus automatisch Agenten-Strukturen, Skills und die dazugehörigen Zugriffsrechte. Die ServiceNow-Dokumentation formuliert es so: Build Agent ermöglicht das Erstellen benutzerdefinierter agentischer Workflows, KI-Agenten und Skills über automatisierte Generierungswerkzeuge.
Das klingt abstrakt. Konkret bedeutet es: Ein Incident-Subflow, den Ihr Team vor drei Jahren gebaut hat, wird nicht weggeworfen. Er wird zum Tool – zu einer Fähigkeit, die ein KI-Agent in Zukunft selbstständig aufrufen kann. ServiceNow nennt das Prinzip intern „Agentic Fabric“: bestehende Workflows bleiben Workflows. Die KI orchestriert sie, statt sie zu ersetzen.
Meine Einschätzung: Das ist konzeptionell klüger als das, was die meisten Wettbewerber tun. Statt alles neu zu erfinden, macht ServiceNow den Bestand intelligent nutzbar. Das Problem liegt woanders.
Was passiert technisch, wenn Build Agent einen Skill erzeugt? Laut offizieller Dokumentation unterstützt das System mehrere Skill-Typen: WebSearch, Inline-Skripte, explizite Skripte, Now Assist Skills, FlowActions und Subflows. Entscheidend ist dabei ein Detail, das viele Artikel unterschlagen: FlowActions und Subflows müssen bereits im App-Scope existieren. Build Agent erfindet keine Logik neu – er erkennt vorhandene Artefakte und bindet sie ein.
Die Workflow-Automatisierung funktioniert nach einem klaren Architektur-Prinzip: Der KI-Agent übernimmt die Orchestrierung, interpretiert Absichten und trifft Entscheidungen. Die eigentliche Ausführung bleibt bei den deterministischen Bausteinen – den Subflows und FlowActions, die Ihr Team bereits gebaut und getestet hat. Das ist keine Schwäche des Ansatzes. Das ist sein größter Vorteil.
Ein praktisches Beispiel aus der ServiceNow-Dokumentation: Ein Agent-Skill soll Reiseanträge zusammenfassen und Genehmigungsempfehlungen auf Basis der Unternehmensrichtlinie generieren. Build Agent erzeugt dafür einen Now Assist Skill, der die Richtlinien-Dokumente interpretiert und strukturierte Vorschläge ausgibt. Das ist Workflow-Automatisierung mit einem semantischen Layer darüber – kein Zaubertrick, aber ein echter Architektursprung.
Gleichzeitig erzeugt Build Agent bei der Agenten-Erstellung automatisch einen strukturierten Plan: Research, Design, Implementation, Testing, Deployment. Das ist kein Marketing-Feature. Das ist eine praktische Kontrollebene, die verhindert, dass generierte Artefakte unkontrolliert in Produktionssysteme rutschen.
Mit dem Zurich Release Patch 4 hat ServiceNow eine Funktion eingeführt, die in der öffentlichen Debatte kaum diskutiert wird, aber erhebliche operative Konsequenzen hat: bestimmte generative KI-Skills werden automatisch auf „Default On“ gesetzt.
Was das konkret bedeutet: Bei neuen Installationen mit Now Assist Plugins werden ausgewählte Generative-AI-Plattform-Skills sofort aktiv. Bei Upgrades bestehender Umgebungen werden bislang ungenutzte Skills mit Default-On-Status ebenfalls aktiviert – es sei denn, ein Administrator hat Rollen oder Status zuvor explizit verändert.
Schluss damit, das zu verharmlosen. Für Enterprise-Umgebungen ist das eine relevante Governance-Frage. Welche Skills werden automatisch aktiv? Haben alle betroffenen Teams das gewusst? Gibt es einen Überblick über den Skill-Katalog? ServiceNow liefert mit dem AI Control Tower ein Monitoring-Werkzeug – aber wer es nicht einrichtet, tappt im Dunkeln.
Die harte Wahrheit: Auto-Aktivierung ist bequem und gefährlich zugleich. Bequem, weil Teams sofort auf generative Fähigkeiten zugreifen können. Gefährlich, weil in regulierten Branchen jede automatisch aktivierte KI-Funktion Compliance-Prüfungen auslösen kann.
Praktiker-Guides – darunter der ausführliche Leitfaden von eesel AI aus dem Jahr 2025 – zeichnen ein nüchterneres Bild als die ServiceNow-Produktseiten. Der Aufwand für produktionsreife Agent-Skill-Setups in Enterprise-Umgebungen liegt realistisch bei Wochen bis Monaten. Plugin-Installation, Konfiguration im AI Agent Studio, Erstellung und Anpassung von Skills, umfangreiche Tests – das ist keine Nachmittagsarbeit.
Dazu kommt die Plattform-Bindung. ServiceNow-Agent-Skills sind primär für den internen Ökosystem-Einsatz optimiert. Die Workflow-Automatisierungs-Plattform bietet zwar Konnektoren zu externen Systemen – Jira, Zendesk und ähnliche Tools sind grundsätzlich integrierbar – aber der Aufwand ist erheblich. Eesel AI spricht direkt von einem „Walled Garden“: Skills sind stark auf ServiceNow-interne Prozesse zugeschnitten. Wer externe Systeme tief integrieren will, landet schnell in Middleware-Projekten, die den ursprünglichen Low-Code-Vorteil auffressen.
Besonders aufschlussreich ist die Frage nach dem Testen: Für Agents gibt es das AI Agent Studio mit Testtools, für Skills das Now Assist Skill Kit. Wer glaubt, generierte Artefakte einfach deployen zu können, macht einen Fehler. Build Agent liefert Vorschläge, keine fertigen Produktionssysteme. Prüfen, anpassen, testen – das bleibt Facharbeit.
Diese Realität gilt auch für verwandte Ansätze bei Enterprise-KI-Agenten. Wer sich für den breiteren Kontext interessiert, findet beim Thema Agentic AI als echte Mitarbeiter ähnliche Muster: Die Plattform liefert den Rahmen, aber die organisatorische Einbettung ist die eigentliche Aufgabe.
Abseits der grundsätzlichen Implementierungskomplexität gibt es in der Praxis wiederkehrende Problemfelder, die erfahrene ServiceNow-Entwickler kennen und Einsteiger regelmäßig überraschen. Das frühzeitige Bewusstsein für diese Punkte spart erheblichen Nacharbeitsaufwand.
Scope-Konflikte: Build Agent arbeitet strikt innerhalb des App-Scope. Wer Subflows oder FlowActions aus anderen Scopes einbinden will, stößt schnell auf Berechtigungsschranken. Das ist kein Bug, sondern gewollte Isolation – aber sie erfordert eine klare Scope-Strategie vor dem ersten Skill-Entwurf. Nachträgliches Refactoring von Scope-Grenzen ist aufwendig und fehleranfällig.
Prompt-Qualität bestimmt Ergebnis-Qualität: Build Agent generiert auf Basis natürlichsprachlicher Eingaben. Vage Beschreibungen liefern vage Strukturen. Wer schreibt „Erstelle einen Agent für IT-Anfragen“, bekommt ein generisches Gerüst. Wer präzisiert – Prozessschritt, Dateneingabe, erwartete Ausgabe, Ausnahmen – bekommt etwas, das näher an der Produktionsrealität liegt. Die Qualität der Prompt-Formulierung ist eine unterschätzte Kompetenz, die Entwicklungsteams aktiv trainieren müssen.
Versionierung und Update-Risiken: Generierte Skills sind statische Artefakte zum Zeitpunkt ihrer Erzeugung. Wenn sich der zugrundeliegende Subflow ändert – etwa weil ein Geschäftsprozess angepasst wird –, wird der Skill nicht automatisch aktualisiert. Teams ohne klare Versionierungsdisziplin riskieren, dass Agents auf veraltete Logik zugreifen. Das ist nicht dramatisch, wenn man es weiß. Es ist gefährlich, wenn man es nicht weiß.
Skill-Granularität: Die Versuchung ist groß, möglichst umfassende Skills zu bauen, die viele Aufgaben auf einmal abdecken. Die Praxiserfahrung zeigt das Gegenteil: granulare, eng definierte Skills mit einem klaren Verantwortungsbereich sind robuster, leichter testbar und einfacher zu warten. Ein Skill, der Tickets klassifiziert, sollte nicht gleichzeitig Benachrichtigungen versenden und Eskalationsregeln prüfen. Die Orchestrierungslogik gehört in den Agent, nicht in den Skill.
Falsch. Widerlegbar. Gefährlich.
Weder die ServiceNow-Dokumentation noch seriöse Praxisberichte behaupten, dass Build Agent menschliche Entwickler oder Administratoren überflüssig macht. Das System generiert Vorschläge – Plans, Agents, Skills – und nutzt vorhandene App-Artefakte. Die Fachkompetenz, die dahinter steckt, kommt weiterhin von Menschen.
Konkret: Sicherheitsmodelle, komplexe Business-Logik, Compliance-Anforderungen, ACL-Konzepte und das Testen in Enterprise-Kontexten bleiben Aufgaben für ServiceNow-Entwickler und -Admins. Was Build Agent abnimmt, ist die manuelle Tipparbeit bei der Strukturerzeugung. Das ist wertvoll. Es ist aber kein Ersatz für Expertise.
Seien wir ehrlich: Wer in Stellenanzeigen nach „ServiceNow-Entwickler nicht mehr nötig, da KI“ sucht, findet das nicht – und sollte es auch nicht finden. Der Build-Agent-Ansatz laut ServiceNow-Dokumentation ist ein Assistenz-Werkzeug. Wer es als Vollautomation vermarktet, lügt.
ServiceNow selbst gibt in seiner Architektur-Guidance klare Empfehlungen, welche Prozesse sich für KI-gesteuerte Agent Skills eignen – und welche nicht. Das Muster nennt sich Hybrid-Workflow-Ansatz.
KI-first Workflows machen Sinn, wenn Prozesse unstrukturiert sind, viele Ausnahmen haben und Kontext-Interpretation erfordern. Ein Agent, der eingehende IT-Tickets klassifiziert und priorisiert, ist ein gutes Beispiel. Der Intent ist variabel, die Sprache uneinheitlich, die Ausnahmen zahlreich.
Deterministische Workflows mit punktuellem KI-Einsatz sind dagegen das richtige Muster für Compliance-kritische Prozesse: Change-Management, Finanz-Freigaben, Security-Incidents. Hier bleibt die Prozesskette festgelegt; KI übernimmt allenfalls Interpretation oder Zusammenfassung an klar definierten Punkten.
Das ist wichtige Orientierung. In der Praxis – das zeigen Partnerberichte von Kellton und anderen ServiceNow-Implementierungspartnern – neigen Teams dazu, zu früh zu viel an KI-Agents zu delegieren. Human-in-the-loop ist in kritischen Prozessen keine optionale Zusatzfunktion. Es ist die Voraussetzung für Auditierbarkeit und regulatorische Compliance.
Ähnliche Überlegungen finden sich auch bei anderen Enterprise-Plattformen: Figma etwa hat mit MCP und Skills einen vergleichbaren Ansatz gewählt, bei dem KI-Fähigkeiten als modulare, kontrollierte Bausteine eingebettet werden – nicht als monolithischer Autopilot.
30 bis 50 Prozent kürzere Prozesslaufzeiten durch agentische Workflows – diese Zahlen kursieren in Partnerberichten und Implementierungs-Guides. Die harte Wahrheit: Sie stammen aus Marketing-Unterlagen von ServiceNow-Partnern wie Kellton, nicht aus peer-reviewten Studien oder öffentlich zugänglichen, neutralen Messberichten.
Das bedeutet nicht, dass die Zahlen falsch sind. Es bedeutet, dass Sie sie nicht als Benchmark nehmen sollten, wenn Sie intern eine Business-Case-Rechnung aufstellen. Effizienzgewinne durch Workflow-Automatisierung sind real – aber sie hängen von der Prozessqualität vor der Einführung, der Implementierungstiefe und der organisatorischen Reife ab.
Wer seinen CIO mit „laut Anbieter 30–50 Prozent schneller“ überzeugen will, hat möglicherweise kurze Beine – zumindest ohne eigene Pilotmessung. Starten Sie mit einem eng definierten Use Case, messen Sie Baseline-Zeiten vor dem Rollout und dokumentieren Sie die Ergebnisse aus Ihrer spezifischen Umgebung. Dann haben Sie Zahlen, die tragen.
Der breitere Markt bewegt sich übrigens in dieselbe Richtung: Technologieriesen wie Microsoft, Salesforce und SAP treiben autonome Agenten-Prozesse massiv voran. ServiceNow ist in diesem Rennen kein Außenseiter – aber auch keine unangefochtene Führungsposition.
Agent Skills sind keine Blackboxes, die irgendwo im Hintergrund Entscheidungen treffen. Zumindest sollten sie das nicht sein. ServiceNow bietet mit dem AI Control Tower eine zentrale Überwachungsebene: Audit Trails, Monitoring von Agent-Aktivitäten, Policy-Enforcement.
Das Problem: Kein Tool konfiguriert sich selbst. In der Praxis erleben Implementierungsteams, dass Governance-Konzepte oft nachgelagert entwickelt werden – nach der ersten Euphorie des erfolgreichen Agent-Deployments. Das ist der falsche Zeitpunkt.
Meine klare Empfehlung: Governance-Konzept vor dem ersten produktiven Agent-Skill. Das umfasst konkret: Welche Skills dürfen ohne menschliche Freigabe agieren? Welche Prozesse erfordern Human-in-the-loop? Welche Logging-Anforderungen existieren aus Datenschutz- und Compliance-Sicht? Wer hat Zugriff auf den Skill-Katalog und darf neue Skills publishen?
Diese Fragen sind nicht akademisch. In deutschen Enterprise-Umgebungen, wo Betriebsräte KI-Einsatz mitbestimmen und DSGVO-Anforderungen für jeden automatisierten Entscheidungsprozess gelten, sind sie existenziell. Build Agent und AI Agent Studio liefern technische Antworten. Die organisatorische Rahmensetzung bleibt bei Ihnen.
Wer die konzeptionelle Diskussion hinter sich lassen und praktisch starten will, braucht einen strukturierten Einstiegspfad. Die folgenden Schritte sind keine Garantie für Erfolg – aber sie reduzieren die häufigsten Anfängerfehler erheblich.
Diese Schritte klingen nach gesundem Menschenverstand – und das sind sie auch. Der Grund, warum sie trotzdem explizit erwähnt werden müssen: In der Praxis werden sie regelmäßig übersprungen, weil die Begeisterung für das neue Werkzeug die Sorgfalt verdrängt. Build Agent macht das Generieren schnell. Die Konsequenzen schlecht geplanter Agents beheben sich langsam.
ServiceNow Build Agent ist kein Hype-Produkt ohne Substanz. Die Architektur – bestehende deterministische Workflows als Tools für KI-Orchestratoren nutzbar machen – ist konzeptionell robust. Wer jahrelang sauber modellierte Subflows und FlowActions aufgebaut hat, profitiert direkt. Wer Workflow-Chaos gebaut hat, wird auch mit Build Agent keinen ordentlichen Agent-Skill erzeugen.
Das Zurich-Release hat mit Auto-Aktivierung von Default-On-Skills und dem AI Agent Studio echte operative Relevanz erreicht. Gleichzeitig: Die Implementierungsrealität bleibt komplex, der Plattform-Lock-in ist real, und die Effizienzversprechen des Anbieters brauchen Ihre eigene Validierung.
Schluss damit, auf den perfekten Moment zu warten. Starten Sie mit einem klar abgegrenzten ITSM-Prozess – Incident-Klassifikation ist ein klassischer Einstieg – bauen Sie den Governance-Rahmen zuerst und messen Sie, was Sie wirklich gewinnen. Dann haben Sie Grundlage statt Glauben.
Was macht Ihr Team gerade mit bestehenden Subflows – lässt sie in der Schublade liegen oder baut es aktiv an agentischen Fähigkeiten? Schreiben Sie es in die Kommentare.
