Der Leitfaden für Architekt:innen zur Agentforce-Interoperabilität

Verfasst von: Agentforce-Produktteam (Pragya Anand , Moe Basi , Shiv Ramanna , Kyle Bransky )

Lesen Sie weiter, um mehr darüber zu erfahren, wie Sie Ihren Ansatz zur Interoperabilität festlegen können.
Laden Sie sich dann Teil 2 als Referenz für das Erstellen herunter.

Vor der Konzeption von Multi-Agent-Systemen gilt es, die Funktionsweise eines Single-Agents zu verstehen. Ein Agentforce-Agent setzt sich aus Unter-Agents (früher als „Topics“ bezeichnet) zusammen, bei denen es sich um modulare Bausteine handelt, die auf bestimmte Domänen ausgerichtet sind und jeweils über definierte Aktionen verfügen (z. B. Flow, Apex, Prompts).

Jeder Agentforce-Agent führt seine eigene LLM-Inferenzschleife aus und koordiniert dabei, wie Aufgaben auf Unteragenten verteilt werden und wie Antworten gebildet werden, bis das Ziel erreicht ist. Die Agentforce Inferenzmaschine erweitert diese Schleife um ein auf Agentenskript basierendes Determinismus-System, indem sie explizite Übergänge und Abläufe zwischen Unter-Agents hinzufügt und so ein vorhersehbares und kontrollierbares Verhalten gewährleistet, anstatt sich ausschließlich auf die Entscheidungen des LLM zu verlassen. Diese Kombination aus LLM-basierter Inferenz und deterministischen Skripten ermöglicht die Umsetzung von Workflows. Ein einzelner Agent kann zwar viel bewältigen, doch mit zunehmender Komplexität stößt er an folgende Grenzen:

• Datengrenzen: Auf Daten, Workflows und Berechtigungen, die sich in verschiedenen Organisationen oder Systemen von Salesforce befinden, kann nicht zugegriffen werden. Dies ist eine architektonische Barriere, die ein Ein-Agenten-Design nicht überwinden kann.
• Kontextüberladung: Der Kontext der LLM-Inferenzmaschine wird mit Anweisungen, Aktionsergebnissen und der Unterhaltung gefüllt, bis sie beginnt, Kernregeln zu ignorieren oder Themen miteinander zu vermischen.
• Auflösung der fachlichen Spezialisierung: Ein Agent, der versucht, in allen Bereichen ein Experte zu sein, wendet die falsche Logik an, um bestimmte Unteragenten aufzurufen. Je größer der Befehlsblock ist, desto geringer ist die Genauigkeit.

Entscheidungs-Framework: Verwenden Sie Single-Agents, wenn Ihr Geschäftsprozess relativ einfach ist, innerhalb einer einzigen Domäne abläuft und einen einheitlichen Datenzugriff über alle Unteragenten hinweg erfordert.

Die SOMA-Orchestrierung (Single-Org, Multi-Agent) ermöglicht es mehreren spezialisierten Agentforce-Agents, nahtlos innerhalb einer einzigen Organisation von Salesforce zusammenzuarbeiten. Anstatt die Benutzer:innen dazu zu zwingen, Unterhaltungen mit verschiedenen Agents einzeln zu verwalten, bietet SOMA einen einheitlichen Einstiegspunkt für die Kommunikation mit Agenten. Hinter den Kulissen koordiniert ein „Super-Agent“ oder „Orchestrator“-Agent auf intelligente Weise die Aufgaben und delegiert diese an spezialisierte Agents, wodurch sichergestellt wird, dass jede Aufgabe von dem dafür am besten geeigneten Agent bearbeitet wird.

Entscheidungs-Framework: Setzen Sie SOMA ein, wenn Ihre Kund:innen eine einheitliche Zugangserfahrung für spezialisierte Agents wünschen, die innerhalb einer einzigen Umgebung (Organisation) von Salesforce arbeiten.

• Vorteile: Vereinfacht die Benutzererfahrung, indem ein einziger Einstiegspunkt für die Unterhaltung mit mehreren spezialisierten Agents bereitgestellt wird.
• Nachteile: Beschränkt auf die Daten und Workflows, die innerhalb einer einzelnen Organisation von Salesforce verfügbar sind.

Die MOMA-Orchestrierung (Multi-Org, Multi-Agent) stellt als logische Weiterentwicklung des Single-Org-Modells (SOMA) mehrere Organisationen von Salesforce in die Lage, eine einheitliche Agent-Erfahrung zu bieten, ohne dass eine komplexe Datenkonsolidierung erforderlich ist. Diese Architektur basiert auf einer Philosophie der gezielten Delegation anstelle eines offenen Netzwerks und erzwingt eine gezielte Beschränkung auf eine Ebene (Agent A > Agent B, nicht Agent A -> B -> C), um unvorhersehbare Verkettungen zu verhindern. Die Sicherheit wird durch eine benutzeridentitätsorientierte Ausführung und den Betrieb innerhalb einer „Data 360 One“ (DC1)-Vertrauensgrenze gewährleistet.

Entscheidungs-Framework: Nutzen Sie MOMA, wenn Ihr natives Agentforce-Netzwerk Aufgaben sicher über verschiedene Salesforce-Organisationen hinweg delegieren muss, ohne dabei Datenmodelle zu konsolidieren.

• Vorteile: Bietet eine einheitliche Agent-Erfahrung in komplexen Unternehmensumgebungen und gewährleistet dabei die strikte Einhaltung der Vorschriften bezüglich der Datenresidenz.
• Nachteile: Die Zuordnung von Benutzeridentitäten über mehrere Organisationen hinweg und der Austausch von Kontextinformationen zwischen den Organisationen können eine Herausforderung darstellen.

Der Model Context Protocol (MCP)-Client ermöglicht es Agentforce-Administratoren, externe MCP-Server zu registrieren, sodass Entwickler Remote-Tools, -Ressourcen und -Aktionen auf standardisierte Weise in Agentforce integrieren können. Dadurch kann Agentforce externe Funktionen über einen Tool-Vertrag nutzen, anstatt auf maßgeschneiderte Punkt-zu-Punkt-Integrationen zurückzugreifen.

Entscheidungs-Framework: Verwenden Sie den MCP-Client, wenn Agentforce weiterhin als primärer Orchestrator fungieren soll und lediglich Zugriff auf externe Funktionen als Tools benötigt. Beispielsweise das Abrufen von Daten aus einem externen System, das Auslösen eines Workflows, das Durchsuchen einer Knowledge-Quelle oder das Ausführen von Aktionen über eine Plattform eines Drittanbieters.

Verwenden Sie den MCP-Client, wenn Agentforce eine externe Funktion als Verbraucher:in nutzen soll.

• Vorteile: Verwandelt externe Services in sichere, steuerbare Tools für Agentforce ohne benutzerdefinierten Code; umfasst Sicherheitsfunktionen wie semantische Integritätsprüfungen (Anti-Rug-Pull) und Risikobewertung, um Tool-Poisoning zu verhindern. Dadurch bleibt die Inferenz auf Agentforce ausgerichtet, während gleichzeitig die Möglichkeiten von Agentforce erweitert werden.
• Nachteile: Die Abstraktion ist bewusst Tool-orientiert. Wenn sich die Remote-Fähigkeit besser als spezialisierter Agent modellieren lässt, der einen Teil der Inferenzen oder des Workflows übernehmen sollte, kann es unnatürlich wirken, ihn in das MCP-Modell zu zwängen. Da das Schema zudem vom externen Server definiert wird, können Vertragsänderungen dazu führen, dass die Integration fehlschlägt, bis sie aktualisiert oder erneut registriert wurde.

Agentforce-A2A ausgehend ist die integrierte Methode, mit der Agentforce-Agents direkt mit einem externen Agent zusammenarbeiten können. Um dies zu ermöglichen, müssen Administrator:innen zunächst den externen Agent registrieren und dabei dessen spezifische Fähigkeiten, Funktionen und Transportprotokolle angeben. Sobald es registriert und mit einem Agentforce-Agent verbunden ist, steht es zur Laufzeit für die sichere, plattformübergreifende Aufgabenübertragung zur Verfügung.

Entscheidungs-Framework: Verwenden Sie Agentforce-A2A, wenn Ihr internes Agentforce-Netzwerk sicher mit Agents externer Anbieter wie Google oder Box interagieren muss. Hinweis: In diesem Fall muss ein Agent Aufgaben an einen anderen Agent delegieren, der für einen Teil der Inferenz, Planung oder Ausführung zuständig ist.

• Vorteile: Da diese Funktion direkt in Agentforce integriert ist, müssen Sie keine externen Orchestrierungstools erwerben, um diese Multi-Agent-Workflows zu verwalten. Ermöglicht den Benutzer:innen ein KI-Ökosystem unter einer „einheitlichen Marke“ und nutzt vorgefertigtes Fachwissen von externen Plattformen.
• Nachteile: Das Vertrauen in externe Dienstleister und die Gewährleistung des Datenschutzes systemübergreifend können eine Herausforderung darstellen. Dies erfordert die manuelle Registrierung der Funktionen des Drittanbieters sowie die Abstimmung der Authentifizierungsstandards.

Beachten Sie diese einfache Regel: Der entscheidende Unterschied besteht nicht darin, ob KI auf beiden Seiten vorhanden ist. Der wesentliche Unterschied besteht darin, wie die Remote-Fähigkeit modelliert wird:

• Wenn sie als Tool modelliert ist, verwenden Sie MCP
• Wenn Sie als kooperierender Agent modelliert ist, verwenden Sie A2A

Mit A2A eingehend können externe Agents von Drittanbietern nahtlos auf die speziellen Fachkenntnisse und Daten eines Agentforce-Agents zurückgreifen. In dieser Konfiguration wird Agentforce als hochkarätiger „Experte“ behandelt, der von externen Systemen aufgerufen werden kann, um spezifische Aktionen von Salesforce auszuführen. Durch die Bereitstellung der Agentforce-Funktionen über einen sicheren API-Endpunkt können externe Plattformen Aufgaben an Salesforce delegieren, ohne dass der Benutzer seine Drittanbieteranwendung jemals verlassen muss.

Entscheidungs-Framework: Verwenden Sie „A2A eingehend“, wenn sich Ihre primäre KI-Schnittstelle in einem System eines Drittanbieters befindet (z. B. in einem benutzerdefinierten Portal oder einem externen Bot), aber komplexe Workflows innerhalb von Salesforce ausführen muss.

• Vorteile: Ermöglicht externen Anwendungen den Zugriff auf Daten von Salesforce in Echtzeit sowie Automatisierung, ohne dass Logik dupliziert werden muss.
• Nachteile: Das externe System muss die Koordinierung und die „Übergabe“-Logik übernehmen, um eine reibungslose Benutzererfahrung zu gewährleisten.

Der gehostete MCP-Server von Salesforce ermöglicht es, Agentforce-Funktionen über eine standardisierte MCP-Schnittstelle für externe Hosts, wie beispielsweise Agenten von Drittanbietern, Copiloten und LLM-Plattformen, zugänglich zu machen. Auf diese Weise können externe Plattformen Agentforce als Tool-Anbieter nutzen, während Agentforce weiterhin Unternehmensprozesse, Geschäftslogik und die Koordination hinter den Kulissen für komplexe und spezialisierte Aufgaben bündelt.

Entscheidungs-Framework: Verwenden Sie Agentforce-Agents als MCP-Server, wenn eine externe Plattform Agentforce als Tool-Anbieter nutzen soll. Dies ist insbesondere in 2 Fällen von Nutzen:

• Interoperabilität von Enterprise-Agents: Wenn ein Enterprise-Agent eines Drittanbieters, wie beispielsweise Microsoft Copilot, einen Agentforce-Agent aufrufen muss, da Agentforce die zur Erledigung der Aufgabe erforderlichen Unternehmensaktionen enthält.
• Externes LLM / Kanalverteilung: Wenn Sie möchten, dass die Funktionen von Agentforce innerhalb externer Plattformen der Unterhaltung wie ChatGPT, Gemini oder ähnlichen Diensten verfügbar sind.

In diesem Modell bleibt die externe Plattform die primäre Erfahrung des Hosts, während Agentforce bewusst über MCP als Tool-Endpunkt bereitgestellt wird. Selbst wenn Agentforce intern agentengesteuert ist, handelt es sich bei dem Interoperabilitätsmuster dennoch um MCP, da es sich bei der externen Beziehung um einen Tool-Aufruf und nicht um eine Delegation zwischen gleichrangigen Agents handelt.

• Vorteile: Erleichtert die Nutzung leistungsstarker und spezialisierter Agentforce-Agents, die auf der Grundlage von Salesforce-Daten (Abrechnung, Support usw.) speziell für Ihr Unternehmen entwickelt wurden und über ein standardisiertes Protokoll auch außerhalb von Salesforce wiederverwendbar sind; ermöglicht es externen Assistenten und Enterprise-Agents, die Orchestrierung und Geschäftsaktionen von Agentforce zu nutzen, ohne diese neu erstellen zu müssen; unterstützt sowohl die Interoperabilität innerhalb des Unternehmens als auch die Verteilung über externe Kanäle.
• Nachteile: Da der externe Host für die primäre Benutzererfahrung und den Zyklus der Inferenz verantwortlich ist, hat Agentforce weniger Einfluss darauf, wie und wann es aufgerufen wird. Unternehmensszenarien erfordern zudem eine zuverlässige Handhabung von Authentifizierung, Autorisierung, Identitätsweitergabe und Kontextübergabe.

Die obige Übersicht ist nur ein erster Anhaltspunkt, der Ihnen dabei helfen soll, das für Ihren Anwendungsfall geeignete Orchestrierungsmuster zu ermitteln. Lesen Sie weiter, um zu erfahren, wie Sie das Produkt entwerfen und ausliefern können.

Folgendes erfahren Sie, wenn Sie Teil 2 herunterladen: Das Referenzhandbuch für Architekt:innen zur Orchestrierung mehrerer Agents:

• Komplexe Prozesse in Agents zerlegen, die weiterhin nachvollziehbar bleiben. Einen überlasteten Agent mithilfe von 3 Strategien – nach Fachgebiet, nach Workflow-Stufe oder nach Kompetenz – in ein Team von Spezialisten verwandeln, von denen jeder eine Aufgabe gut erledigt.
• Ihre Architektur an eines von 5 Orchestrierungsmustern anpassen. Der überwachte Modus und der Handoff-Modus sind heute allgemein verfügbar. Parallele Ausführung, ereignisgesteuerte Hintergrundagenten sowie Plan und Präsentieren stehen auf der Roadmap.
• Wählen Sie zwischen LLM-gesteuertem und deterministischem Routing. Die Inferenzmaschine passt sich offen formulierten Anfragen an. Agentenskript gibt Ihnen deterministische Kontrolle, wenn ein Workflow eine garantierte Sequenz benötigt. Die meisten Multi-Agent-Designs verwenden beides.
• Vermeiden Sie die sieben gängigsten Anti-Muster. Mesh-Orchestrierung, überlappende Unter-Agents und zu viele Delegationsebenen sind die schnellsten Möglichkeiten, Governance und Beobachtbarkeit in großem Maßstab zu untergraben.
• Design für das, was heute unterstützt wird. Die derzeitigen Einschränkungen des Agentenskripts (Sticky Handoff, verschachtelte Delegation, die Begrenzung auf sieben miteinander verbundene Unteragenten) bestimmen, welche Muster Sie bereits jetzt umsetzen können und welche Sie für das nächste Quartal einplanen sollten.