Salesforce wurde als CRM für Menschen im Browser eingeführt und über Jahre mit ERP, Service und Marketing verbunden. Jetzt kommen Agenten als neue Konsumenten dazu: Agentforce im Inneren, externe Agenten von außen. Dieser Beitrag beschreibt drei Generationen der Salesforce-Integration, was sich ändert, wenn der Konsument ein Agent ist, welche Rolle MuleSoft als Schicht dazwischen spielt und wie ein realistischer Weg in vier Schritten aussieht.
Die meisten Salesforce-Landschaften sind in Schichten gewachsen. Zuerst kam das CRM, eingeführt für den Vertrieb, bedient von Menschen im Browser. Dann wurde es mit dem ERP verbunden, damit Kunden und Aufträge nicht doppelt gepflegt werden müssen. Später kamen Service, Marketing, ein Ticketsystem, ein Dokumentenmanagement und ein Dutzend kleinerer Anwendungen dazu, jede mit ihrer eigenen Schnittstelle.
Diese Architektur hat einen gemeinsamen Nenner: Am Ende jeder Integration sitzt ein Mensch. Die Daten werden synchronisiert, damit ein Vertriebsmitarbeiter im CRM sieht, was im ERP passiert ist. Die Oberfläche, die Berechtigungen, die Antwortzeiten, alles ist auf menschliche Nutzung ausgelegt.
Jetzt kommt ein neuer Konsument dazu. Agentforce arbeitet innerhalb von Salesforce und braucht Zugriff auf Daten außerhalb. Externe Agenten, ob in Slack, im ERP oder in einer eigenen Anwendung, wollen auf Salesforce zugreifen und dort handeln. Beides verändert die Anforderungen an die Architektur grundlegender, als es auf den ersten Blick scheint. Aus der CRM-Integration wird der Einstieg in das agentische Unternehmen.
Drei Generationen der Salesforce-Integration
Wer die eigene Landschaft einordnen will, erkennt meist eine von drei Generationen, oft auch mehrere nebeneinander.
| Generation | Muster | Konsument | Typische Schwäche |
|---|---|---|---|
| Punkt-zu-Punkt | Direkte Verbindungen, Batch-Synchronisation über Nacht, Skripte und Middleware-Jobs | Mensch im Browser | Jede neue Verbindung ist ein eigenes Projekt, Änderungen brechen unerwartet |
| API-geführt | Wiederverwendbare System-, Prozess- und Erfahrungs-APIs, etwa mit MuleSoft | Mensch im Browser, mobile Apps, Portale | Für Agenten fehlen Kontext, Aktionsbeschreibung und feingranulare Berechtigungen |
| Agentisch | APIs mit Bedeutung und Aktionssemantik, Agenten als Konsumenten und Akteure | Agenten innerhalb und außerhalb von Salesforce, daneben weiterhin Menschen | Entsteht gerade, Governance und Betrieb sind noch nicht eingespielt |
Der Übergang von der ersten zur zweiten Generation hat vielen Unternehmen Jahre gekostet. Das Ergebnis waren Schnittstellen, die mehrfach nutzbar sind, Änderungen verkraften und zentral überwacht werden. Welche Best Practices für die Integration von MuleSoft und Salesforce sich dabei bewährt haben, ist gut dokumentiert.
Die gute Nachricht: Wer die zweite Generation erreicht hat, hat das Fundament für die dritte. Die APIs existieren. Was fehlt, ist die Schicht, die sie für Agenten verständlich und sicher macht.
Was sich ändert, wenn der Konsument ein Agent ist
Ein Mensch, der eine Salesforce-Oberfläche nutzt, bringt viel mit, das in keiner API steht. Er weiß, dass ein Rabatt über zehn Prozent eine Freigabe braucht. Er weiß, dass ein Kunde mit offener Eskalation gerade keinen Verkaufsanruf bekommen sollte. Er weiß, welche Felder wichtig sind und welche niemand pflegt. Ein Agent weiß das alles nicht, solange es ihm niemand sagt.
Daraus ergeben sich fünf konkrete Unterschiede:
- Kontext statt Felder. Ein Agent braucht keine Liste von Feldern, sondern eine Beschreibung dessen, was ein Objekt bedeutet und wie es mit anderen zusammenhängt. Eine Opportunity ist für ihn nur dann nützlich, wenn er weiß, zu welchem Konzern der Kunde gehört, welches Angebot offen ist und wer verantwortlich ist.
- Aktionen mit Semantik. Ein API-Endpunkt, der einen Datensatz aktualisiert, sagt nichts darüber, ob diese Aktion rückgängig gemacht werden kann, welche Nebenwirkungen sie hat und ob sie eine Freigabe braucht. Für einen Agenten sind genau diese Informationen entscheidend. Welche Anforderungen Agenten an Enterprise-APIs stellen, geht deutlich über das hinaus, was eine OpenAPI-Spezifikation beschreibt.
- Berechtigungen pro Agent. Ein Agent ist kein Nutzer mit einem Profil. Er handelt im Auftrag verschiedener Nutzer, in verschiedenen Kontexten, mit unterschiedlichen Rechten. Die Berechtigung muss aus dem Kontext kommen, nicht aus einem technischen Konto, das alles darf.
- Antwortzeit und Volumen. Ein Agent ruft in einem Vorgang vielleicht zehn APIs nacheinander auf. Was für einen Menschen bei einem Klick akzeptabel ist, summiert sich beim Agenten zu Wartezeiten, die den Prozess unbrauchbar machen. Gleichzeitig erzeugen Agenten ein Vielfaches an Aufrufen, mit Folgen für API-Limits und Kosten.
- Wiederholbarkeit. Ein Agent, der keine Bestätigung erhält, versucht es erneut. Eine API, die daraus zwei Aufträge macht, ist für Agenten nicht geeignet, selbst wenn sie für Menschen jahrelang funktioniert hat.
Keiner dieser Punkte erfordert, die bestehende Integration wegzuwerfen. Alle fünf erfordern, eine Schicht darüber zu legen, die Agenten das gibt, was Menschen mitbringen.
Salesforce als Quelle, Ziel und Akteur
In einer agentischen Architektur nimmt Salesforce drei Rollen gleichzeitig ein. Das ist neu, denn bisher war es in der Integration fast immer nur Quelle oder Ziel.
Als Quelle liefert Salesforce Kundenkontext an Agenten, die anderswo arbeiten: ein Agent im Servicesystem, der wissen will, ob der Kunde strategisch ist; ein Agent im ERP, der prüft, ob ein Auftrag zu einer gewonnenen Opportunity gehört; ein Assistent in Slack, der CRM-Kontext direkt im Arbeitsalltag verfügbar macht.
Als Ziel nimmt Salesforce Aktionen von Agenten entgegen: Ein Agent legt eine Opportunity an, aktualisiert einen Status, erstellt eine Aufgabe für den Account Manager. Das ist der Bereich, in dem die Fragen nach Berechtigung, Idempotenz und Freigabe am dringendsten sind. Was passiert, wenn Salesforce nicht mehr nur im Browser stattfindet, haben wir bereits beschrieben.
Als Akteur betreibt Salesforce mit Agentforce eigene Agenten, die über die Plattform hinaus auf andere Systeme zugreifen müssen. Ein Agentforce-Agent, der eine Serviceanfrage bearbeitet, braucht Lieferstatus aus dem ERP, Vertragsdaten aus dem Dokumentenmanagement und vielleicht einen Bonitätscheck von einem externen Dienst. Für diese Zugriffe gelten dieselben Anforderungen wie für externe Agenten, nur in umgekehrter Richtung. Ob sich der Einsatz lohnt, ist eine Frage des Business Case für Agentforce, aber die Architektur dafür ist in jedem Fall dieselbe.
Die Schicht dazwischen: Integration, Kontext, Governance
Die Antwort auf alle drei Rollen ist nicht ein neues Produkt, sondern eine Schicht, die zwischen Salesforce, den anderen Unternehmenssystemen und den Agenten liegt. Sie hat drei Aufgaben.
| Aufgabe | Was sie leistet | Werkzeuge und Bausteine |
|---|---|---|
| Integration | Einheitlicher, abgesicherter Zugriff auf alle Systeme, unabhängig davon, ob ein Mensch oder ein Agent aufruft | API-geführte Architektur, MuleSoft als Integrationsplattform, Policies für Limits, Retries und Idempotenz |
| Kontext | Geschäftsobjekte, Beziehungen und Regeln, die Agenten verstehen können | Semantische Schicht über den System-APIs, Tool-Beschreibungen mit Bedeutung und Nebenwirkungen |
| Governance | Wer darf was, mit welcher Freigabe, und wie bleibt es nachvollziehbar | Berechtigungen pro Agent und Kontext, Freigabeschritte, zentrale Protokollierung, Monitoring aller Agentenaufrufe |
MuleSoft spielt in dieser Schicht eine besondere Rolle, weil es bereits in vielen Salesforce-Landschaften die Integration trägt. Die System-APIs, die dort für Menschen und Anwendungen gebaut wurden, sind der Ausgangspunkt. Was dazukommt, ist die Beschreibung dieser APIs als Werkzeuge für Agenten und die zentrale Steuerung, welcher Agent welche Werkzeuge nutzen darf. Wie MuleSoft Agent Fabric diese Orchestrierung angeht, zeigt, wohin sich die Plattform entwickelt.
Entscheidend ist, dass alle drei Aufgaben an einer Stelle liegen. Wenn Agentforce eigene Verbindungen ins ERP bekommt, externe Agenten eigene Verbindungen nach Salesforce und jeder Agent seine eigenen Regeln mitbringt, entsteht die Punkt-zu-Punkt-Landschaft der ersten Generation noch einmal, nur mit Agenten statt Skripten. Die Lehre aus zwanzig Jahren Integration gilt auch hier: Eine gemeinsame Schicht ist aufwendiger am Anfang und billiger in jedem Jahr danach.
Agenten machen aus der Integration keine andere Disziplin. Sie machen sichtbar, wo die Integration bisher auf menschliches Wissen angewiesen war.
Ein realistischer Weg in vier Schritten
Der Umbau zur agentischen Architektur ist kein Großprojekt, wenn er auf einer API-geführten Integration aufsetzt. Vier Schritte haben sich bewährt.
| Schritt | Inhalt | Ergebnis |
|---|---|---|
| 1. Bestandsaufnahme | Welche Integrationen gibt es, welche APIs, wer konsumiert sie, und wo greifen Agenten heute schon zu, vielleicht ohne dass es jemand so nennt | Übersicht über Lücken und ungesteuerte Zugriffe |
| 2. APIs agententauglich machen | Für die System-APIs, die Agenten brauchen: Beschreibung mit Bedeutung, Kennzeichnung von Nebenwirkungen, Idempotenz für schreibende Aufrufe, Berechtigung aus dem Kontext | Ein Satz von Werkzeugen, den Agenten sicher nutzen können |
| 3. Ein Prozess Ende zu Ende | Ein konkreter Ablauf, etwa vom Angebot bis zum Auftrag, mit einem Agenten, der Salesforce und ERP nutzt, mit definierten Freigabeschritten | Produktiver Nachweis, dass die Schicht trägt |
| 4. Governance und Betrieb | Monitoring aller Agentenaufrufe, Kennzahlen pro Agent und Werkzeug, Prozess für neue Agenten und neue Werkzeuge | Grundlage, um weitere Agenten ohne Wildwuchs zuzulassen |
Der dritte Schritt ist der wichtigste. Ein Prozess, der produktiv läuft, zeigt mehr als jede Architekturskizze. Er zeigt, wo Berechtigungen zu grob sind, wo eine API zu langsam ist, wo der Agent Kontext braucht, den niemand beschrieben hat. Diese Erkenntnisse fließen in die Schicht zurück, bevor der zweite und dritte Agent dazukommen. Was es bedeutet, einen Agenten nach dem Pilotprojekt in den Betrieb zu bringen, gilt hier in vollem Umfang.
Was Unternehmen jetzt prüfen sollten
| Bereich | Leitfrage |
|---|---|
| Generation | Welche Generation hat die eigene Salesforce-Integration erreicht, und wo existieren noch Punkt-zu-Punkt-Verbindungen? |
| Agentenzugriffe | Greifen heute bereits Agenten auf Salesforce zu, etwa über Nutzerkonten oder Skripte, und sind diese Zugriffe gesteuert? |
| Agentforce | Welche Systeme außerhalb von Salesforce braucht ein Agentforce-Agent, und über welchen Weg erreicht er sie? |
| API-Beschreibung | Sind die System-APIs so beschrieben, dass ein Agent versteht, was sie tun, welche Nebenwirkungen sie haben und wann er sie nutzen soll? |
| Berechtigungen | Handeln Agenten im Kontext eines Nutzers oder mit einem technischen Konto, das mehr darf als jeder Mensch? |
| Idempotenz | Können schreibende Aufrufe nach Salesforce und ins ERP gefahrlos wiederholt werden? |
| Monitoring | Gibt es eine Stelle, an der alle Agentenaufrufe über alle Systeme hinweg sichtbar sind? |
Fazit
Salesforce war über Jahre das Zentrum der Kundenbeziehung und das Ziel vieler Integrationen. Mit Agenten wird es zu etwas anderem: zu einem Knoten in einem Netz aus Systemen, in dem Menschen und Agenten nebeneinander lesen, schreiben und handeln. Die Integration, die dafür gebaut wurde, bleibt die Grundlage. Aber sie braucht eine Schicht darüber, die Agenten Kontext, Aktionssemantik und Grenzen gibt.
Wer eine API-geführte Architektur mit MuleSoft betreibt, hat den größten Teil des Weges hinter sich. Was fehlt, ist weniger Technologie als Beschreibung, Steuerung und ein erster Prozess, der zeigt, dass es funktioniert. Wer noch bei Punkt-zu-Punkt-Verbindungen steht, sollte den Umbau nicht für Agenten allein beginnen, aber mit Agenten im Blick.
Das agentische Unternehmen entsteht nicht durch den Einsatz eines Agenten. Es entsteht durch eine Architektur, in der Agenten genauso verlässlich arbeiten können wie die Menschen, für die Salesforce und die Systemintegration ursprünglich gebaut wurden.