Joule, Agentforce, Copilot: Wann lohnt sich ein eigener Agent?

Wer SAP, Salesforce und Microsoft 365 einsetzt, bekommt KI-Agenten inzwischen praktisch mitgeliefert. SAP baut Joule in seine Anwendungen ein, Salesforce stellt mit Agentforce Agents direkt auf der eigenen Plattform bereit, Microsoft bringt Copilot in Office, Teams und Dynamics 365. Ein eigener Agent wirkt da auf den ersten Blick überflüssig.

Ganz so einfach ist es nicht. Die Antwort hängt weniger an der Qualität der einzelnen Agenten als am Zuschnitt des Prozesses. Dieser Beitrag ordnet ein, wofür die nativen Agenten gemacht sind, wo sie an Grenzen kommen und wie sich beides sinnvoll kombinieren lässt.

Ihr größter Vorteil ist der Kontext. Joule kennt die Anwendungen und das Datenmodell von SAP. Agentforce arbeitet mit Salesforce-Daten, Flows und dem Berechtigungsmodell der Plattform. Copilot greift auf Mails, Dokumente, Chats und Termine in Microsoft 365 zu. Keiner dieser Agenten muss erst lernen, was ein Kundenauftrag oder eine Opportunity ist, denn er sitzt dort, wo die Daten liegen.

Hinzu kommt die Oberfläche. Mitarbeitende bleiben in der Anwendung, die sie kennen, und der Agent erscheint dort als Assistent oder als Aktion. Rollen, Berechtigungen und Datenschutzeinstellungen des Herstellers gelten mit. Betrieb und Weiterentwicklung liegen beim Hersteller.

Für Aufgaben innerhalb eines Systems ist das schwer zu schlagen. Eine Opportunity zusammenfassen, eine Antwort auf eine Serviceanfrage entwerfen, Kennzahlen im ERP abfragen, ein Meeting nachbereiten: Hier lohnt es sich, zuerst zu prüfen, was der native Agent schon leistet, bevor etwas Eigenes entsteht.

Schwieriger wird es, wenn ein Geschäftsprozess Systemgrenzen überschreitet. Order-to-Cash ist dafür ein typisches Beispiel. Die Opportunity wird in Salesforce gewonnen, der Kundenauftrag entsteht in SAP, Rückfragen und Freigaben laufen über Outlook oder Teams. Jeder native Agent sieht seinen Ausschnitt. Den ganzen Prozess sieht keiner.

Drei Punkte wiegen dabei besonders schwer:

• Prozesse über mehrere Systeme: Ein Agent, der für eine Plattform gebaut ist, steuert selten zuverlässig Schritte in anderen Plattformen. Die Übergaben bleiben manuell oder werden mit Einzelintegrationen überbrückt.
• Transaktionen in Fremdsystemen: Daten aus einem anderen System zu lesen, lässt sich meist lösen. Einen SAP-Auftrag aus einem Salesforce-Vorgang heraus anzulegen, mit Prüfung, Freigabe und Schutz gegen doppelte Ausführung, ist eine andere Aufgabe.
• Einheitliche Governance: Jeder Hersteller regelt Berechtigungen, Protokollierung und Freigaben auf seine Weise. Wer drei Agent-Welten betreibt, hat drei Regelwerke und drei Logs. Eine gemeinsame Sicht darauf, was Agenten im Unternehmen tun, fehlt.

Das ist kein Mangel der einzelnen Produkte. Hersteller optimieren für ihre Plattform, und aus ihrer Sicht ist das folgerichtig. Die Lücke entsteht zwischen den Plattformen, also genau dort, wo in vielen Unternehmen der meiste manuelle Aufwand steckt.

voluro Nexus ist die Ausführungs- und Governance-Schicht zwischen Agenten und Enterprise-Systemen. Die nativen Agenten werden dabei nicht abgelöst. Sie lassen sich in Nexus registrieren und als Teilnehmer eines Prozesses einbinden, genauso wie eigene Agenten, etwa auf Basis von LangGraph oder über MCP.

Ein mögliches Zusammenspiel in Order-to-Cash: Agentforce bereitet in Salesforce die gewonnene Opportunity auf. Nexus übernimmt, prüft Geschäftspartner, Preise und Verfügbarkeit in SAP und entscheidet nach Ihren Regeln, ob der Auftrag automatisch angelegt wird, eine Freigabe braucht oder gestoppt wird. Anschließend aktualisiert Nexus die Opportunity, und der Vertrieb wird informiert.

Für alle beteiligten Agenten gelten dieselben Policies und derselbe Audit Trail. Über Governance entscheidet nicht das Sprachmodell, sondern Nexus. Damit bleibt nachvollziehbar, welcher Agent wann welche Aktion in welchem System ausgelöst hat, unabhängig vom Hersteller.

Ein eigener Agent lohnt sich, wenn ein Prozess unternehmensspezifisch ist und kein Hersteller ihn abbildet. Das betrifft oft genau die Stellen, an denen sich ein Unternehmen vom Wettbewerb unterscheidet: eigene Preislogik, besondere Lieferbedingungen, über Jahre gewachsene Ausnahmeregeln.

Auch dann muss nicht alles neu entstehen. Nexus macht aus vorhandenen SAP-OData-Services, Salesforce-Flows, Apex Actions und Custom APIs kontrollierte Agent-Tools, die mehrere Agenten nutzen können. Für Prozesse wie Auftragsbearbeitung oder Lieferausnahmen gibt es Process Packs als fachlich vorbereitete Lösungen, die im Projekt auf die vorhandene Systemlandschaft abgebildet werden.

Die Leitfrage lautet deshalb selten „nativ oder eigen?“. Hilfreicher ist eine andere: Wo endet der Prozess, und wer steuert die Schritte zwischen den Systemen?