Agentforce A2A: Welcher Agent führt das Händlergespräch?

Mit Agentforce A2A, also Agent-to-Agent-Aufrufen zwischen Herstellern, verschiebt sich die Architekturfrage zur Zuständigkeit: Welcher Agent führt das Gespräch mit Händlern und Servicekunden? Meine Antwort: der Agent des Systems, in dem sich die Person anmeldet und in dem der Vorgang liegt. Händler im Salesforce-Portal sprechen mit Agentforce, das SAP über APIs liest. Innerhalb einer Org ist Multi-Agent-Orchestrierung seit Winter ’27 allgemein verfügbar. Über Herstellergrenzen funktioniert heute die MuleSoft A2A Bridge, mit klaren Grenzen: nur synchron, keine Push-Benachrichtigungen, Task-Status im Gateway-Speicher. Natives A2A in Agentforce ist angekündigt, ohne Status.

Warum bringt jeder Hersteller jetzt einen eigenen Agenten?

Ein Maschinenbauer mit Salesforce, SAP und Microsoft 365 bekommt drei Agenten gleichzeitig angeboten. Salesforce verkauft Agentforce für Service, Händlerportal und Vertrieb. SAPs KI-Chef beschrieb Joule in einem Beitrag vom April 20251 als “agent orchestrator working across enterprise workflows” und nennt SAP dort einen der Gründungsunterstützer des A2A-Protokolls. Microsoft dokumentiert, wie ein Agent in Copilot Studio einen anderen Agenten per A2A einbindet2 und Aufgaben an ihn delegiert, statt nur APIs aufzurufen. Jeder Hersteller stellt seinen Agenten nach vorn.

Die Frage eines Händlers hält sich an diese Grenzen nicht. “Ist der Dichtungssatz für Maschine 4711 lieferbar, und ist mein Garantieantrag für diese Maschine freigegeben?” berührt die Verfügbarkeit in SAP sowie Antrag und Anlage in Salesforce. Will jeder Systemagent selbst antworten, bekommt der Händler drei Eingangstüren oder eine Kette von Agenten, die sich gegenseitig fragen. Beides ist schlechter als ein Agent, der das Gespräch führt und sich holt, was er braucht.

A2A (Agent2Agent) ist ein offenes Protokoll, über das Agenten verschiedener Hersteller sich über eine “Agent Card” finden, Aufgaben übergeben und Ergebnisse zurückgeben. Der Unterschied zu MCP zählt für den Entwurf: MCP verbindet einen Agenten mit Werkzeugen und Daten, A2A mit einem anderen Agenten, der selbst schlussfolgert. Was MCP für die IT bedeutet, steht in MCP und Salesforce für die IT-Leitung erklärt.

Was leistet Agent-to-Agent-Interoperabilität heute?

Stand 27. Oktober 2026 unterscheidet sich der Status je nach Weg. Ich würde nur mit dem dokumentierten planen:

• Innerhalb einer Salesforce-Org: allgemein verfügbar. Der Entwicklerleitfaden zu Winter ’273 schreibt “Multi-Agent Orchestration is generally available”. Ein Orchestrator-Agent übergibt an Spezialisten in derselben Org, die in Agent Script als connected_subagent deklariert sind.
• Agentforce als A2A-Server über MuleSoft: verfügbar, mit Grenzen. Die A2A Bridge4 läuft als Policy-Kette auf einem Omni Gateway vor dem Agenten, übersetzt A2A-Anfragen in Aufrufe der Agent API und leitet eine Agent Card ab. Agentforce ist als verfügbar gelistet, mit Streaming und Human-in-the-Loop. In der Pressemitteilung zu Agentforce 35 hatte Salesforce die A2A-Unterstützung von MuleSoft für Juli 2025 als allgemein verfügbar angekündigt.
• Natives A2A in Agentforce: angekündigt. Laut Dreamforce-2026-Rückblick6 kann Agentforce “act as a specialized subagent in any A2A-compliant architecture” und Agenten von AWS, Azure und Google orchestrieren. Der Abschnitt nennt keinen Status, und eine Salesforce-Dokumentation für einen nativen A2A-Endpunkt habe ich nicht gefunden.
• SAP Joule: nur eingehend. SAPs Referenzarchitektur für eingehendes A2A7, aktualisiert am 26. Oktober 2026, stellt Joule-Agenten über das Agent Gateway mit A2A 0.3.0 für Clients anderer Hersteller bereit, das Vertrauen läuft über SAP Cloud Identity Services. Laut Hinweis sind einige Komponenten noch nicht GA, und die bidirektionale Kommunikation mit Agenten anderer Hersteller über das Agent Gateway “is not yet supported”.
• Microsoft Copilot Studio: Client-Seite dokumentiert. Die Copilot-Studio-Seite kennzeichnet die A2A-Funktion weder als Preview noch als GA. Auf der Bridge-Liste von MuleSoft steht Copilot Studio als Quellagent auf “geplant”, ein Copilot-Agent lässt sich über MuleSoft also noch nicht per A2A erreichbar machen.

Die Grenzen der A2A Bridge entscheiden, welche Aufgaben passen.

Herstellerübergreifendes A2A passt heute also zu einer Frage, die in Sekunden beantwortet ist. Eine Garantieprüfung, die tagelang auf den Bericht des Technikers wartet, passt nicht.

Welcher Agent sollte das Gespräch mit Händlern und Servicekunden führen?

Das Gespräch führt der Agent des Systems, in dem sich die Person anmeldet und in dem das Ergebnis festgehalten wird. Diese Fragen entscheiden es:

1. Wer kennt die Person? Ein Händler im Experience-Cloud-Portal ist ein Kontakt an einem Account mit der SAP-Auftraggebernummer. Jede Sichtbarkeitsregel beginnt dort.
2. Wo liegt das Ergebnis? Fälle, Garantieanträge und Arbeitsaufträge liegen in Salesforce, also schreibt der führende Agent das Ergebnis dorthin.
3. Welcher Kanal? Portal-Chat, Service-Hotline und E-Mail-to-Case sind Salesforce-Kanäle. Teams gehört zu Microsoft.
4. Wer übernimmt vom Agenten? Die Eskalations-Queue des Serviceteams läuft in Salesforce Omni-Channel.

Für einen Maschinenbauer ergibt das eine klare Aufteilung. Händler und Servicekunden sprechen mit Agentforce, SAP-Daten kommen über eine API-Aktion, wie in Agentforce und SAP: Auftragsstatus über MuleSoft beschrieben. Vertriebsmitarbeitende, die in Teams und Outlook arbeiten, können Copilot als Eingangstür haben, mit einem Agentforce-Agenten dahinter für CRM-Fragen. Wer im Kreditmanagement oder in der Fakturierung in SAP arbeitet, bekommt Joule.

Ich würde das pro Zielgruppe schriftlich festlegen, so wie jedes Objekt genau einen Owner hat. Den Ausschlag sollte nie geben, welcher Hersteller an dem Tag die beste Demo gezeigt hat.

Ein zweiter Agent lohnt sich nur, wenn er eigene Logik besitzt

Eine Datenabfrage mit genau einer richtigen Antwort gehört in eine API oder ein MCP-Tool. Fragt ein Agent einen anderen nach dem Auftragsstatus, ist das ein API-Aufruf mit zwei Sprachmodellen dazwischen, und beide können die Frage falsch verstehen. Delegieren Sie an einen anderen Agenten nur, wenn er Urteil und Regeln besitzt, die Sie nicht nachbauen wollen, etwa einen SAP-seitigen Prozess, der bereits mit SAPs eigenen Prüfungen läuft.

Vor dem Go-live wirft jeder Sprung vier Fragen auf:

• Als wer läuft der Spezialist? Die A2A Bridge meldet sich mit Client-ID und Secret an der Salesforce-Org an. Im dokumentierten Client-Credentials-Setup8 mit bypassUser auf true nutzt die API den Benutzer, der dem Agenten zugeordnet ist, nicht die Person, die in Teams gefragt hat. Dessen Freigaben bestimmen, was der Spezialist lesen darf. Sperren gehören auf der empfangenden Seite in Code, wie in Agent Script: Regeln statt LLM.
• Wie lange darf es dauern? Höchstens 120 Sekunden, sonst bricht der Aufruf ab.
• Wer zahlt? Laut Salesforce zählt die Nutzung der Agent API zum Credit-Verbrauch, und die aufrufende Plattform rechnet ihre eigene Nutzung ab. Eine Händlerfrage läuft dann über zwei Zähler.
• Wo liegt die Spur? Ein Fehler über zwei Hersteller bedeutet zwei Logs und zwei Supportverträge. Herstellerübergreifende Fälle gehören in die Testfälle aus Agentforce-Agenten testen und freigeben.

Rechenbeispiel: Händlerportal, Teams und ein Joule-Agent

Nehmen wir einen Maschinenbauer mit 250 Händlern, SAP S/4HANA, Microsoft 365 und einem Agentforce-Agenten im Händlerportal, der Garantie- und Auftragsfragen beantwortet. Alle Zahlen sind Annahmen. In einem Quartal kommen drei Anfragen bei der IT an.

Der Vertrieb will den Händleragenten in Teams. Gebietsverkaufsleiter fragen etwa, wie viele Garantieanträge ein Händler offen hat. Ein Copilot-Studio-Agent ruft einen Agentforce-Spezialisten über die MuleSoft A2A Bridge auf. Die Antwort kommt in Sekunden, das passt zu den synchronen Grenzen. Vorher prüfen: Die Bridge akzeptiert JWT, Basic Authentication oder Client-ID-Prüfung, Copilot Studio bietet API-Schlüssel oder OAuth 2.0, beide Seiten brauchen also ein gemeinsames Verfahren. Weil der Spezialist als Agentenbenutzer läuft, würde ich ihn auf lesende Fragen beschränken, die jeder Vertriebsmitarbeitende ohnehin sehen darf, und Antragsdetails in Salesforce lassen.

Das SAP-Team schlägt einen Joule-Agenten für Kreditprüfungen vor. Der Portalagent soll Joule fragen, ob ein Händler trotz Kreditsperre bestellen darf. Das würde ich ablehnen. Eine Kreditsperre ist in SAP ein Ja oder Nein, eine API liefert es deterministisch, und der bidirektionale Weg über Joule ist noch nicht unterstützt.

Der Service will einen Agenten für die Garantieprüfung. Die Prüfung wartet zwei bis fünf Tage auf den Bericht des Technikers im Außendienst. Ohne asynchrone Tasks für Agentforce in der Bridge und mit 120 Sekunden Timeout bleibt das ein Salesforce-Prozess mit Fall, Arbeitsauftrag und Freigabe statt einer A2A-Aufgabe.

Eine von drei Anfragen läuft über A2A. Für ein erstes Jahr halte ich dieses Verhältnis für gesund.

Pro Zielgruppe einen führenden Agenten festlegen

1. Legen Sie pro Zielgruppe einen führenden Agenten fest, samt Kanal: Händler, Servicekunden, Vertrieb, Backoffice.
2. Listen Sie die Fragen auf, die Systemgrenzen überschreiten, und markieren Sie jede als Datenabfrage (API oder MCP) oder delegiertes Urteil (Agent).
3. Nutzen Sie zuerst die Multi-Agent-Orchestrierung innerhalb der Org. Sie ist GA und hält Identität, Logs und Abrechnung an einem Ort.
4. Prüfen Sie Identität, Timeout, Kosten und Logging für jeden herstellerübergreifenden Sprung, bevor Sie ihn bauen.
5. Pilotieren Sie einen lesenden A2A-Sprung, wenn MuleSoft bei Ihnen schon läuft, und lassen Sie sich von SAP und Microsoft den GA-Status ihrer Seite schriftlich bestätigen.

Für den ersten Punkt reicht eine Tabelle mit Zielgruppe, Kanal, führendem Agenten und den Systemen, die er abfragt. Welches Integrationsmuster zu welchem System passt, gehört zu Salesforce-Schnittstellen, und das Masterclass-Kapitel MCP und Schnittstellen ordnet die Protokolle ein.

Quellen8

1. 1Beitrag vom April 2025 (öffnet in einem neuen Tab)news.sap.com
2. 2einen anderen Agenten per A2A einbindet (öffnet in einem neuen Tab)learn.microsoft.com
3. 3Entwicklerleitfaden zu Winter ’27 (öffnet in einem neuen Tab)developer.salesforce.com
4. 4A2A Bridge (öffnet in einem neuen Tab)docs.mulesoft.com
5. 5Pressemitteilung zu Agentforce 3 (öffnet in einem neuen Tab)salesforce.com
6. 6Dreamforce-2026-Rückblick (öffnet in einem neuen Tab)salesforce.com
7. 7Referenzarchitektur für eingehendes A2A (öffnet in einem neuen Tab)architecture.learning.sap.com
8. 8Client-Credentials-Setup (öffnet in einem neuen Tab)developer.salesforce.com