Konzeptkarte

Agenten in SAP Build Process Automation

Stand 7. November 2026

Was sind Agenten in SAP Build Process Automation?

Diese Seite ist die praktische Sicht auf einen Weg durch SAP Build with AI: ein Joule-Agent, dessen Aktionsschritt eine Prozessautomatisierung ist, verbunden mit Sub-Agenten, Document Grounding und MCP-Servern und über eine von drei A2A-Integrationsoptionen mit festen Timeouts an Code außerhalb von Joule angebunden. Die Begleitseite zu SAP Build with AI zeigt die gesamte Landschaft.

Design Time und Runtime leben in unterschiedlichen Subaccounts

Ein im Agent Builder von Joule Studio gebauter Agent wird innerhalb von SAP Build Process Automation entworfen, läuft aber innerhalb einer Joule-Instanz — und SAPs eigener Beispielcode macht ausdrücklich klar, dass dies häufig zwei unterschiedliche Subaccounts der SAP Business AI Platform sind. Besteht diese Trennung, muss jede BTP-Destination, von der der Agent abhängt — etwa die Zugangsdaten eines MCP-Servers —, identisch in beiden Subaccounts angelegt werden: einmal für SAP Build Process Automation zur Design-Zeit, einmal für die Joule-Instanz zur Laufzeit. Wird eine davon vergessen, scheitert das Deployment nicht leise; SAPs dokumentierter Fehlerfall ist ein konkreter Fehler, Failed to create agent using mass deploy content due to exception... (error code: Tenant Administration Worker - 6011), der wie ein Infrastrukturproblem wirkt, aber fast immer eine fehlende Destination in einem der beiden Subaccounts ist. „SAP Build with AI — Joule in Build Code, Build Apps, Process Automation und Joule Studio“ behandelt die breitere SAP-Build-with-AI-Landschaft — Build Code, Build Apps, Process Automation, beide Editionen von Joule Studio; diese Seite bleibt innerhalb des Process-Automation- und Agent-Builder-Ausschnitts.

Warum es zählt

Ein Berater, der nur den Überblick zu SAP Build with AI kennt, kann einen Deployment-Fehler Tenant Administration Worker - 6011 nicht beheben – dafür braucht es die hier dokumentierte Trennung der Subaccounts für Design-Time und Runtime.
Das Muster „Prozessautomatisierung innerhalb einer Skill“ ist die dokumentierte Antwort auf eine Frage, die jeder Agentenbau irgendwann stellt: Wo findet eine Schreibaktion tatsächlich statt, und wie wird sie auditiert und wiederholt?
A2A für eine Aufgabe zu wählen, die legitim länger als eine Minute dauert, erzeugt ein festes, nicht debugbares Zeitlimit; die drei Integrationsformen vorab zu kennen, erspart eine Neugestaltung mitten im Projekt.

Kernpunkte

Joule-Agenten werden in SAP Build Process Automation (Agent Builder von Joule Studio) entworfen, laufen aber in einer Joule-Instanz — oft einem anderen BTP-Subaccount.
Destinations (z. B. MCP-Server-Zugangsdaten) müssen in beiden Subaccounts dupliziert werden; eine fehlende zeigt sich beim Deployment als „Tenant Administration Worker - 6011“, nicht als benannte fehlende Destination.
SAPs eigenes Referenzmuster für eine Schreibaktion: eine aus einer Skill heraus aufgerufene Prozessautomatisierung, kein bloßer REST-Aufruf des Agenten.
Multi-Agenten-Design: Ein Root-Agent orchestriert spezialisierte Unteragenten (z. B. Richtlinienprüfung, Suche, Datensatzverwaltung), jeweils unabhängig im Agent Builder konfiguriert und testbar.
Web-/externer Werkzeugzugriff in Joule-Agenten läuft über als BTP-Destinations registrierte MCP-Server.
Codebasierte Agenten außerhalb von Joule erreichen: direktes A2A (1-Minuten-Zeitlimit), asynchrone REST-API (5-Minuten-Zeitlimit), oder ein zwischengeschalteter A2A Client Service mit Streaming für längere Aufgaben.
Codebasierte Agenten werden typischerweise mit dem SAP Generative AI Hub, dem SAP Cloud SDK for AI und einem Framework wie LangGraph gebaut.
Diese Seite behandelt den Process-Automation-/Agent-Builder-Ausschnitt; „SAP Build with AI – Joule in Build Code, Build Apps, Process Automation und Joule Studio“ behandelt die gesamte Landschaft (Build Code, Build Apps, beide Joule-Studio-Editionen).

Begriffe auf dieser Seite

Agent Builder: Die Joule-Studio-Fähigkeit zum Zusammenstellen von Joule-Agenten aus Skills, Anweisungen und Unteragenten.
Destination: Ein BTP-Konfigurationsobjekt mit Verbindungsdetails (z. B. Zugangsdaten eines MCP-Servers), das sowohl im Design-Zeit- als auch im Laufzeit-Subaccount existieren muss.
Root-Agent / Unteragent: Ein Multi-Agenten-Design, bei dem ein orchestrierender Agent spezialisierte Aufgaben an unabhängig konfigurierte Unteragenten delegiert.
A2A-Protokoll (Agent-to-Agent): Das Protokoll, mit dem Joule einen externen, codebasierten Agenten direkt aufruft; in SAPs dokumentiertem Beispiel auf ein Ein-Minuten-Anfrage-Zeitlimit gedeckelt.
A2A Client Service: Ein zwischengeschalteter Streaming-Dienst zwischen Joule und einem codebasierten Agenten zur Unterstützung lang laufender Aufgaben ohne festes Zeitlimit.
Tenant Administration Worker - 6011: Der Fehlercode, den SAPs Beispiel für einen Mass-Deploy-Fehler dokumentiert, typischerweise verursacht durch eine in einem der beiden Subaccounts fehlende Destination.

Quellen

Vollständige Karte im Consultant-Tarif — 19,90 €/Monat. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →

Redaktion: Cédric Mary · Wie diese Seite entsteht

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.