Joule Work wird ausgerollt. Offene Protokolle ersetzen keine Architekturentscheidung.

SAPs Ankündigungen vom Oktober markieren eine echte Veränderung. Joule Work und Joule Studio sind nicht mehr nur Punkte auf der Roadmap: Ihre allgemeine Verfügbarkeit wird schrittweise eingeführt. A2A und MCP sollen Agenten über SAP- und Nicht-SAP-Systeme hinweg verbinden. Für mittelständische Unternehmen ist die entscheidende Frage nicht, ob SAP diesen Monat „offener“ geworden ist. Sondern welche Architektur zur eigenen Systemlandschaft, zur Datengrenze und zur jeweiligen Aufgabe passt.

Die Antwort ist dadurch nicht einfacher geworden. Ein schrittweiser Rollout bedeutet keine universelle Verfügbarkeit. Protokollunterstützung liefert keine Geschäftssemantik. Und ein Agentenframework entscheidet nicht darüber, wer eine Geschäftstransaktion verändern darf. Dieser Beitrag trennt die Ankündigungen von diesen Umsetzungsfragen.

Was sich im Oktober geändert hat

SAPs Release-Highlights zu Q3 und der TechEd Innovation News Guide bestätigen die schrittweise allgemeine Verfügbarkeit von Joule Work und Joule Studio. Joule Work ist die Interaktionsschicht, über die Menschen ein Ergebnis beschreiben und Assistenten spezialisierte Agenten koordinieren. Joule Studio ist die Umgebung zum Bauen, Testen, Bereitstellen und Steuern eigener Agenten und Skills.

Beide Produkte beantworten unterschiedliche Fragen. Joule Work betrifft die Zusammenarbeit von Menschen und Agenten im Arbeitsablauf. Joule Studio betrifft den Bau und die Kontrolle eigener Agentenfunktionen. Eines davon kann relevant sein, ohne dass sofort auch das andere benötigt wird.

Auch die Steuerung wird konkreter. SAP beschreibt in seiner TechEd-Ankündigung für Entwickler die Joule-Studio-Laufzeit, Tests vor der Bereitstellung, Beobachtbarkeit von Agenten und den kontrollierten Aufruf von Joule Agents durch externe Agenten über ein Agent Gateway. SAP AI Agent Hub wird als allgemein verfügbar bezeichnet. Das separate SAP Enterprise AI Gateway ist erst für Q1 2027 geplant und darf in einer heutigen Architektur nicht vorausgesetzt werden.

Was der Rollout für ECC und On-Premise-S/4HANA nicht bedeutet

Die Oktober-Meldungen zur allgemeinen Verfügbarkeit beseitigen nicht die Bedingungen für klassische Systemlandschaften. SAPs Ankündigung vom Mai besagt, dass ECC- und On-Premise-S/4HANA-Kunden auf ausgewählte KI-Szenarien zugreifen können, wenn sie sich zur Überführung des Großteils ihrer bestehenden Landschaft zu SAP Cloud ERP verpflichten.

Das sind zwei unterschiedliche Aussagen: Joule Work und Joule Studio werden eingeführt, und für ausgewählte Szenarien auf ECC und On-Premise-Systemen gilt eine Cloud-Überführungsbedingung. Aus der ersten Aussage folgt kein uneingeschränkter nativer Zugriff auf die zweite Systemgruppe. Bis zum 29. Oktober haben wir keine primäre SAP-Quelle gefunden, die diese Bedingung aufhebt.

Vor Projektbeginn sollten SAP oder der Implementierungspartner die Antwort für Ihre Landschaft schriftlich präzisieren: welcher Assistent oder Agent, auf welchem Release, in welchem Cloud- und Vertragsmodell, mit welcher Backend-Anbindung und ab welchem Datum. „Joule ist allgemein verfügbar“ reicht für eine Entscheidung über ECC, Business One, hybride oder Nicht-RISE-Systeme nicht aus.

MCP verbindet Werkzeuge. A2A koordiniert Agenten. Beides ersetzt kein Kontrollmodell.

SAPs Architecture Center formuliert diesen Punkt sehr deutlich. MCP standardisiert, wie ein Agent Werkzeuge findet und aufruft; es liefert weder SAP-Geschäftssemantik noch eine Garantie für korrekte Transaktionen. Für die Zusammenarbeit mehrerer Agenten empfiehlt SAP A2A über sein Agent Gateway.

Externe und kundenseitig betriebene MCP-Server sind möglich, doch SAP macht die Verantwortlichkeiten ausdrücklich sichtbar. Die SAP-API-Policy gilt. Jede Verbindung braucht Authentifizierung und Autorisierung. Tokens müssen gegen begrenzte Berechtigungen getauscht statt weitergegeben werden. Eingaben müssen validiert, APIs müssen mit Ratenlimits und Timeouts abgesichert und produktive Aufrufe müssen protokolliert werden. Protokollkompatibilität deckt diese Arbeit nicht ab.

Bei einem Schreibzugriff kommt eine weitere Entscheidung hinzu. Wer hat die Transaktion freigegeben? Welche Geschäftsregel wurde geprüft? Sieht der Agent nur die benötigten Felder? Erstellt er einen Entwurf, reicht er zur Freigabe ein oder bucht er direkt? Ein Konnektor kann eine Funktion bereitstellen; er kann nicht entscheiden, ob deren Freigabe sinnvoll ist.

Strukturierte SAP-Daten brauchen mehr als eine Chat-Oberfläche

SAP hat außerdem seine tabellarischen Modelle erweitert. Der TechEd Guide führt SAP-RPT-TS für Zeitreihenprognosen als allgemein verfügbar. SAP-RPT-Decisions ist für Q4 2026 geplant, SAP-RPT-2 mit Verarbeitung mehrerer Tabellen und Anomalieerkennung für Q1 2027. Diese Daten sind wichtig: verfügbar, für dieses Quartal geplant und für nächstes Jahr geplant sind unterschiedliche Grundlagen für einen Business Case.

Für operative Teams ist das relevant, weil ihre Arbeit häufig mit strukturierten Exporten beginnt: fehlgeschlagene IDocs, unbestätigte Bestellungen, gesperrte Lieferungen, Rechnungsdifferenzen. Ein Modell kann klassifizieren, Anomalien erkennen oder eine Diagnose unterstützen. Das brauchbare Ergebnis hängt weiterhin von begrenzten Eingangsdaten, dem richtigen Geschäftskontext und einer nächsten Handlung ab, die ein Mensch prüfen kann.

Ein praktischer Entscheidungsrahmen

Beginnen Sie mit der Aufgabe, nicht mit dem Produktnamen. Prüfen Sie danach vier Randbedingungen in dieser Reihenfolge:

1. Systemlandschaft und Vertragspfad. Nutzen Sie RISE oder GROW, prüfen Sie das konditionierte ECC-Programm oder bleiben Sie vorerst außerhalb von SAPs Cloud-Pfad? Entscheidend ist die Antwort für Ihre Systeme, nicht die Portfolio-Schlagzeile.
2. Daten- und Modellgrenze. Darf der relevante Inhalt Ihre Umgebung überhaupt verlassen? Falls nicht, ist ein verwalteter Agentendienst ein anderer Ausgangspunkt als Modelle in Ihrem Tenant oder On-Premise.
3. Workflow und Systemumfang. Läuft der Prozess vollständig in SAP oder über Dateien, E-Mail, CRM, Business One, ECC und andere Systeme hinweg? Konnektoren und Steuerungsmodell müssen zu diesem Umfang passen.
4. Entscheidungsrisiko. Diagnostiziert und entwirft der Agent nur, oder kann er buchen? Read-only-Diagnose hat eine wesentlich kleinere Fehlerfläche als unbeaufsichtigtes Rückschreiben. Erweitern Sie Berechtigungen erst, wenn Belege das rechtfertigen.

Für SAP-zentrierte Kunden auf RISE oder GROW ist es sinnvoll, Joule zuerst zu prüfen. Für ECC-Kunden, die das konditionierte Programm erwägen, können die ausgewählten Szenarien relevant sein. Für Business One, Systeme ohne diese Verpflichtung, strenge Anforderungen an private Modelle oder systemübergreifende Ausnahmefälle kann eine andere Architektur besser passen. Das ist eine Entscheidung über die Aufgabe, nicht über Anbietertreue.

Wo aplexio hineinpasst

Wir bauen eng begrenzte Agenten für konkrete Prozessprobleme. Unsere aktuelle SAP-Logistik-Diagnose arbeitet auf Exporten und hat keinen Schreibpfad nach SAP. Private Bereitstellung nutzt Open-Weight-Modelle in Ihrem Cloud-Tenant oder Ihrer On-Premise-Umgebung; kein aplexio-Backend erhält die Daten. Wo Joule bereits vorhanden ist, prüfen wir kontrollierte Koexistenz, statt es auszublenden.

Unser Marktüberblick zu SAP-KI-Agenten zeigt, wie SAP und neun unabhängige Anbieter ihre Ansätze selbst beschreiben. Ein konkretes Read-only-Beispiel finden Sie im SAP Logistics Copilot und in der Analyse eines IDoc mit Status 51. Wenn Sie eine Architekturantwort für Ihre eigene Landschaft möchten, bringen Sie den Workflow und seine Randbedingungen mit.