Salesforce Summer '26 Luncurkan Multi-Agent Orchestration 15 Juni. Ini Audit Sales Ops Sebelum Agen Anda Mulai Saling Meneruskan Pekerjaan

15 Juni tinggal dua minggu lagi, dan fitur paling krusial bagi tim Sales Ops bukan dashboard baru atau forecast yang lebih cerdas. Ini adalah masalah tata kelola baru.

Rilis Salesforce Summer '26 akan tersedia secara umum (GA) pada 15 Juni 2026, dan berita utama bagi Sales Ops adalah Multi-Agent Orchestration di dalam Agentforce: kemampuan untuk menghubungkan beberapa agen secara berurutan sehingga mereka dapat saling meneruskan pekerjaan dalam satu alur kerja pendapatan yang menyeluruh. Dipasangkan dengan Slack First Sales, yang menampilkan konteks CRM secara percakapan di dalam Slack sehingga tim penjualan dapat bertindak langsung di tempat mereka bekerja, rilis ini mengubah makna tata kelola proses pendapatan yang didukung AI.

Perubahan ini tidak kecil. Pada penerapan agen tunggal, tugas tata kelola Anda mencakup satu agen: apa yang dibacanya, apa yang ditulisnya, apa yang memicunya. Multi-agent orchestration berarti agen-agen Anda kini saling meneruskan pekerjaan satu sama lain, dan setiap titik perpindahan tersebut merupakan celah di mana pipeline dapat bocor, berputar, atau menyimpang tanpa ada manusia yang menyadarinya. Data State of Sales 2026 dari Salesforce mempertegas bahwa ini penting dalam skala besar: hampir sembilan dari sepuluh tenaga penjual berencana menggunakan agen AI pada 2027, dan agen AI diproyeksikan memangkas waktu riset sebesar 34%. Itulah banyaknya agen yang menyentuh banyak deal. Jika grafik hand-off salah dikonfigurasi sebelum 15 Juni, Anda akan menghabiskan paruh kedua tahun ini mengurai lead-lead hantu.

Apa yang Benar-Benar Diluncurkan pada 15 Juni

Fakta Kunci

• Tanggal GA Summer '26: 15 Juni 2026 (sumber: Salesforce Newsroom)
• Tenaga penjual yang berencana menggunakan agen AI pada 2027: hampir 9 dari 10 (sumber: Salesforce State of Sales 2026)
• Proyeksi pengurangan waktu riset dari agen AI: 34% (sumber: Salesforce State of Sales 2026)

Multi-Agent Orchestration adalah perubahan inti: agen-agen Agentforce individual kini dapat dihubungkan dalam sebuah urutan di mana output satu agen menjadi input agen berikutnya. Sebuah agen riset dapat menyelesaikan pengumpulan intelijen prospek dan meneruskan paketnya ke agen outreach. Agen outreach menilai keterlibatan dan meneruskan ke agen kualifikasi. Agen kualifikasi membuat keputusan stage dan meneruskan ke agen pembaruan CRM. Agen pembaruan CRM menulis field-field dan meneruskan ke agen forecasting. Itu berarti lima agen menyentuh satu deal, tanpa manusia dalam loop untuk langkah-langkah perantara.

Slack First Sales diluncurkan bersamaan. Data CRM muncul di dalam thread Slack dalam bentuk percakapan, sehingga tim penjualan dapat merespons dorongan deal tanpa meninggalkan Slack. Agen menuliskan hasil interaksi tersebut kembali ke Salesforce secara otomatis. Bagi tim yang sudah terbiasa bekerja di Slack, ini benar-benar berguna. Namun ini menimbulkan pertanyaan tata kelola kedua: siapa yang memiliki jejak audit ketika balasan Slack seorang rep memicu penulisan agen ke Salesforce?

Sisa fitur Summer '26 mencakup pembaruan di Einstein, Data Cloud, dan cloud industri. Artikel ini khusus membahas lapisan orchestration dan hand-off Slack. Pembaruan agen keterlibatan pelanggan dari Summer '26 telah dibahas secara terpisah untuk evaluasi di level CRO.

Mengapa Multi-Agent Orchestration Mengubah Pekerjaan Sales Ops

Sebelum orchestration, daftar periksa tata kelola Agentforce Anda kurang lebih seperti satu baris: satu agen, izin baca, izin tulis, kondisi pemicu, status error.

Setelah orchestration, satu baris tersebut berubah menjadi grafik. Dan grafik itulah permukaan tata kelola yang baru.

Bayangkan seperti apa alur kerja pendapatan lima agen saat berjalan. Agen riset meminta data dari sumber eksternal dan menulis objek intelijen prospek. Ini memicu agen outreach ketika ambang kepercayaan melampaui nilai tertentu. Agen outreach menghasilkan urutan pesan dan menulis field status keterlibatan. Ini memicu agen kualifikasi ketika prospek membuka sejumlah touchpoint tertentu. Agen kualifikasi mengevaluasi kriteria stage dan menulis field stage opportunity. Ini memicu agen pembaruan CRM ketika kriteria terpenuhi. Agen pembaruan CRM menulis field-field deal di seluruh record opportunity. Ini memicu agen forecasting di akhir minggu. Agen forecasting memperbarui kategori commit.

Itu delapan peristiwa hand-off yang berbeda di antara lima agen, masing-masing menyentuh objek dan field CRM yang berbeda. Jika salah satu hand-off tersebut gagal, record di hilir menjadi salah. Dan karena tidak ada manusia yang menyetujui langkah-langkah perantara, data yang salah terus bertambah sebelum siapa pun melihatnya dalam laporan.

Inilah mengapa tugas Anda sebagai Sales Ops bergeser dari "konfigurasi satu agen" menjadi "memiliki grafik hand-off." Grafik itulah tempat tata kelola proses pendapatan kini berada. Jika Anda tidak merancangnya dengan saksama sebelum 15 Juni, perilaku default akan aktif dan Anda mewarisi kondisi pemicu bawaan Salesforce yang dihasilkan dalam lingkungan data spesifik Anda.

Untuk konteks lebih mendalam tentang cara kerja tata kelola AI sales ops dan jejak audit di seluruh tumpukan AI Sales Ops yang lebih luas, kerangka kerja tersebut berlaku langsung di sini karena orchestration membuat persyaratan jejak audit semakin kompleks.

Tiga Mode Kegagalan Hand-Off yang Harus Diblokir Sales Ops

Phantom Hand-off

Phantom hand-off terjadi ketika Agen A menandai pekerjaan sebagai telah diteruskan, tetapi Agen B tidak pernah memprosesnya. Lead terhenti dalam kondisi mati di antara dua antrean agen. Tidak ada agen yang memunculkan error. Tidak ada peringatan yang terpicu. Opportunity hanya berhenti bergerak.

Ini adalah mode kegagalan paling umum dalam sistem berbasis antrean, dan multi-agent orchestration menambahkan versi baru dari masalah ini. Pemeriksaan audit: untuk setiap hand-off dalam grafik Anda, pastikan ada peristiwa pengakuan eksplisit dari agen penerima, bukan hanya status "terkirim" dari agen pengirim. Jika Anda tidak dapat memverifikasi pengakuan, Anda tidak dapat memverifikasi bahwa hand-off telah selesai.

Loop Trap

Loop trap terjadi ketika Agen B tidak memenuhi kondisi untuk maju dan meneruskan pekerjaan kembali ke Agen A. Agen A mengevaluasi ulang, gagal memenuhi kondisi keluarnya sendiri, dan meneruskan kembali ke Agen B. Lead berputar di antara dua agen hingga timeout terpicu atau seseorang menelusuri antrean secara manual.

Contoh konkretnya: agen kualifikasi yang memerlukan skor MEDDIC di atas ambang tertentu untuk memajukan deal, dipasangkan dengan agen riset yang berjalan ulang setiap kali kualifikasi mengembalikan data yang tidak lengkap. Jika agen riset tidak dapat menemukan data yang dibutuhkan agen kualifikasi, keduanya berputar. Pemeriksaan audit: setiap jalur hand-off memerlukan titik keluar "tidak-maju" yang terdefinisi, baik berupa jumlah percobaan ulang maksimum, status cadangan (seperti antrean tinjauan manusia), atau status error eksplisit yang muncul dalam laporan.

Authority Drift

Authority drift adalah yang paling tidak kentara dan paling berbahaya. Ini terjadi ketika sebuah agen menulis ke field yang tidak dirancang untuk dimilikinya karena lapisan orchestration tidak menerapkan izin field per agen.

Begini cara terjadinya. Agen pembaruan CRM Anda dirancang untuk menulis amount opportunity dan tanggal penutupan. Namun saat pengkabelan orchestration, seseorang memberikan akses tulis yang luas karena lebih mudah dikonfigurasi sekali daripada per field. Agen kualifikasi di hilir menemukan ketidaksesuaian dan menulis koreksi ke field yang sama. Kini dua agen menulis ke field opportunity yang sama, masing-masing dengan logika yang berbeda, dan riwayat field menampilkan rangkaian pembaruan yang tidak dibuat oleh manusia secara sengaja.

Pemeriksaan audit: setiap agen dalam grafik orchestration memerlukan lingkup penulisan field yang terdokumentasi. Lingkup tersebut harus diterapkan di tingkat izin, bukan hanya sebagai konvensi konfigurasi. Periksa sekarang apakah pengaturan Agentforce Anda saat ini menerapkan izin objek per agen atau apakah lapisan orchestration mewarisi kumpulan izin agen pada level organisasi secara keseluruhan.

Kerangka Hand-Off Triplet

Untuk setiap hand-off agen-ke-agen dalam grafik orchestration Anda, dokumentasikan tiga hal. Inilah Hand-Off Triplet.

Kondisi pemicu. Peristiwa, nilai field, atau ambang spesifik apa yang menyebabkan Agen A meneruskan pekerjaan ke Agen B? Bersikaplah presisi: "ketika skor lead melampaui 75" adalah kondisi pemicu. "Ketika agen memutuskan sudah siap" bukan kondisi pemicu.

Otoritas penulisan field. Field CRM apa yang boleh ditulis Agen A sebelum hand-off? Field apa yang boleh ditulis Agen B setelah menerimanya? Daftar ini tidak boleh tumpang tindih. Jika tumpang tindih, tentukan agen mana yang memiliki prioritas dan dokumentasikan secara eksplisit.

Jalur rollback. Jika Agen B mengalami error setelah menerima hand-off, apa yang terjadi pada record tersebut? Apakah tulisan terakhir Agen A tetap ada? Apakah opportunity tetap berada di stage yang ditetapkan Agen A? Apakah ada antrean tempat error muncul untuk ditinjau manusia, atau apakah error tersebut dicatat secara diam-diam?

Berikut sebuah contoh. Hand-off antara agen kualifikasi dan agen pembaruan CRM dalam alur kerja Agentforce standar:

• Kondisi pemicu: Agen kualifikasi menetapkan Stage = "SQL" (sales-qualified lead) dan skor MEDDIC >= 80
• Otoritas penulisan field: Agen kualifikasi hanya menulis field Stage dan Skor MEDDIC. Agen pembaruan CRM hanya menulis field Amount, Close Date, dan Forecast Category. Tidak ada tumpang tindih.
• Jalur rollback: Jika agen pembaruan CRM mengalami error, field Stage dan Skor MEDDIC mempertahankan nilai terakhirnya dari agen kualifikasi. Peristiwa error terpicu ke antrean tinjauan Sales Ops di Salesforce. Deal ditandai dengan status "Error agen - tinjauan manual diperlukan."

Tanpa jalur rollback, error pada agen pembaruan CRM membuat deal terjebak di stage SQL selamanya tanpa tanggal penutupan, tanpa amount, dan tanpa sinyal bahwa ada yang salah. Deal tersebut akan muncul dalam laporan cakupan pipeline, menggelembungkan angka forecast, dan akhirnya terdeteksi dalam tinjauan pipeline oleh manajer yang bertanya-tanya mengapa deal tersebut tiba-tiba dingin, tiga minggu kemudian.

Bagi tim yang sedang merancang ulang stage pipeline untuk mengakomodasi progresion yang digerakkan agen, kerangka desain stage pipeline layak ditinjau kembali sebelum 15 Juni karena kriteria keluar agen harus sesuai dengan logika stage yang sudah dipercaya oleh tim penjualan dan manajer Anda.

Slack First Sales: Audit Kedua

Slack First Sales menciptakan kategori hand-off kedua: jalur penulisan rep-ke-agen yang berjalan melalui Slack. Ketika seorang rep merespons dorongan deal di Slack dan agen menginterpretasikan balasan tersebut lalu menulis kembali ke Salesforce, tiga pertanyaan perlu dijawab sebelum 15 Juni.

• Siapa yang memiliki penulisan field? Ketika agen menulis ke record opportunity berdasarkan balasan Slack, apakah penulisan tersebut muncul di bawah profil agen atau profil rep? Ini penting untuk log audit dan untuk atribusi dalam sengketa komisi.
• Di mana batas izin berada? Agen yang menulis ke Salesforce dari interaksi Slack memerlukan penerapan lingkup penulisan field yang sama seperti agen lain dalam grafik orchestration Anda. Konfirmasikan bahwa jalur yang dipicu Slack melewati model izin yang sama dengan agen yang dikonfigurasi langsung, bukan jalur terpisah yang kurang terbatas.
• Apakah interaksi tersebut dicatat? Pesan Slack secara default bukan record aktivitas Salesforce. Jika balasan Slack seorang rep menjadi dasar bagi agen untuk menulis perubahan stage, pesan Slack tersebut adalah jejak bukti untuk perubahan itu. Konfirmasikan bahwa sinkronisasi aktivitas Slack-ke-Salesforce Anda berjalan sebelum 15 Juni, atau Anda akan memiliki penulisan CRM tanpa alasan yang dapat dibaca manusia.

Bagi tim yang mempertimbangkan desain model data CRM terkait penulisan yang digerakkan agen, pertanyaan kepemilikan field menjadi semakin mendesak ketika agen, bukan rep, adalah penulis utama pada field opportunity kunci.

Audit 5 Pertanyaan Sebelum 15 Juni

Masukkan lima pertanyaan ini ke kalender Anda untuk minggu ini. Blokir dua jam, buka konfigurasi Agentforce Anda, dan kerjakan satu per satu.

1. Apakah Anda memiliki daftar terdokumentasi dari setiap hand-off agen-ke-agen dalam pengaturan Agentforce Anda saat ini? Jika belum, petakan sekarang. Anda tidak bisa mengaudit apa yang belum Anda beri nama.
2. Untuk setiap hand-off, dapatkah Anda menyatakan kondisi pemicu secara presisi? Pemicu yang samar menghasilkan perilaku yang tidak konsisten. Jika jawaban Anda mengandung kata "kira-kira" atau "ketika tampaknya sudah siap," perjelas definisinya.
3. Apakah setiap agen memiliki lingkup penulisan field yang terdokumentasi, dan apakah lingkup tersebut diterapkan di tingkat izin? Konvensi konfigurasi bisa menyimpang. Penerapan izin tidak.
4. Apakah setiap hand-off memiliki jalur rollback yang terdefinisi untuk kondisi error? Jalankan skenario kegagalan untuk setiap hand-off: seperti apa record jika agen penerima mengalami error? Apakah kondisi tersebut dapat dipulihkan tanpa intervensi manual?
5. Untuk interaksi Slack First Sales: apakah sinkronisasi aktivitas Slack-ke-Salesforce Anda aktif, dan sudahkah Anda mengonfirmasi penulisan yang dipicu Slack muncul di bawah profil agen versus profil rep? Jalankan interaksi uji coba sebelum 15 Juni, bukan sesudahnya.

Tim yang telah mendalami mode kegagalan AI lead scoring akan mengenali pola yang sama di sini: kegagalan biasanya bukan pada model AI, melainkan pada lapisan tata kelola seputar apa yang boleh ditulis model tersebut dan siapa yang meninjau outputnya. Orchestration memperluas permukaan tersebut secara signifikan.

Apa yang Harus Dilakukan Minggu Ini

Anda memiliki sekitar 13 hari sebelum Summer '26 aktif. Ini yang paling penting sebelum 15 Juni.

Petakan grafik. Daftarkan setiap agen dalam organisasi Agentforce Anda dan gambarkan koneksi hand-off di antara mereka. Ini adalah Langkah Nol. Tidak ada langkah lain dalam audit yang mungkin dilakukan tanpanya.

Terapkan Hand-Off Triplet pada setiap koneksi. Untuk setiap hand-off dalam grafik, dokumentasikan kondisi pemicu, otoritas penulisan field di setiap sisi, dan jalur rollback. Tiga kolom, satu baris per hand-off. Mulai dari hand-off yang menyentuh field opportunity yang paling sering digunakan: Stage, Amount, Close Date, Forecast Category.

Terapkan lingkup penulisan field di tingkat izin. Jangan mengandalkan konvensi konfigurasi yang bergantung pada admin masa depan untuk mengikuti niat admin saat ini yang tidak terdokumentasi. Jika Agen A tidak seharusnya menulis field Amount, cabut izin tersebut secara eksplisit.

Siapkan antrean error Anda. Tentukan di mana error agen muncul dan siapa yang meninjaunya. Jika Anda belum memiliki antrean tinjauan Sales Ops untuk error agen hari ini, bangun sebelum 15 Juni, bukan setelah Anda menyadari phantom hand-off dalam data pipeline.

Jalankan interaksi uji coba Slack First Sales. Sebelum aktif untuk seluruh organisasi Anda, picu interaksi Slack secara manual, konfirmasikan penulisan field muncul dengan benar di Salesforce, verifikasi log aktivitas, dan periksa nama profil mana yang muncul pada penulisan tersebut.

Praktik kebersihan pipeline yang menjaga data pipeline tetap bersih dalam proses yang digerakkan manusia menjadi dua kali lebih penting dalam proses yang digerakkan agen. Agen tidak membuat alasan untuk data yang buruk, mereka mengamplifikasinya dalam skala besar. Tata kelola yang benar sebelum 15 Juni akan menjadikan lapisan orchestration sebagai aset operasi pendapatan yang sesungguhnya. Lewati audit ini, dan Anda akan menghabiskan musim panas dalam laporan insiden.

---

FAQ

Apakah kami perlu menonaktifkan Multi-Agent Orchestration pada hari pertama?

Belum tentu. Namun Anda perlu mengetahui dengan tepat agen mana dalam organisasi Anda yang dihubungkan untuk saling meneruskan pekerjaan sebelum 15 Juni aktif. Jika Anda tidak dapat menjawab pertanyaan itu hari ini, pendekatan konservatif adalah menonaktifkan orchestration untuk field opportunity paling sensitif Anda, yaitu Stage, Amount, Close Date, sampai Anda menyelesaikan audit Hand-Off Triplet. Anda dapat mengaktifkan kembali secara bertahap seiring Anda mendokumentasikan setiap hand-off dengan benar.

Apa perbedaan antara Multi-Agent Orchestration dan Salesforce Flow?

Salesforce Flow adalah otomasi yang dikonfigurasi dan menjalankan langkah-langkah yang telah ditentukan berdasarkan logika eksplisit yang Anda tulis. Multi-Agent Orchestration berbeda: agen membuat keputusan berbasis penalaran tentang kapan harus meneruskan dan apa yang harus diteruskan. Flow bersifat deterministik; agen yang diorkestrasi tidak. Itulah tepatnya mengapa Hand-Off Triplet penting, karena Anda tidak bisa membaca logika flow untuk memahami apa yang diputuskan agen untuk diteruskan. Anda memerlukan kondisi pemicu yang terdokumentasi untuk memverifikasi bahwa perilaku agen sesuai dengan niat Anda.

Di mana Slack First Sales berada dalam log audit kami?

Secara default, pesan Slack bukan record aktivitas Salesforce. Ketika balasan Slack seorang rep memicu penulisan agen ke Salesforce, penulisan tersebut akan muncul dalam riwayat field pada record, tetapi pesan Slack yang menyebabkannya tidak akan otomatis muncul sebagai aktivitas terkait. Anda perlu mengaktifkan dan mengonfigurasi sinkronisasi aktivitas Slack-ke-Salesforce untuk mencatat interaksi Slack sebagai aktivitas pada record yang relevan. Konfirmasikan ini aktif sebelum 15 Juni, atau Anda akan memiliki entri riwayat field tanpa alasan yang dapat dibaca manusia.