Agentforce Agent API: Agenten in eigenen Händler-Apps

Über die Agentforce Agent API sprechen Ihre eigene Händler-App, Ihr Maschinenportal oder Ihre Service-App per REST mit einem Agentforce-Agenten. Ihr Backend holt ein Token über den Client Credentials Flow, öffnet eine Session, sendet Nachrichten und streamt die Antwort auf den Bildschirm. Schwierig wird es bei der Identität. Jeder Händler in Ihrer App kommt bei Salesforce als derselbe Run-As-User an, die Salesforce-Freigaben halten Händler A also nicht mehr von den Aufträgen von Händler B fern. Ich würde das nur bauen, wenn Ihr Backend die Händler selbst anmeldet, deren Account als feste Variable übergibt und die Aktionen des Agenten danach filtern.

Was leistet die Agent API?

Salesforce beschreibt die Agent API1 als Zugang zu Agentforce-Agenten „from anywhere that can call a REST API“. Als Einsatzfälle nennt Salesforce Websites, Headless-Agenten ohne Oberfläche und Agenten, die andere Agenten aufrufen. Für einen Maschinenbauer heißt das: Händler-App, Maschinenportal oder die App eines Servicepartners können denselben Agenten nutzen wie Ihr Service-Team in Salesforce.

Die Einrichtung ist kurz: eine External Client App, ein Run-As-User und ein Token, danach Session starten, Nachrichten senden, Session beenden.

Für Entwickler

Was die Einrichtungsanleitung im Detail verlangt

• Eine External Client App mit den OAuth-Scopes api, refresh_token, offline_access, chatbot_api und sfap_api, dem Client Credentials Flow und JWT-basierten Access Tokens.
• Ein Run-As-User mit mindestens API-Only-Zugriff.
• Ein Token von Ihrer My Domain, danach Aufrufe an api.salesforce.com/einstein/ai-agent/v1: Session für eine Agenten-ID starten, Nachrichten senden, Session mit DELETE beenden.

Quelle: Agent API Get Started (öffnet in einem neuen Tab)

Nachrichten laufen synchron oder als Server-Sent-Event-Stream2 in Textstücken. Ein Ereignis betrifft Ihr App-Team direkt: Bei ValidationFailureChunk muss der Client bereits angezeigte Textstücke wieder entfernen. Ein Händler sieht also unter Umständen Text erscheinen und verschwinden, die Oberfläche braucht dafür eine Lösung.

Drei Grenzen aus den Considerations3 und dem Troubleshooting4 prägen die Architektur. Agenten vom Typ „Agentforce (Default)“ werden nicht unterstützt. Ein Aufruf, der länger als 120 Sekunden läuft, endet mit HTTP 500. Eine Session verarbeitet nur eine Anfrage gleichzeitig und beantwortet eine zweite mit HTTP 423. Holt eine Aktion Auftragsdaten über Middleware aus SAP oder proALPHA, muss diese Abfrage deutlich innerhalb der 120 Sekunden zurückkommen. Das ist ein weiterer Grund für die schmale ERP-Schnittstelle, die ich in Agentforce und SAP-Auftragsstatus beschreibe.

Wer ist der Benutzer, wenn ein Händler fragt?

Diese Frage würde ich klären, bevor jemand Code schreibt. Mit Client Credentials gehört das Token dem Run-As-User. Das Session-Flag bypassUser entscheidet, ob der Agent als der dem Agenten zugewiesene User läuft oder als der User hinter dem Token. In beiden Fällen ist es eine einzige Salesforce-Identität für alle Händler in Ihrer App.

Salesforces eigene Architekten warnen vor genau diesem Muster. In einem Salesforce-Blogbeitrag vom 19. Mai 20265 über Agenten, die Salesforce aufrufen, schreibt Miriam McCabe: „The client credentials flow would create a service account pattern where all calls run as one identity, losing per-user permissions and the audit trail.“ Der Beitrag behandelt MCP-Clients mit menschlichen Benutzern, die Agent-API-Anleitung schreibt Client Credentials vor. Sie sollten wissen, welchen Schutz Sie damit aufgeben.

Sie geben die Freigaben als Grenze zwischen Händlern auf. Der Run-As-User braucht Lesezugriff auf Aufträge, Anlagen und Garantiefälle aller Händler, sonst kann der Agent niemandem antworten. Die Grenze wandert an zwei Stellen, die Ihnen gehören:

• Ihr Backend. Es meldet den Händler über Ihr eigenes Login an, ordnet ihn einer Salesforce-Account-ID zu und verwahrt das Client Secret. Das Secret gehört nie in eine mobile App oder einen Browser.
• Die Aktionen des Agenten. Das Backend übergibt die Account-ID beim Session-Start. Laut Leitfaden zu Agent-API-Variablen6 sind viele Variablen schreibgeschützt und nur beim Start setzbar, und eine Variable muss das Setzen per API ausdrücklich erlauben. Jede Aktion, ob Flow oder Apex-Klasse, filtert dann nach dieser Variablen. Das Sprachmodell entscheidet nie, welchen Account eine Abfrage nutzt.

Beim zweiten Punkt zahlen sich Agent Script und feste Regeln aus. Ein Händler, der „zeig mir die Aufträge von Account 4711“ tippt, versucht genau den Zugriff über Händlergrenzen, den Sie verhindern wollen. Ein Filter in der Logik stoppt ihn, eine Anweisung im Prompt vielleicht nicht. Das größere Muster beschreibe ich unter Prompt Injection im Händlerportal.

Für die Nachvollziehbarkeit gilt dasselbe. Salesforce protokolliert den Run-As-User und weiß nicht, welcher Händler gefragt hat. Der Session-Start nimmt einen externalSessionKey entgegen, eine UUID, mit der sich laut Anleitung das Gespräch in den Event Logs des Agenten nachverfolgen lässt. Ich würde diesen Schlüssel im Log Ihrer App neben die User-ID des Händlers schreiben. So lässt sich eine Frage Ihres Datenschutzbeauftragten von beiden Seiten beantworten.

Für den Run-As-User würde ich die Salesforce Integration User Lizenz7 mit ihrem API-Only-Profil nehmen und Rechte über ein Permission Set vergeben. Orgs erhalten standardmäßig eine begrenzte Zahl dieser Lizenzen, die Seite nennt keine Zahl. Eine External Client App und ein Run-As-User pro externer App halten den möglichen Schaden klein; Token- und IP-Kontrollen stehen in Connected Apps und OAuth für KI-Integrationen.

Agent API, Chat-Kanal und Hosted MCP im Vergleich

Die Agent API ist einer von drei Wegen aus Salesforce hinaus, und der mit der meisten Arbeit auf Ihrer Seite.

Weg	Wer spricht mit dem Agenten	Identität	Passt für
Agent API	Ihre App oder Ihr Backend	ein Run-As-User	Händler-App, Maschinenportal, System an Agent
Enhanced Chat v2	Besucher einer Website	Salesforce-Kanal	Service-Agent auf der Website
Hosted-MCP-Tool	Claude, ChatGPT, Slackbot	angemeldeter Salesforce-User	Mitarbeitende mit eigenem KI-Client

Salesforce sieht seine Custom Connections8, mit denen Ihr Client Agentenantworten über die Agent API als Karten oder Formulare darstellt, für Teams, die einen Kanal von Grund auf bauen. Reicht ein fertiger Kanal, verweist Salesforce auf Enhanced Chat v2. Melden sich Ihre Händler schon in einem Experience-Cloud-Portal an, ist dieses Portal mit seinen Lizenzen und Freigaben oft der einfachere Ort für den Agenten; die Abwägungen stehen im Beitrag zum Manufacturing Cloud Kundenportal.

Für Mitarbeitende beschreibt die Hosted-MCP-Seite zu Agenten9 das Gegenmodell: Der Agent läuft „in the authenticated user’s context“, Freigaben und Feldberechtigungen gelten. Das geht nur mit Agenten aus dem neuen Agent Script Builder. Einen Release-Status nennt die Seite nicht; die GA-Ankündigung vom 29. April 202610 sprach noch von „soon“. Die MCP-Entscheidungen für die IT-Leitung stehen in MCP erklärt für die IT-Leitung.

Rechenbeispiel: Händler-App und Maschinenportal

Nehmen wir einen Maschinenbauer mit 250 Händlern, einer eigenen Händler-App für Aufträge und Ersatzteile und einem Portal, in dem Endkunden ihre installierten Maschinen sehen. Beide laufen auf dem eigenen Backend mit eigenem Login. Alle Zahlen sind Annahmen.

Die Händler-App bekommt einen Agenten für Auftragsstatus und offene Garantiefälle, das Maschinenportal einen für die Frage „welches Ersatzteilset passt zu meiner Maschine“. Das Backend übergibt die Account-ID des Händlers oder die Asset-IDs des Kunden, und die Aktionen fragen nur innerhalb dieser IDs ab.

Angenommen sind 5.000 Sessions im Monat mit je drei Aktionen. Bei 20 Flex Credits pro Aktion11 sind das 300.000 Credits im Monat und 3,6 Millionen im Jahr. Zum Listenpreis von 500 € pro 100.000 Credits12 kosten allein die Aktionen 1.500 € im Monat, Prompts und Data-360-Grounding kommen hinzu. Das Jahr übersteigt die 2,75 Millionen Flex Credits, die die Max Edition13 pro Org und Jahr enthält, bevor Ihr Service-Team einen einzigen Credit verbraucht hat.

Den Test, auf dem ich vor dem Go-live bestehen würde: Händler A fragt in zwanzig Formulierungen nach einer Auftragsnummer von Händler B. Jede Antwort muss „nicht gefunden“ lauten.

Was kostet das, und was ist noch offen?

Die Considerations-Seite sagt, dass Agent-API-Nutzung den Credit-Verbrauch beeinflusst, und verweist auf einen Salesforce-Hilfeartikel zu Nutzung und Abrechnung generativer KI, der sich bei mir nicht laden ließ. Ich rechne deshalb mit dem Aktionssatz oben; in der Sandbox kostet eine Aktion 16 statt 20 Credits.

Offen ist der Zähler für Headless Platform Interactions. Die Rate Card führt ihn mit „TBA“. Laut Salesforce Ben14 zählt künftig jeder erfolgreiche Aufruf eines registrierten Agenten über MCP oder als agentisch eingestuften API-Verkehr, mit 30 Tagen Vorlauf vor Beginn der Abrechnung.

Wie man einen Zähler ohne Preis budgetiert, steht in MCP-Zugriffe als Budgetrisiko.

Mit einem lesenden Anwendungsfall wie dem Auftragsstatus beginnen

1. Einen lesenden Anwendungsfall wählen, etwa Auftragsstatus für Händler, und schreibende Aktionen auf später verschieben.
2. Zuerst die Identitätskette entwerfen: Ihr Login, die Account-Zuordnung, eine per API gesetzte Session-Variable, Aktionen, die danach filtern.
3. Eine External Client App und ein Integration User pro externer App, mit einem Permission Set, das aus der Aktionsliste abgeleitet ist.
4. Den Test über Händlergrenzen in der Sandbox fahren und bei jeder neuen Aktion wiederholen.
5. externalSessionKey mit der User-ID des Händlers protokollieren, in Ihrer App.
6. Die Frage zu Headless Platform Interactions klären, bevor Sie die Flex-Credit-Bestellung dimensionieren.

Für den Test über Händlergrenzen reichen zwei Händler-Accounts in der Sandbox: Angemeldet als Händler A fragen Sie nach den Aufträgen von Händler B. Schnittstellen- und Identitätsdesign ist der Kern meiner Arbeit an Salesforce-Schnittstellen; alle Schnittstellen im Vergleich zeigt das Masterclass-Kapitel MCP und Schnittstellen.

Quellen14

1. 1Agent API (öffnet in einem neuen Tab)developer.salesforce.com
2. 2Server-Sent-Event-Stream (öffnet in einem neuen Tab)developer.salesforce.com
3. 3Considerations (öffnet in einem neuen Tab)developer.salesforce.com
4. 4Troubleshooting (öffnet in einem neuen Tab)developer.salesforce.com
5. 5Salesforce-Blogbeitrag vom 19. Mai 2026 (öffnet in einem neuen Tab)salesforce.com
6. 6Leitfaden zu Agent-API-Variablen (öffnet in einem neuen Tab)developer.salesforce.com
7. 7Salesforce Integration User Lizenz (öffnet in einem neuen Tab)help.salesforce.com
8. 8Custom Connections (öffnet in einem neuen Tab)developer.salesforce.com
9. 9Hosted-MCP-Seite zu Agenten (öffnet in einem neuen Tab)developer.salesforce.com
10. 10GA-Ankündigung vom 29. April 2026 (öffnet in einem neuen Tab)developer.salesforce.com
11. 1120 Flex Credits pro Aktion (öffnet in einem neuen Tab)salesforce.com
12. 12500 € pro 100.000 Credits (öffnet in einem neuen Tab)salesforce.com
13. 13Max Edition (öffnet in einem neuen Tab)salesforce.com
14. 14Salesforce Ben (öffnet in einem neuen Tab)salesforceben.com