Salesforce Summer '26 bringt Multi-Agent-Orchestrierung am 15. Juni. So führen Sie das Sales Ops-Audit durch, bevor Ihre Agenten mit dem Übergeben beginnen

Der 15. Juni ist zwei Wochen entfernt, und das folgenreichste Feature für Sales Ops-Teams ist weder ein neues Dashboard noch eine intelligentere Forecast-Funktion. Es ist ein neues Governance-Problem.

Das Summer '26-Release von Salesforce wird am 15. Juni 2026 allgemein verfügbar (GA), und das Highlight für Sales Ops ist die Multi-Agent-Orchestrierung innerhalb von Agentforce: die Möglichkeit, mehrere Agenten so zu verknüpfen, dass sie Aufgaben in einem vollständigen Umsatz-Workflow untereinander weitergeben. Zusammen mit Slack First Sales, das CRM-Kontext in Gesprächsform direkt in Slack-Threads anzeigt, damit Vertriebsmitarbeitende dort handeln, wo sie sich ohnehin aufhalten, verändert dieses Release, was es bedeutet, einen KI-gestützten Umsatzprozess zu steuern.

Die Verschiebung ist nicht marginal. Bei Einzelagenten-Deployments umfasste Ihre Governance-Checkliste genau eine Zeile: ein Agent, seine Leserechte, seine Schreibrechte, seine Auslösebedingungen, sein Fehlerzustand. Multi-Agent-Orchestrierung macht aus dieser einzelnen Zeile einen Graphen. Und der Graph ist die neue Governance-Oberfläche.

Salesforces State of Sales 2026-Daten machen deutlich, dass dies in großem Maßstab relevant ist: Nahezu neun von zehn Vertriebspersonen planen, bis 2027 KI-Agenten einzusetzen, und KI-Agenten sollen die Recherchezeit um 34 % reduzieren. Das bedeutet viele Agenten, die viele Deals berühren. Wer den Übergabe-Graphen vor dem 15. Juni nicht in Ordnung bringt, wird die zweite Jahreshälfte damit verbringen, Phantom-Leads zu entwirren.

Was am 15. Juni tatsächlich ausgeliefert wird

Key Facts

• Summer '26 GA-Datum: 15. Juni 2026 (Quelle: Salesforce Newsroom)
• Vertriebspersonen, die bis 2027 KI-Agenten einzusetzen planen: nahezu 9 von 10 (Quelle: Salesforce State of Sales 2026)
• Erwartete Reduzierung der Recherchezeit durch KI-Agenten: 34 % (Quelle: Salesforce State of Sales 2026)

Multi-Agent-Orchestrierung ist die zentrale Neuerung: Einzelne Agentforce-Agenten können jetzt zu einer Sequenz verknüpft werden, bei der der Output eines Agenten zum Input des nächsten wird. Ein Research-Agent kann Prospect-Intelligence abschließen und das Paket an einen Outreach-Agenten übergeben. Der Outreach-Agent bewertet das Engagement und übergibt an einen Qualifizierungsagenten. Der Qualifizierungsagent trifft eine Stage-Entscheidung und übergibt an einen CRM-Update-Agenten. Der CRM-Update-Agent schreibt Felder und übergibt an einen Forecast-Agenten. Das sind fünf Agenten, die einen Deal berühren, ohne dass ein Mensch die Zwischenschritte genehmigt.

Slack First Sales wird parallel dazu ausgeliefert. CRM-Daten erscheinen in Slack-Threads in Gesprächsform, sodass Vertriebsmitarbeitende auf Deal-Hinweise reagieren können, ohne Slack zu verlassen. Agenten schreiben die Ergebnisse dieser Interaktionen automatisch zurück in Salesforce. Für Teams, die ohnehin in Slack arbeiten, ist das echten Mehrwert. Es stellt jedoch eine zweite Governance-Frage: Wer ist für den Audit-Trail verantwortlich, wenn die Slack-Antwort eines Mitarbeitenden einen Agenten-Write in Salesforce auslöst?

Der Rest von Summer '26 umfasst Updates für Einstein, Data Cloud und Industry Clouds. Dieser Artikel behandelt ausschließlich die Orchestrierungsebene und den Slack-Hand-off. Die Aktualisierungen des Customer-Engagement-Agenten aus Summer '26 wurden separat für die Bewertung auf CRO-Ebene behandelt.

Warum Multi-Agent-Orchestrierung die Sales Ops-Aufgabe verändert

Vor der Orchestrierung sah Ihre Agentforce-Governance-Checkliste ungefähr wie eine einzelne Zeile aus: ein Agent, seine Leserechte, seine Schreibrechte, seine Auslösebedingungen, sein Fehlerzustand.

Nach der Orchestrierung wird aus dieser einzelnen Zeile ein Graph. Und der Graph ist die neue Governance-Oberfläche.

Stellen Sie sich vor, wie ein Fünf-Agenten-Umsatz-Workflow tatsächlich abläuft. Der Research-Agent fragt externe Datenquellen ab und schreibt ein Prospect-Intelligence-Objekt. Er löst den Outreach-Agenten aus, wenn ein Konfidenz-Schwellenwert einen festgelegten Wert überschreitet. Der Outreach-Agent generiert eine Nachrichtensequenz und schreibt Engagement-Status-Felder. Er löst den Qualifizierungsagenten aus, wenn ein Prospect eine bestimmte Anzahl von Touchpoints öffnet. Der Qualifizierungsagent bewertet Stage-Kriterien und schreibt das Opportunity-Stage-Feld. Er löst den CRM-Update-Agenten aus, wenn die Kriterien erfüllt sind. Der CRM-Update-Agent schreibt Deal-Felder im gesamten Opportunity-Datensatz. Er löst den Forecast-Agenten am Wochenende aus. Der Forecast-Agent aktualisiert Commit-Kategorien.

Das sind acht verschiedene Übergabe-Ereignisse über fünf Agenten, von denen jeder unterschiedliche CRM-Objekte und Felder berührt. Wenn einer dieser Hand-offs fehlschlägt, ist der nachgelagerte Datensatz falsch. Und weil kein Mensch die Zwischenschritte genehmigt hat, potenzieren sich die falschen Daten, bevor jemand sie in einem Bericht sieht.

Deshalb verlagert sich Ihre Aufgabe als Sales Ops von „einen Agenten konfigurieren" zu „den Übergabe-Graphen verantworten". Der Graph ist jetzt der Ort, an dem die Governance des Umsatzprozesses stattfindet. Wenn Sie ihn vor dem 15. Juni nicht bewusst gestalten, wird das Standardverhalten ausgeliefert, und Sie erben, was Salesforces Out-of-the-box-Auslösebedingungen in Ihrer spezifischen Datenumgebung erzeugen.

Für einen tieferen Einblick darin, wie AI Sales Ops-Governance und Audit-Trails über den gesamten KI-Sales-Ops-Stack hinweg funktionieren, gilt dieses Framework direkt hier: Orchestrierung erhöht die Anforderungen an den Audit-Trail, anstatt sie zu verringern.

Die drei Übergabe-Fehlermodi, die Sales Ops blockieren muss

Phantom-Hand-offs

Ein Phantom-Hand-off liegt vor, wenn Agent A die Arbeit als übergeben markiert, Agent B sie aber nie verarbeitet. Der Lead befindet sich in einem toten Zustand zwischen zwei Agenten-Queues. Keiner der Agenten wirft einen Fehler. Kein Alert wird ausgelöst. Die Opportunity hört einfach auf, sich zu bewegen.

Das ist der häufigste Fehlermodus in jedem warteschlangenbasierten System, und die Multi-Agent-Orchestrierung fügt eine neue Variante davon hinzu. Die Audit-Prüfung: Bestätigen Sie für jeden Hand-off in Ihrem Graphen, dass es ein explizites Bestätigungsereignis vom empfangenden Agenten gibt, nicht nur einen „Gesendet"-Status vom ausgehenden. Wenn Sie die Bestätigung nicht verifizieren können, können Sie nicht verifizieren, dass der Hand-off abgeschlossen wurde.

Loop-Fallen

Eine Loop-Falle entsteht, wenn Agent B die Bedingung zum Vorankommen nicht erfüllt und die Arbeit an Agent A zurückgibt. Agent A bewertet neu, scheitert an seiner eigenen Exit-Bedingung und gibt an Agent B zurück. Der Lead kreist zwischen zwei Agenten, bis ein Timeout ausgelöst wird oder ein Mensch in die Queue schaut.

Das konkrete Beispiel: ein Qualifizierungsagent, der einen MEDDIC-Score über einem Schwellenwert benötigt, um einen Deal voranzutreiben, kombiniert mit einem Research-Agenten, der immer dann neu startet, wenn die Qualifizierung unvollständige Daten zurückgibt. Wenn der Research-Agent die Daten nicht finden kann, die der Qualifizierungsagent benötigt, entsteht eine Schleife. Die Audit-Prüfung: Jeder Hand-off-Pfad benötigt einen definierten „Kein-Vorwärts"-Ausgang: entweder eine maximale Anzahl von Wiederholungsversuchen, einen Fallback-Zustand (z. B. Human-Review-Queue) oder einen expliziten Fehlerzustand, der in einem Bericht erscheint.

Authority Drift

Authority Drift ist der am wenigsten offensichtliche und der gefährlichste Fehlermodus. Er tritt auf, wenn ein Agent Felder schreibt, die er nicht besitzen sollte, weil die Orchestrierungsebene keine agentenspezifischen Feldberechtigungen durchsetzt.

So geschieht es: Ihr CRM-Update-Agent ist dafür ausgelegt, Opportunity-Betrag und Abschlussdatum zu schreiben. Während der Orchestrierungskonfiguration erhält er jedoch breiten Schreibzugriff, weil es einfacher war, einmal zu konfigurieren als per Feld einzuschränken. Der nachgelagerte Qualifizierungsagent bemerkt eine Diskrepanz und schreibt eine Korrektur in dieselben Felder. Jetzt schreiben zwei Agenten dieselben Opportunity-Felder mit unterschiedlicher Logik, und der Feldverlauf zeigt eine Abfolge von Aktualisierungen, die kein Mensch absichtlich vorgenommen hat.

Die Audit-Prüfung: Jeder Agent im Orchestrierungsgraphen benötigt einen dokumentierten Feldschreib-Umfang. Dieser Umfang sollte auf Berechtigungsebene durchgesetzt werden, nicht nur als Konfigurationskonvention. Prüfen Sie jetzt, ob Ihr aktuelles Agentforce-Setup agentenspezifische Objektberechtigungen durchsetzt oder ob die Orchestrierungsebene den organisationsweiten Agenten-Berechtigungssatz erbt.

Das Hand-Off-Triplet-Framework

Dokumentieren Sie für jeden Agenten-zu-Agenten-Hand-off in Ihrem Orchestrierungsgraphen drei Dinge. Das ist das Hand-Off-Triplet.

Auslösebedingung. Welches spezifische Ereignis, welcher Feldwert oder welcher Schwellenwert veranlasst Agent A, Arbeit an Agent B zu übergeben? Seien Sie präzise: „wenn der Lead-Score 75 überschreitet" ist eine Auslösebedingung. „Wenn der Agent bereit ist" ist keine.

Feldschreib-Berechtigung. Welche CRM-Felder darf Agent A vor dem Hand-off schreiben? Welche Felder darf Agent B nach dem Empfang schreiben? Diese Listen sollten sich nicht überschneiden. Wenn sie es tun, entscheiden Sie, welcher Agent Vorrang hat, und dokumentieren Sie das explizit.

Rollback-Pfad. Was passiert mit dem Datensatz, wenn Agent B nach dem Hand-off einen Fehler hat? Bleibt der letzte Schreibvorgang von Agent A bestehen? Verbleibt die Opportunity in der Stage, die Agent A gesetzt hat? Gibt es eine Queue, in der Fehler für die manuelle Überprüfung auftauchen, oder werden sie still protokolliert?

Hier ein Beispiel. Der Hand-off zwischen Qualifizierungsagent und CRM-Update-Agent in einem Standard-Agentforce-Workflow:

• Auslösebedingung: Qualifizierungsagent setzt Stage = „SQL" (Sales-Qualified Lead) und MEDDIC-Score >= 80
• Feldschreib-Berechtigung: Qualifizierungsagent schreibt nur Stage- und MEDDIC-Score-Felder. CRM-Update-Agent schreibt nur Betrag, Abschlussdatum und Forecast-Kategorie-Felder. Keine Überschneidung.
• Rollback-Pfad: Wenn der CRM-Update-Agent einen Fehler hat, behalten Stage- und MEDDIC-Score-Felder ihre letzten Werte vom Qualifizierungsagenten. Ein Fehlerereignis wird an die Sales Ops-Review-Queue in Salesforce gesendet. Der Deal wird mit dem Status „Agentenfehler: Manuelle Überprüfung" gekennzeichnet.

Ohne den Rollback-Pfad hinterlässt ein Fehler im CRM-Update-Agenten einen Deal dauerhaft im SQL-Stadium ohne Abschlussdatum, ohne Betrag und ohne Signal, dass etwas schiefgelaufen ist. Dieser Deal wird in Pipeline-Coverage-Berichten auftauchen, Forecast-Zahlen aufblähen und schließlich in einem Pipeline-Review auffallen: drei Wochen später, wenn ein Manager sich fragt, warum der Deal eingeschlafen ist.

Für Teams, die ihr Pipeline-Stage-Design überarbeiten, um agentengesteuerte Progression zu berücksichtigen, lohnt es sich, das Pipeline-Stages-Design-Framework vor dem 15. Juni zu überprüfen. Die Exit-Kriterien der Agenten müssen mit der Stage-Logik übereinstimmen, der Ihre Vertriebsmitarbeitenden und Manager bereits vertrauen.

Slack First Sales: Das zweite Audit

Slack First Sales schafft eine zweite Übergabe-Kategorie: den Rep-zu-Agent-Schreib-Pfad, der über Slack verläuft. Wenn ein Mitarbeitender auf einen Deal-Hinweis in Slack antwortet und ein Agent diese Antwort interpretiert und zurück in Salesforce schreibt, müssen drei Fragen vor dem 15. Juni beantwortet werden.

• Wer ist für den Feldschreibvorgang verantwortlich? Wenn ein Agent auf Basis einer Slack-Antwort in einen Opportunity-Datensatz schreibt, erscheint dieser Schreibvorgang unter dem Profil des Agenten oder des Mitarbeitenden? Das ist relevant für Audit-Logs und für die Zuordnung bei Provisionsstreitigkeiten.
• Wo liegt die Berechtigungsgrenze? Der Agent, der von einer Slack-Interaktion aus in Salesforce schreibt, benötigt dieselbe Durchsetzung des Feldschreib-Umfangs wie jeder andere Agent in Ihrem Orchestrierungsgraphen. Bestätigen Sie, dass der Slack-ausgelöste Pfad dasselbe Berechtigungsmodell durchläuft wie Ihre direkt konfigurierten Agenten, nicht einen separaten, weniger eingeschränkten Pfad.
• Wird die Interaktion protokolliert? Slack-Nachrichten sind standardmäßig keine Salesforce-Aktivitätsdatensätze. Wenn die Slack-Antwort eines Mitarbeitenden die Grundlage dafür ist, dass ein Agent eine Stage-Änderung schreibt, ist diese Slack-Nachricht der Beweispfad für die Änderung. Bestätigen Sie, dass Ihre Slack-zu-Salesforce-Aktivitätssynchronisierung vor dem 15. Juni aktiv ist, sonst werden Sie CRM-Schreibvorgänge ohne menschlich lesbare Begründung vorfinden.

Für Teams, die CRM-Datenmodell-Design im Hinblick auf agentengesteuerte Schreibvorgänge durchdenken, wird die Frage der Feldverantwortung drängender, wenn Agenten und nicht Vertriebsmitarbeitende die primären Schreibenden bei wichtigen Opportunity-Feldern sind.

Das 5-Fragen-Pre-June-15-Audit

Setzen Sie diese fünf Fragen für diese Woche in Ihren Kalender. Blockieren Sie zwei Stunden, öffnen Sie Ihre Agentforce-Konfiguration und arbeiten Sie jede einzelne durch.

1. Haben Sie eine dokumentierte Liste aller Agenten-zu-Agenten-Hand-offs in Ihrem aktuellen Agentforce-Setup? Falls nicht, erstellen Sie jetzt eine Übersicht. Sie können nichts prüfen, was Sie nicht benannt haben.
2. Können Sie für jeden Hand-off die Auslösebedingung präzise benennen? Vage Auslöser führen zu inkonsistentem Verhalten. Wenn Ihre Antwort das Wort „ungefähr" oder „wenn es bereit zu sein scheint" enthält, präzisieren Sie die Definition.
3. Hat jeder Agent einen dokumentierten Feldschreib-Umfang, und wird dieser Umfang auf Berechtigungsebene durchgesetzt? Konfigurationskonventionen driften. Berechtigungsdurchsetzung nicht.
4. Hat jeder Hand-off einen definierten Rollback-Pfad für den Fehlerzustand? Gehen Sie das Fehlerszenario für jeden Hand-off durch: Wie sieht der Datensatz aus, wenn der empfangende Agent einen Fehler hat? Ist dieser Zustand ohne manuelle Eingriffe wiederherstellbar?
5. Für alle Slack First Sales-Interaktionen: Ist Ihre Slack-zu-Salesforce-Aktivitätssynchronisierung aktiv, und haben Sie bestätigt, welche Slack-ausgelösten Schreibvorgänge unter dem Profil des Agenten und welche unter dem des Mitarbeitenden erscheinen? Führen Sie eine Testinteraktion vor dem 15. Juni durch, nicht danach.

Teams, die KI-Lead-Scoring-Fehlermodi durchgearbeitet haben, werden dasselbe Muster erkennen: Das Problem ist meistens nicht das KI-Modell, sondern die Governance-Ebene darum herum: was das Modell schreiben darf und wer die Outputs überprüft. Orchestrierung skaliert diese Oberfläche erheblich.

Was Sie diese Woche tun sollten

Sie haben noch ungefähr 13 Tage, bis Summer '26 live geht. Das ist das Wichtigste vor dem 15. Juni.

Den Graphen abbilden. Listen Sie jeden Agenten in Ihrer Agentforce-Organisation auf und zeichnen Sie die Übergabe-Verbindungen zwischen ihnen ein. Das ist Schritt null. Nichts anderes im Audit ist ohne diesen Schritt möglich.

Das Hand-Off-Triplet auf jede Verbindung anwenden. Dokumentieren Sie für jeden Hand-off im Graphen die Auslösebedingung, die Feldschreib-Berechtigung auf jeder Seite und den Rollback-Pfad. Drei Spalten, eine Zeile pro Hand-off. Beginnen Sie mit den Hand-offs, die die am häufigsten genutzten Opportunity-Felder berühren: Stage, Betrag, Abschlussdatum, Forecast-Kategorie.

Feldschreib-Umfänge auf Berechtigungsebene durchsetzen. Verlassen Sie sich nicht auf Konfigurationskonventionen, die davon abhängen, dass zukünftige Admins die undokumentierten Absichten des aktuellen Admins befolgen. Wenn Agent A das Betrag-Feld nicht schreiben soll, entfernen Sie diese Berechtigung explizit.

Ihre Fehler-Queue einrichten. Entscheiden Sie, wo Agentenfehler erscheinen und wer sie überprüft. Wenn Sie heute keine Sales Ops-Review-Queue für Agentenfehler haben, richten Sie eine vor dem 15. Juni ein, nicht erst nachdem Sie Phantom-Hand-offs in den Pipeline-Daten bemerkt haben.

Eine Slack First Sales-Testinteraktion durchführen. Bevor es für Ihre gesamte Organisation live geht, lösen Sie manuell eine Slack-Interaktion aus, bestätigen Sie, dass der Feldschreibvorgang korrekt in Salesforce erscheint, überprüfen Sie das Aktivitätsprotokoll und kontrollieren Sie, welcher Profilname auf dem Schreibvorgang erscheint.

Die Pipeline-Hygiene-Praktiken, die Pipeline-Daten in einem menschengesteuerten Prozess sauber halten, sind in einem agentengesteuerten doppelt so wichtig. Agenten entschuldigen sich nicht für schlechte Daten, sie skalieren sie. Richten Sie die Governance vor dem 15. Juni ein, und die Orchestrierungsebene wird zu einem echten Revenue Operations-Vorteil. Überspringen Sie dieses Audit, und Sie werden den Sommer mit Incident-Reports verbringen.

---

FAQ

Müssen wir die Multi-Agent-Orchestrierung am ersten Tag deaktivieren?

Nicht unbedingt. Aber Sie müssen vor dem 15. Juni genau wissen, welche Agenten in Ihrer Organisation so verdrahtet sind, dass sie Arbeit aneinander übergeben. Wenn Sie diese Frage heute nicht beantworten können, ist ein konservativer Ansatz, die Orchestrierung für Ihre sensibelsten Opportunity-Felder zu deaktivieren: Stage, Betrag, Abschlussdatum, bis Sie das Hand-Off-Triplet-Audit abgeschlossen haben. Sie können sie schrittweise wieder aktivieren, sobald Sie jeden Hand-off ordnungsgemäß dokumentiert haben.

Was ist der Unterschied zwischen Multi-Agent-Orchestrierung und einem Salesforce Flow?

Ein Salesforce Flow ist eine konfigurierte Automatisierung, die vordefinierte Schritte auf Basis expliziter Logik ausführt, die Sie schreiben. Multi-Agent-Orchestrierung ist anders: Agenten treffen begründungsbasierte Entscheidungen darüber, wann sie übergeben und was sie weitergeben. Flows sind deterministisch; orchestrierte Agenten sind es nicht. Genau deshalb ist das Hand-Off-Triplet so wichtig: Sie können die Logik eines Flows lesen, um zu verstehen, was der Flow tut. Was ein Agent entschieden hat weiterzugeben, lässt sich nicht aus einer Konfigurationsdatei ablesen. Dafür brauchen Sie eine dokumentierte Auslösebedingung, die es ermöglicht zu überprüfen, ob das Agentenverhalten Ihrer Absicht entspricht.

Wo steht Slack First Sales in unserem Audit-Log?

Standardmäßig sind Slack-Nachrichten keine Salesforce-Aktivitätsdatensätze. Wenn die Slack-Antwort eines Mitarbeitenden einen Agenten-Write in Salesforce auslöst, erscheint dieser Schreibvorgang im Feldverlauf des Datensatzes. Die Slack-Nachricht, die ihn verursacht hat, erscheint jedoch nicht automatisch als zugehörige Aktivität. Sie benötigen die Slack-zu-Salesforce-Aktivitätssynchronisierung, die so konfiguriert ist, dass Slack-Interaktionen als Aktivitäten auf dem relevanten Datensatz protokolliert werden. Bestätigen Sie, dass dies vor dem 15. Juni aktiv ist, sonst haben Sie Feldverlaufseinträge ohne menschlich lesbare Begründung.