ServiceNow-KI-Agenten können einen Incident analysieren, entscheiden, was passieren soll, und innerhalb der Plattform handeln. Was sie jenseits der Plattformgrenze können, hängt vollständig davon ab, welche externen Systeme angebunden wurden, von wem, und wer diese Verbindungen am Laufen hält.
Dieser Artikel zeigt, was ServiceNow-KI-Agenten 2026 nativ erreichen, was Action Fabric und der MCP-Client vom externen System verlangen, wo die Reichweite endet und wie die Optionen zum Schließen dieser Lücke im Vergleich abschneiden.
Kernaussagen
- ServiceNow-KI-Agenten handeln frei auf ServiceNow-Daten; für alles andere brauchen sie eine Verbindung, die bereits existiert, mit Zugangsdaten, Monitoring und einem Owner.
- Action Fabric erlaubt ServiceNow-Agenten, externe MCP-Server aufzurufen und Aufgaben über A2A mit externen Agenten auszutauschen, aber nur, wenn das externe System bereits einen konformen Server oder Agenten-Endpunkt betreibt. Die meisten Legacy-, Kunden- und Partnersysteme tun das nicht.
- IntegrationHub deckt ServiceNow-zentrierte Flows mit transaktionsbasierter Preisgestaltung ab, wobei Ihr Team jeden Spoke, jede Zugangsberechtigung und jedes Mapping betreibt.
- Wo eine Verbindung keinen Owner hat, gibt der Agent die Arbeit an einen Menschen zurück, der dahinterliegende Prozess wartet, und dieser Teil des Business Case zahlt sich nie aus.
- Ein Managed Integration Service gibt Agenten Any-to-any-Reichweite über Organisationsgrenzen hinweg, mit einem namentlich benannten Owner und einem Service Level auf jeder Verbindung statt nur auf der Plattformverfügbarkeit.
Das Betriebsmodell hinter Managed Integration Services beschreibt das Integration Ops Buch ausführlich: Lifecycle-Phasen, Ownership-Muster und Playbook-Beispiele. Kostenlos herunterladen.
Was sind ServiceNow-KI-Agenten?
ServiceNow-KI-Agenten sind konfigurierbare, zielgerichtete Agenten, die im AI Agent Studio gebaut und vom AI Agent Orchestrator koordiniert werden. Sie können über ServiceNow-Daten schlussfolgern und Aktionen ausführen wie Datensätze aktualisieren, Flows auslösen und Incidents lösen. Sie arbeiten nativ auf der ServiceNow AI Platform und erreichen andere Systeme nur über Verbindungen, die für sie konfiguriert wurden.
Dieser letzte Halbsatz ist das gesamte Thema dieses Artikels. Alles, was ein Agent innerhalb von ServiceNow tut, ist eine Plattformfunktion. Alles, was er außerhalb von ServiceNow tut, ist eine Integration.
Was ServiceNow-KI-Agenten heute außerhalb von ServiceNow können
ServiceNow hat stark in die Erweiterung der Agentenreichweite investiert, und die Action-Fabric-Ebene von 2026 geht weiter, als viele Teams annehmen. Drei Mechanismen sind relevant.
MCP Server Console. ServiceNow-Funktionen werden als MCP-Tools veröffentlicht, sodass externe KI-Agenten gesteuerte ServiceNow-Workflows ausführen können. Administratoren veröffentlichen Now-Assist-Skills, Subflows oder skriptbasierte REST-APIs als Tools, konfigurieren OAuth 2.0 und setzen Zugriffskontrollen über das AI Gateway.
MCP Client. ServiceNow-KI-Agenten können Tools in externen MCP-Servern aufrufen, was ServiceNow laut Dokumentation Systeme „wie Jira, Salesforce, SAP, GitHub oder jedes MCP-konforme System ohne individuellen Integrationscode" abdecken lässt. Der Administrator registriert den externen Endpunkt im AI Agent Studio und konfiguriert Zugangsdaten und einen Connection Alias.
A2A. Ein ServiceNow-Agent und ein externer Agent können eine gemeinsame Aufgabe koordinieren, Teilaufgaben delegieren und Kontext untereinander weitergeben.
Zusammengenommen geben diese Mechanismen einem Agenten echte Reichweite in die modernen, gut gepflegten Teile einer Systemlandschaft. Für Plattform-zu-Plattform-Arbeit zwischen zwei Anbietern, die beide in Agentenprotokolle investieren, ist das ein echter Fortschritt und eine bessere Antwort, als pro Anwendungsfall einen individuellen Connector zu bauen.
Wo die Reichweite endet
Jeder dieser drei Mechanismen stellt eine Anforderung an das System am anderen Ende der Verbindung.
Der MCP-Client funktioniert, wenn das externe System einen MCP-konformen Server bereitstellt, mit konfigurierter Authentifizierung und mit Schemas veröffentlichten Tools. A2A funktioniert, wenn das entfernte System einen A2A-fähigen Agenten auf einem HTTP-Endpunkt betreibt, der das Protokoll implementiert. Die MCP Server Console funktioniert, wenn der externe Client MCP implementiert und gültige ServiceNow-Zugangsdaten besitzt.
Wenden Sie das nun auf eine reale Systemlandschaft an. Vier Kategorien von Systemen fallen regelmäßig durch diesen Test.
Legacy-Systeme und Eigenentwicklungen. Die Asset-Datenbank, die Abrechnungs-Engine, das Planungstool, das ein externer Entwickler 2011 geschrieben hat. Kein Protokollserver, keine Roadmap für einen, und oft keine API, die diesen Namen verdient.
Kunden- und Partnerumgebungen. Ein Service Provider, der sich an die ITSM-Plattform eines Kunden anbindet, kontrolliert weder die Protokolladoption dieses Kunden noch dessen Sicherheitslage oder Release-Zeitplan. Darauf zu warten, dass jeder Kunde einen MCP-Server veröffentlicht, ist kein Lieferplan.
Systeme hinter organisatorischen Richtlinien. Finanz- und OT-Systeme, bei denen die Governance die Einschränkung ist, nicht die Technologie. Der Endpunkt könnte existieren. Er wird einem autonomen Agenten nicht ohne Kontrollen geöffnet, die jemand entwerfen, dokumentieren und betreiben muss.
Anbieter mit langsamerem Protokollfahrplan. Viele etablierte ITSM- und Operations-Tools werden Agentenprotokolle irgendwann unterstützen. Ihr Agenten-Business-Case ist auf dieses Jahr datiert.
Das Muster hinter diesen vier Kategorien ist konsistent: Protokolle standardisieren, wie zwei willige, moderne, gut ausgestattete Endpunkte miteinander sprechen, aber sie erschaffen keine Endpunkte und sie pflegen sie nicht. Und das sind selten die unwichtigen Systeme. Sie halten typischerweise die Abrechnungsläufe, die Einsatzplanung im Außendienst und die Kundenzusagen, sodass jedes System, das der Agent nicht erreicht, Arbeit ist, die manuell bleibt, und jedes, das mitten im Workflow bricht, ein Prozess ist, der für die gesamte Organisation stillsteht, während die IT herausfindet, warum.
Was IntegrationHub abdeckt und was nicht
IntegrationHub ist die native Antwort für ServiceNow-zentrierte Integration: Spokes, Flow-Designer-Aktionen und ein großer Katalog vorgefertigter Operationen. Für Flows, die innerhalb eines von ServiceNow verwalteten Prozesses beginnen und enden, ist es der Weg des geringsten Widerstands.
Zwei Eigenschaften definieren seine Grenze. Es wird pro Transaktion abgerechnet, sodass die Kosten mit genau dem steigen, was ein erfolgreiches Agentenprogramm produziert, nämlich mehr automatisierte Aktionen. Und es ist ein Tool, das Ihr Team konfiguriert und pflegt, kein Service, den jemand für Sie betreibt, sodass jeder Spoke, jede Zugangsberechtigung und jedes Mapping durch jedes Release auf beiden Seiten hindurch in der Verantwortung Ihres Teams bleibt.
Das funktioniert, solange die Systemlandschaft ServiceNow-förmig ist. Es funktioniert weniger gut, wenn die Landschaft mehrere Anbieter und mehrere Unternehmen umfasst. Deshalb kommen Teams, die Alternativen zu ServiceNow IntegrationHub prüfen, meist über Kostenplanbarkeit oder unternehmensübergreifende Reichweite dorthin, selten über eine fehlende Funktion.
Wo ein Managed Integration Service hineinpasst
Ein Managed Integration Service steht neben ServiceNow. Der Anbieter besitzt die Verbindungen zwischen ServiceNow und allem anderen: Design, Build, Monitoring, Change und Verantwortung, im Rahmen eines Abonnements mit angehängter Servicezusage.
Für Agentenprogramme ändert das drei konkrete Dinge. Der Agent erreicht Systeme, die nie ein Agentenprotokoll sprechen werden, weil die Verbindung von einer Partei gebaut und betrieben wird, mit der Sie einen Vertrag haben, nach Ihrem Zeitplan. Unternehmensübergreifende Flows tragen das Mapping, die Filterung und den Audit-Trail, die eine Grenzüberschreitung verteidigungsfähig machen, wenn ein Kunde ein SLA anfechtet. Und jede Verbindung hat einen Owner außerhalb des Plattformteams, kontinuierlich überwacht, sodass ein defekter Schreibpfad erkannt wird, bevor ein autonomer Workflow ihn zu stillstehenden Prozessen und verpassten Kundenzusagen verstärkt.
ONEiO veröffentlicht außerdem einen zertifizierten ServiceNow-Spoke, sodass die ServiceNow-Seite der Verbindung nativ konfiguriert wird, während die Betriebslast für alles auf der anderen Seite beim Anbieter liegt.
„Mir ist egal, welches System der Kunde nutzt, wir können alles mit allem verbinden. Und das ist wirklich einer der größten Vorteile, die ich bei ONEiO sehe, den kein anderer Lösungsanbieter, den ich kenne, versprechen oder liefern kann." So beschreibt Michael von MHP die Eigenschaft, die darüber entscheidet, wie weit ein Agent reicht.
Wann das nicht die richtige Wahl ist. Wenn Ihre Agenten-Anwendungsfälle innerhalb von ServiceNow leben oder nur moderne SaaS-Plattformen erreichen, die bereits MCP-Server bereitstellen, decken native Funktionen und IntegrationHub das ab, und ein Managed Service fügt Kosten hinzu, ohne Reichweite hinzuzufügen. Dasselbe gilt, wenn Sie ein finanziertes Integrationsteam mit dokumentiertem Ownership und Service Levels auf jeder Verbindung betreiben. Der Fall ändert sich, wenn die Landschaft mehrere Unternehmen umfasst, wenn Legacy-Systeme die Aktionen halten, auf die es ankommt, oder wenn das interne Team bereits der Engpass dafür ist, wie schnell Agenten ausgerollt werden.
Fazit zu ServiceNow-KI-Agenten außerhalb von ServiceNow
Innerhalb von ServiceNow sind die Agenten leistungsfähig und werden es immer mehr. Außerhalb ist die Leistungsfähigkeit eine Funktion der Integrationsebene, und Action Fabric hat diese Grenze für Systeme, die die neuen Protokolle sprechen, nach außen verschoben.
Die Systeme, die sie nicht sprechen, sind diejenigen, die die teure Arbeit halten: Legacy-Plattformen, Kundeninstanzen, Partnertools und alles, was so streng gesteuert wird, dass ein autonomer Schreibvorgang eine entworfene Kontrolle braucht. Kein Protokoll erreicht diese Systeme. Eine betriebene Verbindung schon.
Der praktische Schritt, bevor Sie Autonomie einschalten, ist, die Aktionen im Business Case aufzulisten, das System zu benennen, in dem jede Aktion landet, und den Owner der Verbindung dorthin zu benennen. Überall dort, wo dieser zweite Name fehlt, wird der Agent korrekt schlussfolgern und dann das Ticket einer Person zuweisen, und der Prozess hinter diesem Ticket wird genau so lange warten wie heute.
Nicht sicher, wo Ihre Integrationsebene steht? Das Integration Ops Reifegrad-Assessment gibt Ihnen eine strukturierte Einschätzung zu Ownership, Monitoring und Change-Bereitschaft in Ihrer gesamten Systemlandschaft.
