Offene gegen geschlossene Agenten-Architektur: SAP A2A, Salesforce Headless 360 und ServiceNow Action Fabric

1. Was offene und geschlossene Agenten-Architektur unterscheidet

Mit dem Aufkommen autonomer KI-Agenten stellt sich für Unternehmensplattformen eine Architekturfrage, die über die reine Funktion hinausgeht: Wie dürfen Agenten auf das System zugreifen, und wer kontrolliert diesen Zugang. Zwei Grundmuster stehen sich gegenüber.

Eine geschlossene Architektur leitet jeden Agenten durch ein definiertes, herstellereigenes Tor. Der Zugriff auf Daten und Aktionen erfolgt nur über diesen kontrollierten Kanal, externe Agenten müssen sich dem Protokoll des Plattformbetreibers unterwerfen. Eine offene Architektur stellt Daten, Workflows und Aktionen über Schnittstellen und das Model Context Protocol bereit, sodass beliebige Agenten sie direkt nutzen können, ohne eine herstellereigene KI-Schicht zwingend zu durchlaufen.

1. Warum das mehr ist als eine technische Detailfrage. Die Wahl zwischen offen und geschlossen entscheidet, wer die Kontrolle über den Agenten behält, der am Ende eine Änderung im System auslöst. Im SAP-Change-Kontext ist das unmittelbar relevant, weil eine Änderung, die ein Agent anstößt, denselben Weg in die Produktion nimmt wie jede andere.

2. Abgrenzung zur Frankenstein-Debatte. Die Diskussion um eine unkontrollierte Vielzahl herstellerfremder Agenten ist an anderer Stelle geführt worden. Hier geht es nicht um das Bild des Flickwerks, sondern um den konkreten Architekturunterschied zwischen drei großen Plattformen und seine Folgen für die Governance.

2. Warum die Frage 2026 akut wird

1. Agenten handeln auf Produktivsystemen. Agenten beschränken sich nicht mehr auf das Beantworten von Fragen, sondern führen mehrstufige Prozesse aus und lösen Aktionen mit realen Folgen aus. Sobald ein Agent eine Änderung an einem produktiven Geschäftssystem anstoßen kann, wird die Architektur seines Zugangs zur Governance-Frage.

2. Die großen Plattformen wählen gegensätzliche Wege. Im Frühjahr 2026 ist die Spaltung sichtbar geworden. SAP verfolgt einen kontrollierten, plattformeigenen Weg, während Salesforce und ServiceNow ihre Systeme bewusst für beliebige Agenten öffnen. Dieselbe Aufgabe, nämlich Agenten Zugang zu Geschäftsaktionen zu geben, wird damit architektonisch völlig unterschiedlich gelöst.

3. Regulatorik erhöht den Einsatz. Mit den ab August 2026 wirksamen Pflichten des EU AI Act und den bereits geltenden Anforderungen aus NIS2 und DORA wird die Frage, welcher Agent welche Aktion auslösen darf und wie das nachgewiesen wird, zur Compliance-Frage. Die Architektur des Agenten-Zugangs bestimmt mit, wie gut sich diese Pflichten erfüllen lassen.

4. Die Wahl ist langlebig. Eine einmal gewählte Zugangsarchitektur prägt die Landschaft über Jahre. Wer sich heute für ein geschlossenes oder offenes Modell entscheidet, legt fest, wie flexibel oder wie kontrolliert die Agenten-Landschaft in Zukunft ist.

3. Die drei Hersteller-Ansätze im Vergleich

Die drei großen Plattformen stehen 2026 für drei unterschiedliche Antworten auf dieselbe Frage.

1. SAP, der kontrollierte Weg über Joule. SAP positioniert den Zugang agentischer Anwendungsfälle über Agent-to-Agent-Kommunikation via Joule als den vorgesehenen Weg. Die öffentlichen Schnittstellen sind nach SAP-Darstellung für statische Anwendungen gedacht, nicht für dynamische Drittanbieter-Agenten. SAP begründet das mit der notwendigen Governance einer mandantenfähigen Plattform. Ergänzt wird das durch den SAP AI Agent Hub, eine herstellerunabhängige Kontrollebene, um SAP- und Nicht-SAP-Agenten sowie MCP-Server zu entdecken, zu inventarisieren und zu steuern, mit Richtlinien dafür, welcher Agent auf welche Daten und Prozesse zugreifen darf.

2. Salesforce, der offene Weg über Headless 360. Salesforce hat mit Headless 360 eine Architektur vorgestellt, in der Daten, Workflows und Aktionen über Schnittstelle, MCP-Werkzeug oder Kommandozeile zugänglich sind. Eine Vielzahl von MCP-Werkzeugen ist aus verschiedenen Agenten-Laufzeiten heraus nutzbar, ohne dass eine herstellereigene KI-Oberfläche zwingend als Tor vorgeschaltet ist.

3. ServiceNow, der offene Weg über Action Fabric. ServiceNow hat mit Action Fabric langjährig gewachsene Workflows, Playbooks, Genehmigungsketten und Geschäftsregeln über Schnittstellen und MCP für beliebige KI-Agenten geöffnet. Die Logik der jeweiligen Aktion bleibt dabei in der Plattform, der Agent ruft definierte, regelgebundene Aktionen auf.

4. Die gemeinsame Linie und der Unterschied. Salesforce und ServiceNow setzen erkennbar auf ein offenes Modell, in dem die Plattform die Ausführungsschicht ist und die Wahl des Agenten beim Kunden liegt. SAP setzt auf ein kontrolliertes Modell, in dem der plattformeigene Kanal der vorgesehene Weg ist. Beide Ansätze haben eine innere Logik, sie unterscheiden sich aber grundlegend darin, wo die Kontrolle über den Agenten liegt.

4. Wo die Architekturwahl zum Governance-Risiko wird

1. Das geschlossene Modell konzentriert die Kontrolle. Ein kontrollierter Kanal vereinfacht die Governance, weil jeder Zugriff durch eine Instanz läuft. Er verlagert aber die Entscheidungsmacht stärker auf den Plattformbetreiber. Die eigentliche Governance-Frage ist dabei nicht, welches Tor das sicherste ist, sondern ob die Organisation die Wahl behält, ein anderes zu nehmen, denn ein System, das nur einen Weg zulässt, kontrolliert am Ende den, der ihn geht.

2. Das offene Modell verteilt die Verantwortung. Ein offener Zugang gibt dem Kunden Flexibilität und die freie Wahl des Agenten, verlangt aber, dass die Governance beim Kunden selbst entsteht. Ohne eine eigene Kontroll- und Freigabe-Instanz kann die Offenheit zu unkontrollierten Zugriffen führen, gerade wenn viele Agenten parallel auf dieselben Aktionen zugreifen.

3. Der gemeinsame blinde Fleck ist die SAP-Produktion. Unabhängig vom Modell bleibt die Frage, was passiert, wenn ein Agent eine Änderung auslöst, die in einem SAP-System landet. Weder die Offenheit von Salesforce oder ServiceNow noch der kontrollierte Joule-Kanal von SAP ersetzt eine Change-Governance, die das verbindliche Nein vor der SAP-Produktion hält.

4. Nachweispflicht trifft beide Modelle. Ob offen oder geschlossen, die regulatorische Pflicht zum Nachweis bleibt. Es muss nachvollziehbar sein, welcher Agent welche Aktion ausgelöst hat und auf welcher Grundlage sie freigegeben wurde. Diese Spur ist in keinem der beiden Modelle automatisch vollständig, sie muss bewusst hergestellt werden.

5. Ein Bewertungsrahmen für SAP-Organisationen

Die Architekturdebatte ist für SAP-Kunden keine reine Beobachterfrage, weil ihre Landschaften zunehmend SAP- und Non-SAP-Plattformen mischen. Die folgenden Punkte helfen, die eigene Position zu bestimmen.

1. Den Zugangsweg je Plattform klären. Festhalten, über welchen Weg Agenten auf jede beteiligte Plattform zugreifen, kontrolliert über einen herstellereigenen Kanal oder offen über Schnittstellen und MCP. Schon diese Bestandsaufnahme zeigt, wo Kontrolle und wo Offenheit herrscht.

2. Die eigene Governance-Instanz definieren. Unabhängig vom Modell der Plattform braucht es eine eigene Instanz, die entscheidet, welche agentengetriebene Änderung in die Produktion darf. Bei offenen Plattformen ist sie Pflicht, bei geschlossenen ergänzt sie die herstellereigene Kontrolle um die kundenspezifische Sicht.

3. Den Agenten-Bestand inventarisieren. Erfassen, welche Agenten und MCP-Server auf welche Systeme zugreifen, einschließlich herstellerfremder. Ein zentrales Inventar ist die Voraussetzung dafür, Zugriffe überhaupt steuern und nachweisen zu können.

4. Den Nachweis bewusst herstellen. Für jede agentengetriebene Änderung sicherstellen, dass dokumentiert ist, welcher Agent sie ausgelöst hat und wie sie freigegeben wurde. Dieser Nachweis verbindet die Architekturfrage mit dem durchgängigen Audit Trail, den die Regulatorik verlangt.

5. Die SAP-Produktion eigenständig absichern. Den Weg einer agentengetriebenen Änderung in die SAP-Produktion durch dieselbe Change-Governance führen wie jede andere Änderung. Die Architektur der Agenten-Plattform ersetzt diese Kontrolle nicht.

6. Tool Landscape

Die folgende Tabelle stellt die drei Plattform-Ansätze gegenüber und führt zum Kontrast die SAP-seitige Change-Governance mit. Sie zeigt, dass die Architektur des Agenten-Zugangs und die Kontrolle der SAP-Produktion zwei unterschiedliche Fragen sind.

¹ Solutive AG ist Initiator des Change Orchestration Institute. Die Bewertung in der Tabelle ist eine Selbstauskunft des Anbieters und nicht Teil einer redaktionell unabhängigen Validierung. Der Orchestration Layer ist keine Agenten-Plattform, sondern adressiert die Change-Governance vor der SAP-Produktion. Er steht in der Tabelle zum Kontrast, nicht als gleichartige Alternative zu den drei Plattform-Ansätzen.

Die Tabelle macht deutlich, dass keine der Agenten-Plattformen die SAP-spezifische Change-Governance ersetzt. SAP, Salesforce und ServiceNow beantworten die Frage des Agenten-Zugangs, aber die Frage, ob eine agentengetriebene Änderung in die SAP-Produktion darf, liegt auf einer eigenen Ebene. Eine vollständige Governance kombiniert die Zugangsarchitektur der Plattformen mit einer eigenständigen Change-Governance auf der SAP-Seite.

7. Operative Konsequenzen für SAP-Organisationen

Aus der Architekturdebatte ergeben sich konkrete Schritte.

Die erste Konsequenz betrifft die Klarheit über die Modelle. SAP-Organisationen sollten wissen, dass die von ihnen genutzten Plattformen unterschiedliche Agenten-Architekturen verfolgen, kontrolliert bei SAP, offen bei Salesforce und ServiceNow. Diese Klarheit ist die Grundlage jeder weiteren Entscheidung.

Die zweite Konsequenz betrifft die eigene Kontrolle. Unabhängig vom Modell der Plattform braucht es eine eigene Governance-Instanz für agentengetriebene Änderungen, besonders dort, wo offene Plattformen die Verantwortung bewusst zum Kunden verschieben.

Die dritte Konsequenz betrifft den Nachweis. Die regulatorische Pflicht, agentengetriebene Änderungen nachvollziehbar zu machen, gilt in beiden Modellen und muss bewusst umgesetzt werden, nicht als automatisches Nebenprodukt der Plattform erwartet.

Die vierte Konsequenz betrifft die SAP-Produktion. Der Weg einer agentengetriebenen Änderung in ein SAP-Produktivsystem gehört durch dieselbe Change-Governance geführt wie jede andere Änderung, denn die Zugangsarchitektur der Agenten-Plattform und die Kontrolle der SAP-Produktion sind zwei verschiedene Aufgaben.