2025 Mungkin Menjadi Tahun Agen AI, Jika Mereka Dapat Bertahan dari Neraka Perusahaan

Selama beberapa dekade, bisnis telah berupaya mengotomatiskan tugas-tugas administrasi, entri data, proses penagihan, dan alur kerja berulang lainnya. Namun, meskipun perangkat lunak telah berkembang, otomatisasi menyeluruh yang sesungguhnya masih sulit dipahami oleh sebagian besar perusahaan. Kini, dengan pesatnya perkembangan Large Language Models (LLM), dan munculnya "agen AI" yang mampu bernalar dan bertindak secara mandiri, ada keyakinan yang berkembang bahwa tahun 2025 mungkin menjadi tahun di mana kita akhirnya melihat lompatan maju yang signifikan dalam otomatisasi perusahaan.

Sam Altman telah menyatakan secara terbuka bahwa "pada tahun 2025, kita mungkin akan melihat agen AI pertama bergabung dengan angkatan kerja dan secara material mengubah output perusahaan," sementara Marc Benioff mengalihkan Salesforce ke arah "AgentForce" untuk mengantisipasi masa depan di mana banyak proses organisasi didelegasikan kepada agen khusus. Prediksi ini menimbulkan pertanyaan utama: dapatkah agen AI mengatasi rintangan rumit dari sistem perusahaan di dunia nyata? Dalam artikel ini, kita akan meneliti kesulitan unik dari otomatisasi perusahaan dan mengeksplorasi beberapa solusi yang menjanjikan (tetapi masih dalam tahap pengembangan) saat ini. Kami juga akan membagikan pengujian langsung dengan alur kerja yang tampaknya mudah di Salesforce (SFDC) — membuat pesanan pengecer untuk akun baru — yang mengungkap kompleksitas yang mengintai di balik layar.

Mengapa Otomatisasi Perusahaan Begitu Menantang?

Di atas kertas, mengotomatiskan tugas-tugas perusahaan terdengar mudah: buat skrip untuk masuk, isi formulir, dan klik "kirim." Dalam praktiknya, kompleksitasnya sangat mencengangkan. Perusahaan bergantung pada berbagai sistem pencatatan seperti Salesforce, SAP, Oracle, dan banyak solusi buatan sendiri. Setiap sistem memiliki jaringan izin, alur autentikasi, dan logika bisnis khusus sendiri. Terlebih lagi, sistem-sistem ini sering kali sangat disesuaikan. Merupakan hal yang umum untuk melihat UI khusus, bidang data tambahan, dan alur kerja khusus yang berbeda dari satu bisnis ke bisnis lainnya.

Menurut survei gabungan oleh MuleSoft dan Deloitte, perusahaan besar mungkin menggunakan rata-rata 976 sistem berbeda untuk mendukung operasi harian ( sumber ). Fragmentasi ini berarti alat otomatisasi harus berkomunikasi dengan beberapa sistem, masing-masing dengan nuansanya sendiri; beberapa dengan API yang tangguh, yang lain tidak memilikinya sama sekali. Sering kali, tugas yang paling sederhana melibatkan penjembatanan data di seluruh aplikasi lama dan layanan berbasis cloud yang baru. Bahkan platform standar seperti Salesforce dapat menjadi rumit setelah alur kerja khusus dan integrasi pihak ketiga diterapkan.

Dengan latar belakang ini, agen yang didukung LLM menjanjikan pendekatan yang lebih fleksibel: mereka dapat mengurai data, bernalar tentang langkah selanjutnya, dan bahkan menavigasi GUI yang rumit — setidaknya secara teori. Namun seperti yang akan Anda lihat dalam contoh berikut, kenyataan untuk meminta agen AI melakukan alur kerja Salesforce dasar tanpa bantuan manusia lebih rumit daripada yang disadari banyak orang.

Contoh Praktis: Membuat Pesanan Reseller Kustom di Salesforce

Tugas

Bayangkan Anda adalah seorang asisten penjualan di sebuah perusahaan manufaktur sepeda yang menggunakan Salesforce. Anda baru saja menjual 1 sepeda Dynamo X1 berukuran besar seharga $5.000 kepada pengecer baru bernama “Northern Trail Cycling”. Tugas Anda adalah:

1 - Autentikasi ke Salesforce (dengan kredensial yang disediakan).

2 - Buat akun baru untuk pengecer.

3 - Buat pesanan pengecer dan tambahkan item baris (sepeda).

4 - Kirimkan pesanan itu ke bagian manufaktur untuk disetujui.

Agar eksekusi berhasil, kami mengharapkan hasil akhir terlihat seperti berikut:

Tampaknya cukup sederhana, tetapi inti permasalahannya ada pada detailnya. Instans Salesforce perusahaan tersebut disesuaikan: menggunakan objek dan alur "pesanan reseller" khusus, fitur drag-and-drop khusus untuk menambahkan produk, dan langkah "submit to manufacturing" tersembunyi tanpa pelabelan yang jelas. Saya menguji skenario ini menggunakan beberapa pendekatan otomatisasi berbasis AI yang sedang berkembang untuk melihat bagaimana pendekatan tersebut berhasil.

Penggunaan Komputer Claude

Apa itu?

Claude Computer Use adalah fitur baru dari Anthropic, yang diperkenalkan bersama Claude 3.5 Sonnet v2 . Fitur ini membawa paradigma pemanggilan fungsi LLM standar selangkah lebih maju dengan memberi Claude lingkungan desktop yang sepenuhnya terkontainerisasi untuk "dilihat" dan "dikendalikan." Fitur ini dapat mengambil tangkapan layar, menafsirkannya melalui penalaran visual/spasial, dan melakukan tindakan tingkat OS seperti klik tetikus, gulir, dan penekanan tombol.

Dari sudut pandang pengguna, Anda memberi Claude tugas tingkat tinggi (“Masuk ke Salesforce dan buat pesanan reseller ini”), dan Claude mencoba melakukan hal itu. Tugas ini berulang melalui serangkaian hal berikut:

1. Mengambil tangkapan layar dan menafsirkannya.
2. Mengeluarkan tindakan UI (klik mouse, penekanan tombol, perintah bash).
3. Mengulangi hingga tugas selesai (atau menyerah).

Mengujinya

Mari kita mulai dengan pendekatan paling sederhana untuk menjalankan implementasi referensi Anthropic tanpa perubahan apa pun pada prompt sistem . Berikut ini adalah awal interaksi yang menunjukkan prompt awal, rencana yang diusulkan Claude, dan desktop tempat interaksi dimulai.

Mengamati desktop Claude yang terkontainerisasi awalnya mengesankan. Ia membuka browser, mengunjungi URL Salesforce, masuk dengan kredensial yang diberikan, dan menavigasi ke "Akun." Ia dengan sempurna membuat akun baru untuk Bike Production Company , memasukkan detail yang tepat dalam formulir, lalu mencoba membuat pesanan reseller baru. Semuanya berjalan lancar hingga ia menemukan antarmuka drag-and-drop khusus untuk menambahkan sepeda. Sistem macet saat mencoba melakukan drag-and-drop berbasis piksel.

Setelah beberapa kali gagal, ia mencoba mencari metode alternatif (seperti tombol “Tambah Item” yang tersembunyi). Upaya pertamanya dengan tombol “edit” tidak berhasil.

"Saya melihat dalam dialog edit tidak ada cara yang jelas untuk menambahkan produk. Izinkan saya mencoba pendekatan yang berbeda dengan mengeklik menu tarik-turun Pesanan Penjual untuk melihat apakah ada opsi lain".

Akhirnya, aplikasi ini menemukan jalannya dengan menemukan cara untuk menambahkan item baru melalui tab "terkait" — tetapi gagal ketika pemicu dinamis aplikasi tidak memperbarui total pesanan secara otomatis. Pengembang aplikasi SFDC tidak menyelesaikan pengembangan jalur kode ini, karena mengharapkan pengguna manusia untuk mengikuti metode seret dan lepas saja. Singkatnya, alur tersebut dirancang untuk manusia, bukan untuk agen AI.

Claude kemudian mencoba mencari tombol "submit to manufacturing", yang terkubur di bawah tab khusus. Karena tidak memiliki pengetahuan sebelumnya tentang langkah tersebut, tombol itu tidak berfungsi selama beberapa menit. Akhirnya, saya harus campur tangan, menambahkan sepeda secara manual ke pesanan, dan mengarahkan Claude ke tombol yang relevan. Setelah sekitar 10 menit dan biaya penggunaan sekitar $0,80, prosesnya masih belum sepenuhnya otomatis. Mudah untuk melihat mengapa Anthropic menyebut fitur ini eksperimental: banyak pembatas dan perbaikan di dunia nyata yang diperlukan sebelum Computer Use benar-benar siap untuk produksi.

Bisakah Menjadi Lebih Baik?

Meskipun masih belum sempurna, konsepnya menarik. AI berbasis visi untuk interaksi GUI meningkat pesat, dan kurva biaya untuk inferensi menurun dengan cepat. Sebuah studi a16z baru-baru ini menunjukkan bahwa untuk kinerja yang sama, biaya LLM menurun sekitar 10x per tahun. Pada prinsipnya, versi Claude di masa mendatang dapat menjadi lebih cepat, lebih murah, dan lebih akurat pada tugas visual/spasial seperti drag-and-drop.

Namun, masalah mendasarnya tetap bahwa UI perusahaan, terutama yang lama atau yang sangat disesuaikan, jarang dibuat dengan mempertimbangkan otomatisasi. Interaksi tingkat piksel itu rapuh. Perubahan kecil pada tata letak atau pop-up dinamis dapat merusak seluruh alur kerja. Ada juga penelitian yang berkembang seputar kerangka kerja GUI yang berbasis visual, tetapi membuat kerangka kerja ini bermutu produksi untuk ratusan alur kerja yang berbeda merupakan pekerjaan besar.

Browser Tanpa Kepala: Melewati GUI Sepenuhnya

Salah satu pendekatan alternatif adalah mengabaikan "kotak pembatas visual" sepenuhnya. Jika aplikasi target Anda berjalan di browser web, Anda dapat mengotomatiskannya di level DOM, dengan melewatkan tangkapan layar dan interaksi berbasis piksel. Sementara browser headless tradisional seperti Playwright dan Selenium sering dikaitkan dengan kerangka pengujian, generasi baru browser headless yang berfokus pada kasus penggunaan AI sedang muncul. Platform yang lebih baru ini dibangun di atas Playwright dan Selenium untuk memungkinkan interaksi yang lebih dinamis dan bertenaga LLM.

Basis Peramban

BrowserBase adalah salah satu contohnya. Platform ini berfungsi sebagai platform infrastruktur yang menghosting dan menskalakan sesi browser tanpa mengharuskan pengembang mengelola kontainer. Pola interaksi berkisar pada penguraian konten HTML halaman menjadi komponen (misalnya, formulir, tombol) yang dipetakan ke xPath-nya dan meneruskan struktur ini ke LLM pilihan Anda. LLM kemudian menghasilkan rangkaian kode Playwright berikutnya untuk dieksekusi, yang memungkinkan interaksi dengan DOM melalui kode, bukan klik GUI tradisional. Karena sepenuhnya tanpa kepala, ia menggunakan lebih sedikit atau tidak ada tangkapan layar, menjaga panjang konteks tetap pendek dan latensi lebih rendah daripada pendekatan "lingkungan desktop" penuh.

Baru-baru ini, BrowserBase mengirimkan pustaka sumber terbuka StageHand untuk memudahkan para pengembang. Dalam model asli, interaksi masih sangat manual, yang mengharuskan para pengembang untuk bekerja dengan detail tingkat rendah dari browser tanpa kepala, termasuk menulis kode Playwright secara langsung dan mengurai HTML secara manual. Dengan StageHand, BrowserBase menyediakan tingkat abstraksi yang lebih tinggi, yang memungkinkan para pengembang untuk menggunakan perintah bahasa alami berbasis maksud seperti "navigate" atau "extract." Pendekatan ini juga memasukkan beberapa pemrosesan untuk mengubah HTML mentah menjadi komponen, sehingga memudahkan LLM untuk menangani tugas. Namun, pengguna masih perlu membuat lapisan orkestrasi mereka sendiri untuk menghubungkan dan mengelola alur kerja, karena StageHand sendiri tidak menawarkan orkestrasi bawaan.

Untuk menguji BrowserBase, saya menggunakan developer playground mereka, yang menyediakan konsol untuk menulis kode Playwright dan penulis prompt LLM untuk secara otomatis membuat skrip tersebut. Idenya adalah melakukan navigasi multi-langkah — masuk, membuat akun, membuat pesanan reseller. Namun, platform tersebut mengharapkan Anda untuk mengatur sendiri langkah-langkah tersebut. Dimulai dengan prompt yang sama yang diberikan kepada Claude, BrowserBase tersandung karena tidak dapat bernalar dalam mode multi-langkah. Jadi, saya melanjutkan dengan menyediakan prompt bahasa alami untuk setiap langkah dan mengamati apakah kode Playwright yang dihasilkan melakukan apa yang dimaksudkan. Pada tangkapan layar di bawah, Anda dapat melihat serangkaian prompt dan kode Playwright yang dihasilkan.

Dalam praktiknya, saya mengalami ketidakselarasan sesekali antara lingkungan browser Playground dan formulir HTML yang perlu diisi. Tombol ditampilkan dengan aneh, waktu tunggu diperpanjang, dan kolom formulir tidak dimuat persis seperti yang diharapkan. Meskipun ada gangguan ini, kode Playwright yang dihasilkan LLM berhasil masuk, membuat akun, dan mengisi sebagian formulir pesanan reseller. Namun, drag-and-drop untuk menambahkan item lagi-lagi menjadi kendala. Saya menghabiskan sekitar tujuh menit mengutak-atiknya sebelum menyerah. Jelas bahwa platform tersebut belum cocok untuk jenis otomatisasi seperti itu. Platform ini mungkin paling cocok untuk kasus penggunaan web scraping.

Langit

Skyvern adalah pendekatan headless yang lebih menyeluruh yang menambahkan orkestrasi secara default. Tidak seperti BrowserBase, yang mengharuskan pengguna untuk menentukan dan mengelola langkah-langkah secara manual, Skyvern mencoba menangani orkestrasi secara langsung. Di balik layar, ia beroperasi mirip dengan BrowserBase — seperti yang terlihat dalam kode sumber terbuka mereka — tetapi juga menambahkan agen web yang dapat mengatur dan menalar tentang langkah-langkah. Ini termasuk mode penglihatan opsional yang mengirimkan tangkapan layar ke LLM bersama komponen yang diekstrak dan xPath-nya untuk membantu dalam pengambilan keputusan.

Untuk mengatasi keterbatasan pembuatan langkah manual di BrowserBase, saya memutuskan untuk menguji Skyvern menggunakan layanan terkelolanya, dengan fokus khusus pada mode Workflow. Mode ini dirancang untuk proses multi-langkah, dan saya ingin mengevaluasi seberapa baik kinerjanya dengan alur kerja Salesforce kami. Sayangnya, pengujian tersebut menghabiskan lebih dari 15 langkah penalaran dan $1 kredit tertahan dalam proses autentikasi dua faktor (2FA). IP yang dihosting Skyvern ditandai, memicu 2FA, dan tidak ada cara untuk memberikan kode secara manual atau membagikan cookie untuk melewati situasi tersebut. Hal ini menyoroti tantangan autentikasi yang sedang berlangsung dalam pengaturan perusahaan dan menggarisbawahi mengapa perusahaan rintisan seperti Anon muncul untuk fokus hanya pada solusi autentikasi untuk agen AI.

Tim Skyvern memposisikan platform tersebut sebagai platform yang sesuai untuk tugas-tugas yang lebih sederhana dan lebih kecil, dengan otomatisasi formulir kontak sebagai kasus penggunaan utama yang didukung. Kasus penggunaan potensial lainnya (misalnya Pekerjaan, Faktur) masih tercantum sebagai "dalam pelatihan", yang menunjukkan bahwa platform tersebut dimulai dengan otomatisasi yang berfokus pada kasus penggunaan sederhana, bukan kebutuhan alur kerja perusahaan yang lebih rumit. Meskipun menjanjikan, jelas bahwa Skyvern lebih cocok untuk skenario yang tidak terlalu rumit pada tahap pengembangannya ini.

Kompromi

Browser tanpa kepala melewati tebakan tingkat piksel, yang sering kali menghasilkan lebih sedikit kesalahan dan eksekusi lebih cepat. Namun, begitu Anda menggunakan fitur lanjutan seperti drag-and-drop atau aplikasi satu halaman yang kompleks, Anda mungkin perlu kembali ke analisis tangkapan layar parsial atau kode khusus. Browser mungkin juga mengalami 2FA dan daftar hitam IP. Untuk aplikasi perusahaan multi-penyewa, autentikasi saja bisa jadi rumit, dan Anda mungkin masih memerlukan lapisan orkestrasi khusus.

Keterbatasan lainnya adalah bahwa platform ini bergantung pada pembuatan kode secara dinamis melalui LLM setiap kali alur kerja dijalankan. Karena LLM pada dasarnya bersifat nondeterministik, kode yang dihasilkan dapat bervariasi di setiap proses, sehingga sulit untuk mengaudit atau memverifikasi konsistensi. Ketidakpastian ini dapat menimbulkan masalah, terutama dalam alur kerja yang sensitif. Meskipun menyimpan kode yang dihasilkan dalam cache tampaknya menjadi rencana untuk beberapa platform, hal itu menimbulkan tantangan yang signifikan bagi LLM. Bahkan perubahan kecil dalam prompt atau pemrosesan batch selama inferensi dapat menghasilkan hasil yang sama sekali berbeda, sehingga mempersulit proses penyimpanan dalam cache.

Secara keseluruhan, penelusuran tanpa kepala bisa lebih murah dan lebih stabil daripada manipulasi GUI penuh, tetapi ini jauh dari perbaikan ajaib. Banyak solusi, seperti BrowserBase dan Skyvern, berfokus pada kasus penggunaan yang lebih sempit (misalnya, formulir, ekstraksi data) daripada menjadi "satu platform untuk mengotomatiskan semuanya."

Rekayasa Balik API Internal

Pendekatan ketiga adalah dengan mengabaikan halaman web sepenuhnya dengan mencegat panggilan jaringan yang terjadi saat Anda mengeklik. Jika Anda dapat menangkap permintaan yang dikirim browser, Anda dapat merekonstruksi panggilan tersebut dalam kode. Pada prinsipnya, hal ini menghindari langkah-langkah berbasis UI yang berantakan dan memastikan Anda menggunakan logika backend yang sama dengan yang digunakan aplikasi Anda. Tren ini tidak sepenuhnya baru, karena rekayasa balik API telah ada sejak lama. Namun, penambahan baru ini menggabungkan agen AI untuk bernalar tentang permintaan jaringan, yang membuat prosesnya lebih cerdas dan mudah beradaptasi.

Beberapa bulan lalu, sebuah produk bernama Integuru diluncurkan di Hackernews dan telah menarik perhatian karena pendekatan sumber terbuka dan metodologi barunya. Penasaran dengan potensinya, saya memutuskan untuk mengujinya, tertarik dengan pendekatan berbasis grafik yang menarik dan integrasi agen AI untuk menganalisis permintaan jaringan. Janji untuk memangkas waktu dan biaya otomatisasi secara drastis menjadikannya pilihan yang menarik untuk dijelajahi.

Repositori Integuru tergolong baru tetapi menjanjikan. Pada intinya, repositori ini merekam semua lalu lintas jaringan dan kuki di Chromium selama mengerjakan tugas. Repositori ini kemudian membuat representasi grafik dari permintaan, memetakan halaman mana yang memanggil titik akhir mana. Dengan menggunakan grafik ini, repositori ini melakukan traversal, meneruskannya ke LLM untuk menghasilkan kode bagi setiap node yang memutar ulang permintaan yang sama, menyuntikkan parameter dinamis Anda (seperti "Perusahaan Produksi Sepeda") sesuai kebutuhan dan menyusunnya berdasarkan dependensi. Pendekatan ini secara teoritis dapat menyederhanakan proses otomatisasi secara signifikan.

Namun, dalam praktiknya, hal itu tidak berjalan dengan baik untuk kasus penggunaan kami, sebagian besar karena keterbatasan jendela konteks. Alurnya mungkin terlalu panjang untuk ditangani secara efektif oleh LLM. Bahkan upaya untuk mempersingkat proses dengan menyematkan kuki login secara langsung dan memulai dari beranda tidak berhasil. Meskipun saya menduga kunci API OpenAI tingkat rendah saya berkontribusi terhadap masalah ini, jelas bahwa Integuru masih dalam tahap awal. Potensinya ada, tetapi produk tersebut memerlukan penyempurnaan lebih lanjut. Demo-nya (seperti mengunduh dokumen pajak dari Robinhood) bekerja paling baik pada kerangka kerja web modern dengan alur yang lebih sederhana. Salesforce, dengan ujung depannya yang rumit dan objek kustom yang rumit, menimbulkan kesalahan.

Meski demikian, metode ini belum menjadi solusi universal. Kebutuhan untuk merekam semua langkah membatasi fleksibilitasnya, dan metode ini condong ke pendekatan yang lebih statis dalam membuat kode untuk alur tertentu terlebih dahulu, yang mengingatkan kita pada alat RPA berbasis aturan yang populer satu dekade lalu. Hal ini menyoroti keterbatasan mendasar: meskipun penambahan penalaran AI pada permintaan jaringan menarik dan dapat membuka pintu untuk integrasi dengan sistem yang tidak memiliki API, metode ini masih lebih cocok untuk tugas yang lebih terkontrol atau berulang daripada alur kerja yang dinamis dan beragam di lingkungan perusahaan.

AgentForce: Solusi Asli Salesforce

Tidak ada pembahasan tentang otomatisasi berbasis AI di Salesforce yang akan lengkap tanpa menyebutkan AgentForce , taruhan besar Marc Benioff dalam membangun "agen" di dalam ekosistem Salesforce. Tidak seperti solusi lain yang kami uji di atas, yang berfokus pada pengembang dan bertujuan untuk mengotomatiskan alur kerja di berbagai sistem, AgentForce diposisikan sebagai solusi tertanam berkode rendah khusus untuk Salesforce. Solusi ini mengemas banyak komponen bersama-sama dan berfokus pada seluruh alur dalam platform Salesforce.

Idenya adalah untuk membuat agen yang sepenuhnya berada di Salesforce dan membangun kustomisasi Anda. Pengguna menentukan deskripsi umum agen, menetapkan topik, dan menautkan tindakan terkait yang merupakan alur yang telah dibuat sebelumnya yang ditentukan dalam kode atau melalui UI Salesforce. Izin, peran pengguna, dan instruksi kemudian disiapkan untuk memungkinkan agen berfungsi. Konsep ini secara teoritis memungkinkan bisnis untuk memanfaatkan data dan alur kerja Salesforce yang ada untuk mendorong otomatisasi tanpa pengodean yang ekstensif.

Saya ingin menguji AgentForce secara langsung dengan contoh pesanan reseller eBikes kami. Sayangnya, akses ke Einstein (fitur AI) diperlukan, yang tidak tersedia di akun developer gratis. Sebagai gantinya, saya menjelajahi taman bermain mereka selama 30 menit dengan aplikasi fiktif "Coral Beach Resort". Tugas pengujiannya adalah mengonfigurasi agen untuk mengotomatiskan pembuatan reservasi, sebuah proses yang agak mirip dengan pesanan reseller dalam skenario eBikes kami.

Penyiapannya cukup rumit, memerlukan beberapa langkah: menentukan izin, mengaktifkan topik, menghubungkan ke tindakan yang telah dibuat sebelumnya, memetakan bidang data, dan mengklarifikasi instruksi. Meskipun dipasarkan sebagai solusi low-code, menjadi jelas bahwa pengetahuan yang signifikan tentang seluk-beluk Salesforce diperlukan. Jika instans Salesforce perusahaan tidak memiliki bidang kustom yang terdokumentasi dengan baik dan alur tindakan yang telah dikonfigurasi sebelumnya, peningkatan awal bisa sangat substansial. Secara realistis, sebagian besar bisnis kemungkinan perlu mendatangkan integrator sistem atau konsultan untuk sepenuhnya menerapkan dan mengoptimalkan agen ini.

Sifat AgentForce yang berbasis aturan juga menonjol. Pengguna harus memetakan dengan cermat kolom mana yang diisi atau dilewati agar otomatisasi dapat bekerja secara akurat, sehingga lebih praktis daripada beberapa platform yang digerakkan oleh AI. Meskipun pendekatan ini memastikan ketepatan, pendekatan ini memperkuat ketergantungan pada keahlian Salesforce yang kuat dan infrastruktur yang ada.

Meskipun AgentForce membatasi dirinya pada ekosistem Salesforce, hal ini memiliki kelebihan dan kekurangan. Di satu sisi, ini adalah solusi paket yang menyatukan autentikasi, izin pengguna, definisi alat, dan logika orkestrasi dalam satu platform. Di sisi lain, banyak alur kerja perusahaan mencakup beberapa sistem, dan sifat AgentForce yang terisolasi membatasi penerapannya untuk kebutuhan otomatisasi yang lebih luas. Marc Benioff telah menyatakan bahwa ratusan pelanggan telah menandatangani kesepakatan untuk menggunakan AgentForce, jadi evolusinya akan layak dipantau.

Jadi… Apakah Kita Sudah Sampai?

Dari percobaan ini, jelas bahwa solusi agen AI saat ini dapat melakukan pekerjaan yang layak dalam penalaran tentang tugas multi-langkah dan menyusun rencana. Tantangan sebenarnya adalah eksekusi dalam lingkungan dunia nyata yang berantakan dengan pengetahuan suku tentang bagaimana sistem ini benar-benar berperilaku. UI grafis dibuat untuk interaksi manusia, dan logika khusus setiap perusahaan seperti lubang hitam mini yang rumit. Bahkan jika Anda melewatkan GUI untuk pendekatan tanpa kepala atau merekayasa balik API backend, Anda masih menghadapi kasus tepi, rintangan autentikasi, batas kecepatan, atau alur kerja dinamis yang membuang LLM terbaik.

Tantangan yang tersisa sebagian besar adalah masalah rekayasa: membangun perangkat yang tangguh, mengintegrasikan secara mendalam dengan sistem perusahaan, membangun pembatas, dan menciptakan kerangka kerja pemantauan dan orkestrasi yang andal. Semua ini dapat dipecahkan dengan upaya dan spesialisasi yang berdedikasi. LLM saat ini telah menunjukkan kemampuan penalaran yang jauh melampaui apa yang tersedia bahkan setahun yang lalu, dan biayanya turun dengan cepat. Fokus sekarang harus beralih ke pembangunan infrastruktur dan proses yang dibutuhkan untuk menerapkan kemampuan ini secara efektif.

Namun, kesulitan-kesulitan ini tidak boleh menutupi kemajuan yang terjadi. Kita sudah melihat otomatisasi AI yang terspesialisasi dan terfokus secara vertikal (misalnya agen dukungan pelanggan atau SDR) yang dapat memberikan akurasi tinggi dalam domain yang terkendali. Seiring dengan semakin matangnya masing-masing otomatisasi sekali pakai ini, kita mungkin akan melihatnya dirangkai menjadi alur kerja yang lebih luas. Pada akhirnya, itulah cara kita memecahkan otomatisasi menyeluruh di perusahaan-perusahaan besar: dengan menggabungkan beberapa agen khusus daripada mengharapkan satu agen serba guna untuk melakukan semuanya. Untuk saat ini, ROI dari membangun agen dari awal mungkin tidak akan menguntungkan untuk semua tugas kecuali tugas dengan volume tertinggi.

Spesialisasi dan Jalan ke Depan

Salah satu pelajaran dari pengujian ini adalah pentingnya spesialisasi. Mencapai keandalan yang hampir sempurna dalam satu domain (misalnya, membuat faktur di NetSuite) memerlukan penyempurnaan yang signifikan. Perusahaan rintisan atau tim internal yang berfokus pada satu alur kerja khusus dapat memberikan pengalaman yang lebih baik daripada solusi umum yang luas. Kita sudah melihat gelombang "agen vertikal" yang menangani tugas-tugas yang ditargetkan dalam keuangan, logistik, SDM, atau rantai pasokan. Setiap agen akan terintegrasi secara mendalam, mungkin menggabungkan otomatisasi UI jika diperlukan dengan panggilan API langsung jika memungkinkan, ditambah logika fallback dan pembatas khusus domain.

Pertanyaan besarnya tetap: Apakah 2025 benar-benar akan menjadi tahun ketika agen-agen ini menjadi arus utama, atau apakah kita melihat landasan pacu yang lebih panjang? Teknologi ini bergerak cepat, dan optimisme berlimpah. Namun, seperti halnya insinyur perangkat lunak tidak menghilang ketika pembuatan kode menjadi lebih baik, kita mungkin tidak akan melihat otomatisasi perusahaan "tanpa sentuhan" untuk semua proses. Sebaliknya, kita akan melihat peningkatan berulang dalam kantong-kantong khusus, yang pada akhirnya menyatukannya sebagai mosaik otomatisasi parsial.

Kesimpulan

Konsep agen AI otonom tidak dapat disangkal menarik, terutama dalam lingkungan perusahaan yang banyak melakukan tugas berulang. Manfaat potensial — menghemat waktu, mengurangi kesalahan, dan memungkinkan karyawan untuk fokus pada pekerjaan yang lebih kreatif dan strategis — sangat besar. Namun, meskipun kemampuan dasar agen AI kuat, jalur menuju adopsi yang luas bergantung pada mengatasi tantangan teknik selain memajukan penelitian yang mendasarinya.

Membangun infrastruktur yang tepat adalah kuncinya: perkakas yang tangguh, integrasi yang andal, dan solusi khusus domain dengan pembatas dan lapisan orkestrasi yang terdefinisi dengan baik. Kompleksitas sistem perusahaan di dunia nyata memerlukan solusi khusus, dan di sinilah agen vertikal dapat unggul. Berkonsentrasi pada alur kerja yang sempit dan terdefinisi dengan baik memungkinkan tim untuk menyempurnakan solusi mereka hingga tingkat akurasi dan keandalan yang tinggi, mengatasi tantangan unik di setiap domain. Seiring berjalannya waktu, agen khusus ini dapat saling terhubung, menciptakan jaringan otomatisasi yang lebih luas.

Tahun 2025 mungkin akan membawa kemajuan yang mengesankan dan semakin banyaknya program percontohan. Daripada dunia yang berjalan dengan autopilot, kita cenderung akan melihat otomatisasi yang terarah dan sangat efektif untuk mengatasi masalah tertentu. Perjalanan menuju otomatisasi perusahaan secara menyeluruh akan bersifat iteratif, didorong oleh spesialisasi dan kolaborasi. Momentum sedang dibangun, dan penyelesaian tantangan teknik ini akan membuka jalan bagi gelombang inovasi perusahaan berikutnya.

(Kredit gambar fitur untuk DALL-E)