Wer den ERP-Agent-Gateway kontrolliert, besitzt die Workflows

Vergessen Sie den Chat als Statussymbol. Die harte Wahrheit lautet: Wer den ERP-Agent-Gateway kontrolliert, besitzt die Enterprise-Workflows. Nicht die Folie. Nicht den Demo-Agenten in Teams. Den Prozess.

Microsoft und SAP koppeln Microsoft 365 Copilot und Joule über Agent-to-Agent. Aufgaben starten in Word oder Teams – und landen in S/4HANA oder SuccessFactors. Copilot ist kein reines Gesprächsfenster mehr. Das System of Record wird zur Ausführungsschicht für fremde Agenten. Punkt.

Hand aufs Herz: Wer nur Microsoft-365-Agenten skaliert und den SAP-Gateway ignoriert, automatisiert die Slide – nicht den Prozess. Das klingt hart. Es ist gemeint.

Agent Gateway: Discovery und Execution in einer Schicht

Klartext zur Definition, zitierfähig: Das Agent Gateway (SAP) ist die zentrale Integrationsschicht für Discovery und Execution agentischer Ressourcen. Es übernimmt Authentifizierung, Principal Propagation, Policy Enforcement und Tenancy. Sowohl Joule als auch andere Agenten greifen auf Tools und Business-Capabilities über dieses Gateway zu – nicht am Rand vorbei, sondern durch die Schicht hindurch.

Genau.

Ohne Gateway keine kontrollierte Discovery. Ohne Gateway keine einheitliche Execution. Ohne Gateway keine belastbare Aussage darüber, wer im Namen wessen handelt. Das ist Architektur, keine Marketing-Folie. Wer „Agenten überall“ ruft und die Integrationsschicht überspringt, baut Parallelwelten. Die brechen später teuer.

Seien wir ehrlich: Viele Programme kaufen zuerst den sichtbaren Copilot-Einstieg und behandeln ERP wie eine Datenquelle für schöne Antworten. Funktioniert nicht – jedenfalls nicht, wenn Buchung, Freigabe, Personalakte oder Lieferkette wirklich bewegt werden sollen. Die harte Wahrheit: Chat ohne Execution-Schicht ist Theater.

Auf digital-magazin.de trennen wir bewusst Layer. Persönliche Agenten können die Kundenreise auf einem Secure Layer erledigen – Mail, Buchung, Zahlung –, während die Enterprise-Ticket-Queue noch wartet; die Einordnung zur Muse-Layer-Logik und Queue-Kundenreise zeigt, warum der falsche Layer teuer wird. Derselbe Fehler droht jetzt innen: Copilot skaliert, Gateway fehlt.

Was heißt Principal Propagation hier konkret? Der Agent handelt nicht „als System“, sondern in einer nachvollziehbaren Kette: jemand startet Intent, etwas führt aus, Rechte werden weitergereicht – und am Ende muss ein Audit sagen können, wer was unter welcher Identität getan hat. Fehlt Propagation, bricht die Kette. Dann raten Sie hinterher. Raten ist kein Betrieb.

Policy Enforcement am Gateway ist der Gegenpol zu „der Agent war kreativ“. Kreativität ohne Policy ist Risiko. Policy ohne Discovery ist Blindflug. Beides zusammen – Discovery und Execution unter Policy – ist der Job der Schicht. Tenancy gehört dazu: Welche Mandanten, welche Boundaries, welche Datenräume? Wer Tenancy „später“ plant, mischt Kontexte. Das wird teuer und peinlich.

Ein-Wort-Check für Architektur-Reviews: Gateway?

Wenn die Antwort zögert, besitzen Sie den Workflow nicht. Sie besitzen eine Sammlung von Assistenten. Assistenten erklären. Workflows ändern Buchungen, Status, Freigaben. Unterschied.

Sapphire: A2A verbindet Copilot und Joule

Auf der SAP Sapphire 2026 haben Microsoft und SAP die Richtung verschärft. Im Azure-Blog zu den SAP-on-Azure-Ankündigungen von Sapphire 2026 steht die Agent-to-Agent-Integration zwischen Microsoft 365 Copilot und Joule klar: connected AI über Microsoft 365, nicht isolierte Assistenten-Inseln.

Was heißt das praktisch? Business-Kollaboration läuft ohnehin in Microsoft 365 – Teams-Chats zu Supply Chain, Finance, Sales; Mails an Kunden und Lieferanten. A2A soll Joule und Copilot agentische Flows mit der kollektiven Intelligenz von Microsoft Work IQ und SAP Knowledge Graph fahren. Kontext statt Copy-Paste zwischen Systemen.

Ein konkretes Beispiel aus dem Azure-Text: Performance Reviews vorbereiten, starten in Microsoft 365 Copilot in Word, SAP-gelieferte Joule-Skills für S/4HANA oder SuccessFactors nutzen, das 1:1 mit der Führungskraft im selben Interface terminieren. Kein Wechselspiel aus Screenshot, Excel-Export und Hoffnung. Eine Oberfläche – Execution im System of Record.

Dazu die Plattform-Kopplung: Joule verbindet sich mit Teams, Fabric und Copilot. Die Cloud Acceleration Factory weitet die Copilot–Joule-Anbindung in RISE- und GROW-Umgebungen aus. Erste agentische Use Cases laufen über Copilot Studio oder Foundry. Das ist kein Nebenprojekt für Innovationstheater. Das ist der Versuch, Produktivitätsschicht und ERP-Execution zu verheiraten.

Falsch wäre, das als „noch ein Chat-Plugin“ zu lesen. Richtig ist: Fremde Agenten dürfen – über Standards und Gateway – im ERP handeln. Wer das als UX-Thema abtut, unterschätzt den Machtwechsel.

Meine Einschätzung: Wer Sapphire nur als Partnership-PR abhakt, verpasst den Kontrollpunkt. A2A ohne Gateway-Ownership ist ein Vertrag ohne Schlüsselbund.

Cloud Acceleration Factory klingt nach Programmname. Operativ heißt es: RISE- und GROW-Kunden sollen Copilot und Joule früher koppeln – Daten, Workflows, Produktivität von Tag eins. Azure Accelerate nennt erste agentische Use Cases über Copilot Studio oder Foundry. Gut. Aber Studio ohne Gateway-Klarheit produziert schnelle Demos und langsame Produktion.

Teams, Fabric, Copilot – die Microsoft-Seite der Gleichung – ist der Ort, an dem Menschen schon arbeiten. S/4HANA und SuccessFactors sind der Ort, an dem das Unternehmen rechtlich und operativ gebunden ist. A2A ist die Brücke. Das Gateway ist die Zollstelle auf der Brücke. Wer die Zollstelle nicht besetzt, lässt alles durch – oder nichts. Beides schlecht.

Genau deshalb ist die Sapphire-Story gefährlich und nützlich zugleich. Nützlich, weil sie den Execution-Anspruch öffentlich macht. Gefährlich, weil Erwartung vor Capability rennt. Lesen Sie Ankündigung und Architecture-Disclaimer parallel. Nicht nacheinander, wenn das Budget schon verbrannt ist.

Was sich für die ERP-Execution ändert

Bisher war die Trennung bequem: Copilot schreibt, Menschen klicken im ERP. Die neue Logik bricht das. Der Agent startet dort, wo gearbeitet wird – Word, Teams – und greift auf Skills zu, die Buchungen, Stammdaten und HR-Prozesse im System of Record anfassen.

S/4HANA ist dann nicht mehr die „Quelle für den schönen Absatz“. SuccessFactors ist nicht mehr die Excel-Hintertür für Reviews. Beides wird Execution Layer. Das verändert Freigaben, Audit, Rollen und Betriebsmodell. Schluss damit, Agenten nur als Schreibhilfe zu budgetieren.

Das Problem dabei: Viele Organisationen skalieren zuerst die sichtbare Seite – Lizenzen, Studio-Templates, Teams-Apps – und lassen Identity, Policy und Tenancy am Gateway unklar. Dann landet die Automatisierung auf der Folie. Der Prozess bleibt manuell. Genau das passiert, wenn Agentforce-ähnliche Ticket-Handoffs ohne saubere Workflow-Grenze gebaut werden; wer den Agentforce-Workflow beim Ticket-Handoff kennt, weiß: ohne klare Übergabe wird Automatisierung zur Warteschlange mit KI-Label.

Nein.

Sie brauchen eine klare Antwort auf drei Fragen. Wer darf Skills entdecken? Wer darf sie ausführen? Unter welcher Identität – Nutzerkontext oder technische Agenten-Identität? Fehlt eine der drei, bleibt Copilot höflich. ERP bleibt stumm.

Und jetzt die unangenehme Variante: Wenn Joule Skills in S/4HANA schreiben und Copilot den Einstieg steuert, sitzt die Governance nicht mehr nur in SAP-Rollen. Sie sitzt an der Schnittstelle. Am Gateway. Wer diese Schicht nicht besitzt – fachlich, technisch, organisatorisch –, besitzt den Workflow nicht. Punkt.

Performance Review als Beispiel ist absichtlich „weich“ gewählt – HR, Word, Kalender. Übertragen Sie dasselbe Muster auf Finance, SCM, Spend. Derselbe Mechanismus: Intent in M365, Skill im SAP-System, Termin oder Freigabe im selben Flow. Die Organisationsfrage bleibt: Wer genehmigt Agent-Schreibzugriff? Wer reviewed Logs? Wer stoppt einen Agenten, der außerhalb der Schnittmenge der Rechte operiert?

Viele IT-Landschaften antworten noch mit „Wir haben Rollen in SAP“ und „Wir haben Conditional Access in Entra“. Beides nötig. Beides unvollständig, wenn der Hop zwischen Copilot und Joule keine Gateway-Policy sieht. Die Schnittmenge Nutzer ∩ Agent entsteht nicht von allein. Sie wird enforced – oder sie existiert nur auf der Folie.

Falsch.

„Wir automatisieren erst die Dokumentation, Execution kommt später“ klingt vorsichtig. In Wahrheit zementiert es den falschen Layer: Copilot wird Content-Maschine, ERP bleibt Klickarbeit. Später umzubauen kostet mehr als früh zu steuern.

Inbound, Outbound, MCP: Gateway, Copilot und Joule in beide Richtungen

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2PromptPhotorealistic editorial still life: whiteboard architecture sketch of a central gateway hub as soft glowing nodes linking a laptop and tablet on a glass meeting-room wall, markers and sticky notes, Copilot-to-ERP workflow metaphor without brand marks, no readable diagram text, no logos, business magazine style, soft daylight, 16:9

Die SAP-Referenzarchitektur zu Agentic AI – aktualisiert rund um den 27. August 2026 – sortiert das Feld nüchtern. Joule Work ist der Ort, an dem Intent ausgedrückt und orchestriert wird. Joule Assistants koordinieren über Funktionen hinweg. Joule Agents erledigen die konkreten Mehrschritt-Aufgaben. Custom-Agenten von Kunden, Partnern oder LoB-Teams docken über offene Standards an: A2A für Agent-zu-Agent, MCP für Tool-Konnektivität.

Kern der Integrationslogik bleibt das Agent Gateway: Discovery plus Execution, zentral für Authentifizierung, Principal Propagation, Policy und Tenancy. Sowohl Joule als auch Agenten verbinden Tools und Capabilities darüber. Das ist die zitierfähige Definition in einem Satz – und die harte Wahrheit für Architekturentscheidungen.

Inbound: Drittparteien – etwa Microsoft Copilot Studio – konsumieren Joule Agents über das Gateway via A2A. Outbound: Joule orchestriert externe A2A-Agenten. Zusätzlich MCP: semantische Tool-Anbindung; im SAP-Kontext auch über MCP Gateway in der Integration Suite für governed Tool-Zugriff ohne Eigenbau-Server.

LeanIX AI Agent Hub kommt als vendor-agnostisches Command Center dazu: Registry für Agenten, LLMs und MCP-Server, Verifikation, Identity/Access, Observability. Wer Open-Source-Agenten in die Enterprise-Landschaft zieht – LangChain, LlamaIndex und Co. –, braucht genau solche Governance-Anker; die Einordnung zu Open-Source-Agenten im Enterprise mit LangChain und LlamaIndex zeigt die gleiche Schnittstelle: Frameworks sind frei, Execution ohne Policy ist es nicht.

Identity ist der Hebel, den viele unterschätzen. Zwei Modelle: Agenten im Nutzerkontext (mit agentenspezifischen Constraints) und autonome Agenten mit eigener technischer Identität, Token und Audit-Trail. Die effektive Berechtigung zur Laufzeit ist die Schnittmenge aus Nutzerrechten und Agentenrechten – enforced am Gateway bei jedem Hop. Schnittmenge. Nicht Maximum. Nicht „irgendwie Trust“.

Wer das ignoriert, baut Agenten, die theoretisch alles dürfen und praktisch nichts Belastbares dürfen – oder umgekehrt: technische Identitäten, die zu weit greifen. Beides ist schlecht. Schluss damit, Identity als Nachziehprojekt zu planen.

Die Tabelle ist Absicht: ein Blick, drei Wahrheiten. Gateway = Kontrolle. A2A = Richtung. Identity = Schnittmenge. GA = ehrlich bleiben.

Inbound und Outbound sind keine Synonyme für „Integration“. Inbound heißt: externe Plattformen – Copilot Studio, Vertex, Bedrock und andere – delegieren SAP-spezifische Aufgaben an Joule Agents, Trust über Cloud Identity Services. Outbound heißt: Joule steuert externe A2A-Agenten, inklusive sync, async Callbacks und Multi-Turn. Wer beides in einem Pilot ohne getrennte Risikoanalyse mischt, verdoppelt die Angriffsfläche und halbiert die Nachvollziehbarkeit.

MCP ist Tool-Semantik. A2A ist Agent-Kollaboration. Wer MCP wie A2A behandelt, verwechselt Schraubenzieher mit Bauleitung. Tools erweitern Fähigkeiten. Agenten orchestrieren Schritte. Das Gateway muss beides kennen – und entscheiden dürfen, was in Produktion darf.

LeanIX AI Agent Hub hilft beim Inventar: Was existiert? Was ist verifiziert? Welche MCP-Server sind freigegeben? Observability mit Session-Health und Tool-Call-Tracing ist kein Luxus. Ohne Tracing erklären Sie Vorfällen mit Bauchgefühl. Bauchgefühl überzeugt weder Audit noch Vorstand.

Transitional – nicht verkaufen, was noch nicht GA ist

Jetzt der Disclaimer, den Verkäufer gerne klein drucken: Laut SAP Architecture Center ist die bidirektionale Kommunikation mit Dritt- und Self-hosted-Agenten über das Agent Gateway noch nicht vollständig generally available. Die Referenzarchitektur beschreibt einen transitionalen Zustand. Bausteine sind sichtbar. Die volle Bidirektionalität steht aus und soll die Architektur weiterentwickeln.

Das ist keine Fußnote. Das ist Betriebsrisiko.

Wer Roadmaps als GA verkauft, erzeugt Erwartungsschulden. Wer Piloten baut, als wäre Inbound und Outbound schon überall produktiv, riskiert Shadow-Integrationen. Seien wir ehrlich: Architecture Center und Marketing-Slide sind zwei Dokumente. Lesen Sie beides. Glauben Sie dem Disclaimer.

Die kanonische Quelle für Definition, Inbound/Outbound, MCP, LeanIX-Hub und den GA-Hinweis ist die Seite Agentic AI & AI Agents im SAP Architecture Center. Einmal. Klar. Ohne Wunschdenken.

Meine zweite Einschätzung: Die Übergangsphase ist der eigentliche Test. Wer jetzt Ownership am Gateway klärt – Rollen, Policies, Tenancy, Observability –, gewinnt Zeit. Wer wartet, bis „alles GA“ auf der Keynote steht, automatisiert weiter die Präsentation.

Funktioniert nicht als Strategie: „Wir skalieren Copilot Studio und schauen später auf SAP.“ Später ist genau der Moment, in dem fremde Agenten schon Schreibzugriff erwarten und niemand die Schnittmenge der Rechte erklärt.

Transitional heißt: Sie dürfen Architektur lernen und Piloten bauen. Sie dürfen nicht so tun, als wäre volle Bidirektionalität bereits überall Produktstandard. Verträge, SLAs und Betriebsmodelle müssen den Disclaimer aushalten. Wenn ein Partner „fertig integriert Copilot–Joule A2A in beide Richtungen über Gateway“ verkauft, fragen Sie nach GA-Scope. Konkret. Pro Capability. Pro Richtung.

Die harte Wahrheit: Übergangsphasen belohnen die, die Ownership früh klären, und bestrafen die, die Feature-Listen sammeln. Feature-Listen ohne Gateway-Betrieb sind Sammelalben. Schön. Nutzlos im Incident.

Wer nur M365-Agenten skaliert, verfehlt den Prozess

Provokation, absichtlich: Wer Copilot-Agenten in Microsoft 365 skaliert und den SAP-Gateway links liegen lässt, automatisiert die Slide. Nicht den Prozess.

Warum? Weil der Engpass nicht die Formulierung der Review ist. Der Engpass ist die belastbare Aktion in SuccessFactors oder S/4HANA – unter Audit, unter Rollen, unter Tenancy. Ohne Gateway bleibt die schöne Word-Session eine Geschichte. Mit Gateway wird sie Workflow.

Das gilt auch, wenn Zulieferketten und Modell-Infrastruktur wackeln. Wer die Abhängigkeiten in der KI-Zulieferkette kennt – etwa die Debatte um NVIDIA, Hugging Face und die Zulieferkette –, weiß: Kontrolle sitzt selten dort, wo die Demo glänzt. Sie sitzt an den Engpässen. Hier ist der Engpass das Agent Gateway.

Open-Source-Agenten-Stacks ändern daran wenig. NemoClaw und Co. liefern Bausteine; Enterprise-Execution braucht trotzdem Discovery, Policy und Identity. Die Linie von digital-magazin.de zu NVIDIA NemoClaw und Open-Source-Agenten ist dieselbe: frei bauen ja – unkontrolliert ausführen nein.

Was also tun, ohne Vaporware zu kaufen?

Erstens: Gateway-Ownership festnageln. Wer ist fachlich verantwortlich? Wer technisch? Wer für Policy und Tenancy? Ein Name. Kein Komitee-Nebel.

Zweitens: Use Cases vom System of Record rückwärts denken. Nicht „Was kann Copilot schön erzählen?“, sondern „Welche Aktion in S/4 oder SuccessFactors ist freigabefähig – und unter welcher Schnittmenge der Rechte?“

Drittens: A2A-Richtungen getrennt planen. Inbound (Copilot Studio konsumiert Joule Agents) ist ein anderes Risiko als Outbound (Joule orchestriert externe Agenten). MCP ist Tool-Zugriff, kein Freifahrtschein.

Viertens: GA-Status je Capability tracken. Sapphire-Ankündigung ≠ überall GA. Architecture-Disclaimer lesen. Pilotgrenzen schriftlich ziehen.

Fünftens: Observability und Hub ernst nehmen. LeanIX AI Agent Hub ersetzt das Gateway nicht – aber ohne Registry und Verifikation wissen Sie nicht, was in Produktion ruft.

Und die rhetorische Frage, die im Steering Committee hängen bleiben sollte: Besitzen Sie den Workflow – oder nur den Chat, der über den Workflow spricht?

Wenn die Antwort „Chat“ lautet, skalieren Sie Theater. Wenn die Antwort „Gateway“ lautet, skalieren Sie Execution. dazwischen liegt viel Budgetverschwendung.

Klartext für Budgetrunden: Lizenzen für Copilot und Studio ohne Gateway- und Identity-Programm sind halbe Automatisierung. Halbe Automatisierung fühlt sich modern an und liefert manuelle Nacharbeit. Schluss damit.

Auf digital-magazin.de bleiben wir bei dieser Linie: Layer trennen, Engpässe benennen, GA ehrlich markieren. Copilot ist Einstieg. Joule orchestriert. Das Gateway entscheidet, ob daraus Enterprise-Workflow wird – oder eine gut formulierte Illusion.

Hand aufs Herz: In wie vielen Steering Decks steht „100 Copilot-Agenten“ und in wie vielen steht „Gateway-Policy-Owner benannt“? Wenn die erste Zahl groß und die zweite leer ist, automatisieren Sie Folien. Der Prozess bleibt, wo er war – bei Menschen, die nachklicken, nachbuchen, nachkorrigieren.

Das ist keine Anti-Copilot-Haltung. Copilot als Einstieg ist logisch. Menschen arbeiten in Word und Teams. Die These greift erst, wenn Execution im System of Record ohne kontrollierte Schicht erwartet wird. Dann wird aus Produktivität Verantwortung – und Verantwortung braucht Gateway, Identity, Policy.

Drei Anti-Muster, kurz:

Erstens: Studio-Templates kopieren, Skills „irgendwie“ anbinden, Rechte maximal setzen „damit es läuft“. Läuft – bis zum Audit.

Zweitens: Nur Outbound oder nur Inbound denken, das andere als Detail. Detail wird Produktionsstopp.

Drittens: Open-Source-Agenten im BTP-Subaccount feiern und LeanIX/Gateway-Registry überspringen. Feiern Sie ruhig. Registrieren Sie trotzdem.

Wer Zulieferketten-Risiken bei Modellen und Hosting ernst nimmt, sollte Integrations-Risiken am Gateway nicht leichter nehmen. Dieselbe Disziplin. Anderer Engpass.

Was bleibt?

Wer den ERP-Agent-Gateway kontrolliert, besitzt die Enterprise-Workflows. Sapphire 2026 hat Copilot und Joule über A2A zusammengeschoben; Tasks starten in M365 und zielen auf S/4HANA und SuccessFactors. Die Architecture Center-Definition ist klar: Gateway = Discovery und Execution plus Auth, Propagation, Policy, Tenancy. Bidirektionale Drittpartei über dieses Gateway ist laut SAP noch nicht voll GA – transitional, nicht Märchenstunde.

Und jetzt? Benennen Sie den Owner. Ziehen Sie Inbound und Outbound auseinander. Markieren Sie GA ehrlich. Bauen Sie den ersten Use Case vom System of Record rückwärts – nicht vom Chat vorwärts. Dann ist Copilot Einstieg, Joule Orchestrierung, Gateway Besitz.

Der Punkt ist: Workflow-Besitz ist kein Lizenzthema. Es ist ein Kontrollthema. Wer die Schicht besitzt, besitzt die Execution. Wer sie ignoriert, besitzt Präsentationen.

Skalieren Sie also nicht nur den sichtbaren Agenten. Skalieren Sie die Schicht, die entscheidet, was er darf. Punkt.