Multi-Agenten-Orchestrierung auf Salesforce: Was Agent-zu-Agent-Übergaben im Produktivbetrieb zuverlässig macht

Die kurze Antwort: Multi-Agenten-Orchestrierung auf Salesforce bedeutet, dass ein Orchestrator-Agent das Gespräch führt und jede Aufgabe an einen Spezialagenten mit eng geschnittenem Fachgebiet übergibt. Zuverlässig wird das im Produktivbetrieb nicht durch einen größeren Prompt im Orchestrator, sondern durch einen strengen Übergabevertrag zwischen den Agenten: was übergeben wird, was zurückkommt und wer handeln darf. Salesforce hat die Multi-Agenten-Orchestrierung in Agentforce am 15. Juni 2026 allgemein verfügbar gemacht, und das Agent2Agent-Protokoll (A2A) überträgt dasselbe Muster auf Agenten, die nicht auf Salesforce laufen.

Was ist Multi-Agenten-Orchestrierung auf Salesforce?

Es ist eine Routing-Architektur. Ein primärer Agent ist der einzige Ansprechpartner des Nutzers und hält den Sitzungskontext. Dahinter stehen Spezialagenten, jeder auf ein abgegrenztes Fachgebiet beschränkt und mit eigenen Aktionen ausgestattet: Apex, Flow, Prompt-Vorlagen, externe APIs.

Das Routing ist kein Entscheidungsbaum. Die Atlas Reasoning Engine liest von jedem registrierten Agenten Beschreibung, Anweisungen und verfügbare Aktionen und wählt zur Laufzeit den passenden aus. Daraus folgt etwas, das Teams unterschätzen: eine Agentenbeschreibung ist Routing-Logik, keine Dokumentation. Unscharfe Beschreibungen erzeugen unscharfes Routing.

Warum funktioniert ein einziger großer Prompt irgendwann nicht mehr?

Fast jedes Team probiert zuerst die Variante mit einem Agenten. Sie wirkt in der Demo und bricht im Produktivbetrieb ein, aus Gründen, die strukturell und nicht behebbar sind:

• Verwässerte Anweisungen. Regeln aus einem Workflow sickern in einen anderen, und das Modell mittelt sie.
• Werkzeug-Wildwuchs. Jenseits von etwa einem Dutzend Aktionen sinkt die Auswahlgenauigkeit, und das falsche Werkzeug feuert.
• Kein Wirkungsradius. Ein Agent mit Erstattungsrechten hat diese Rechte in jedem Gespräch, das er jemals führt.
• Nicht testbare Änderungen. Ein neuer Absatz zu Retouren kann still das Verhalten bei Garantiefällen verändern, und es gibt nichts, was sich als Unit testen ließe.

Ein Spezialist mit einer Aufgabe und fünf Aktionen hat keines dieser Probleme. Die Komplexität verschwindet nicht, sie wandert an die Nahtstellen zwischen den Agenten. Dort gehört sie hin, denn eine Nahtstelle lässt sich spezifizieren.

Wie sieht Orchestrator plus Spezialisten im Produktivbetrieb aus?

1. Ein Orchestrator, der die Absicht klärt, Kontext hält und eskaliert. Er trägt keine eigenen Geschäftsaktionen.
2. Ein Spezialist je abgegrenztem Fachgebiet, etwa Anspruchsprüfung, Einsatzdisposition oder Rechnungskorrekturen, jeweils mit eigenen Aktionen und eigenen Testfällen.
3. Ein strukturierter Kontext, der zwischen ihnen übergeben wird, statt freiem Text.
4. Eine menschliche Freigabe für alles Unumkehrbare oder Finanzielle.
5. Tracing an jeder Übergabe, damit ein schlechtes Ergebnis einem Agenten zurechenbar ist und nicht "der KI".

Der Maßstab erklärt, warum das zählt. In unserem ASSA-ABLOY-Programm (FocusCura und Phoniro) umfasst die operative Fläche 11.000 vernetzte Geräte mit bis zu 2,5 Millionen Ereignissen pro Woche in drei Märkten, und die wöchentlichen Fälle sanken von 3.000 auf 350 ohne zusätzliches Support-Personal. Eine Last dieser Form hält niemand in einem einzigen Prompt.

Was macht eine Übergabe zwischen Agenten zuverlässig?

Das ist der Teil, den Herstellermaterial überspringt, und genau dort brechen Produktivsysteme. Behandeln Sie jede Übergabe als Schnittstelle, nicht als Gespräch.

• Typisiert rein, typisiert raus. Wenn Sie die Übergabe nicht als Funktionssignatur aufschreiben können, erfindet der Orchestrator eine, und morgen eine andere.
• Übergeben Sie Bezeichner, keine Prosa. Eine CaseId und eine AssetId überstehen eine Übergabe. Eine umformulierte Zusammenfassung nicht.
• Geben Sie dem Spezialisten die Möglichkeit abzulehnen. "Ich kann nicht fortfahren, der Anspruch ist abgelaufen" ist eine routingfähige Antwort. Stille Improvisation nicht.
• Machen Sie Aktionen idempotent. Orchestratoren wiederholen Versuche. Ein Wiederholungsversuch darf nie eine zweite Erstattung auslösen.
• Versionieren Sie die Beschreibungen. Das Routing hängt davon ab, also ist eine geänderte Beschreibung eine Produktivänderung und gehört ins Review.

Die Nahtstelle ist das Produkt. Agenten sind der einfache Teil; der Vertrag zwischen ihnen ist die eigentliche Ingenieursarbeit.

Wo gehören A2A und MCP wirklich hin?

A2A regelt die Delegation über Plattformgrenzen. Ein Agent veröffentlicht eine Agent Card, die beschreibt, was er kann; ein Client-Agent findet sie, delegiert eine Aufgabe und erhält Nachrichten und Artefakte zurück. So erreicht ein Agentforce-Orchestrator einen Spezialisten, der ganz woanders läuft.

MCP ist die andere Achse. Es gibt einem einzelnen Agenten Zugriff auf Werkzeuge und Daten. Wir bauen MCP-Server, damit ein Agent in den Systemen handeln kann, die ein Unternehmen ohnehin betreibt, statt jede Aktion durch eine CRM-Maske zu zwingen.

Faustregel: A2A geht von Agent zu Agent, MCP von Agent zu System. Das Falsche zu wählen ist der häufigste Architekturfehler, den wir sehen.

Wie führt man das ein, ohne die Nahtstellen zu zerreißen?

1. Starten Sie mit drei Agenten auf einem Workflow mit bereits sauberen Daten. Agenten über unsauberen Daten vervielfachen das Chaos.
2. Instrumentieren Sie vor dem Skalieren. Wer heute keine einzelne Übergabe nachverfolgen kann, debuggt nächstes Quartal keine zehn Agenten.
3. Geben Sie jedem Spezialisten einen namentlichen menschlichen Eigentümer.
4. Testen Sie das Routing adversarial, mit mehrdeutigen Anfragen und mehreren Absichten, nicht mit dem Idealpfad.
5. Halten Sie je Spezialist einen Notausschalter bereit, damit ein fehlerhafter Agent nicht den ganzen Workflow lahmlegt.

FAQ

Ist Multi-Agenten-Orchestrierung heute auf Salesforce produktiv verfügbar?

Ja. Salesforce hat die Multi-Agenten-Orchestrierung in Agentforce am 15. Juni 2026 allgemein verfügbar gemacht, samt A2A-Unterstützung für Agenten außerhalb der Plattform.

Mit wie vielen Spezialagenten sollten wir starten?

Mit drei, auf einem Workflow. Beweisen Sie zuerst Übergaben und Tracing, dann kommt ein Fachgebiet nach dem anderen dazu.

Macht ein größeres Modell Orchestrierung überflüssig?

Nein. Ein stärkeres Modell verbessert das Schließen innerhalb eines Agenten. Es liefert keine abgegrenzten Rechte, keine Tests je Fachgebiet und keinen zurechenbaren Fehler. Das kommt aus der Architektur.

Was bricht im Produktivbetrieb am häufigsten?

Übergaben. Zwischen Agenten verlorener Kontext, Fehlrouting durch eine unscharfe Agentenbeschreibung und Wiederholungen, die eine nie idempotente Aktion erneut ausführen.

Müssen wir Agenten auf anderen Plattformen neu bauen?

Nein. Mit A2A kann ein Agentforce-Orchestrator an Drittanbieter-Agenten delegieren, sodass ein Spezialist außerhalb von Salesforce im selben Workflow mitläuft.

Tekunda baut Multi-Agenten-Systeme auf Salesforce und außerhalb davon, einschließlich Agent-zu-Agent-Orchestrierung im Produktivbetrieb. Wenn Sie von einem Agenten zu einem Team von Agenten wechseln, ist der Entwurf der Nahtstellen die erste Arbeit, die sich lohnt.