a16z：Ketika UI tidak lagi menjadi produk, apa yang tersisa dari keunggulan perangkat lunak?

Editor’s note: Selama dua puluh tahun terakhir, parit perlindungan SaaS sebagian besar dibangun di atas UI. Dashboard, bidang, alur persetujuan, dan kebiasaan pengguna, bukan hanya antarmuka operasi, tetapi juga membentuk cara kerja organisasi dan tatanan data. Ketika AI dapat langsung membaca data, memanggil alat, dan menjalankan proses, ketahanan yang terbentuk dari memori otot manusia mulai melemah, UI tidak lagi harus menjadi antarmuka utama perangkat lunak perusahaan.

Ini tidak berarti sistem pencatatan kehilangan nilainya, melainkan pertahanan mereka sedang beralih: dari UI dan kebiasaan penggunaan, ke model data, sistem izin, tanggung jawab kepatuhan, logika bisnis, siklus eksekusi, dan jaringan kolaborasi multi pihak. Di masa depan, perangkat lunak yang benar-benar memiliki hambatan kompetitif mungkin tidak lagi hanya basis data yang mencatat pekerjaan manusia, tetapi sistem aksi yang mampu menangkap konteks, memulai tugas, mengoordinasikan agen cerdas, dan secara terus-menerus menghasilkan data baru selama proses eksekusi.

Ketika perangkat lunak menuju headless (tanpa antarmuka), masalah inti perangkat lunak perusahaan juga berubah: nilai tidak lagi hanya tentang siapa yang memiliki data, tetapi siapa yang dapat mengatur tindakan di sekitar data.

Berikut adalah teks asli:

Bulan lalu, Salesforce mengumumkan akan membuka API dan meluncurkan produk headless (tanpa antarmuka). Pada dasarnya, ini berarti Salesforce sedang bertaruh: di era Agen, nilai inti mereka tidak lagi terutama berasal dari UI, melainkan dari lapisan data. Ini adalah repositioning yang cukup cerdas.

Namun juga perlu dicatat, dari segi teknologi, peluncuran ini tampaknya tidak membawa banyak perubahan substantif. API yang dibungkus ulang oleh Salesforce sebagai “produk headless” sebenarnya sudah ada selama bertahun-tahun. Dengan kata lain, ini lebih mirip peluncuran pemasaran khas Salesforce.

Inti dari produk baru ini adalah, Agen dapat mengakses langsung data dalam sistem pencatatan tanpa harus berinteraksi melalui UI yang dirancang untuk manusia. Fungsi UI tradisional adalah membantu pengguna manusia melacak proses, mengelola tugas, dan mendorong alur kerja; tetapi setelah kehadiran Agen, kebutuhan akan lapisan antarmuka ini mulai berkurang.

Hal yang benar-benar layak didiskusikan dari peluncuran ini bukanlah apa produk baru yang dirilis Salesforce, melainkan pertanyaan yang lebih mendasar: jika UI dihilangkan dan hanya database dasar yang dibuka, apa yang tersisa dari sistem pencatatan? Apa bedanya dengan database Postgres, skema data yang dirancang baik, dan sekumpulan API?

Lebih jauh lagi, apakah faktor-faktor klasik yang dulu membuat sistem pencatatan memiliki pertahanan jangka panjang masih relevan? Atau sudah muncul standar kompetisi baru?

Di era SaaS, alasan mengapa sistem pencatatan memiliki parit perlindungan adalah karena pengguna manusia telah lama hidup dalam antarmuka mereka. Antarmuka memuat kebiasaan operasi, proses organisasi, dan akumulasi data, yang semuanya menciptakan biaya migrasi yang tinggi. Tetapi di era Agen, keunggulan ini mulai berkurang. Lapisan yang benar-benar memiliki pertahanan, sedang turun ke model data, sistem izin, logika alur kerja, dan kemampuan kepatuhan; sekaligus naik ke efek jaringan, kemampuan menghasilkan data eksklusif, dan kemampuan eksekusi di dunia nyata.

Ketika perangkat lunak menuju headless, ke mana parit perlindungan akan berpindah?

UI dulu adalah inti produk itu sendiri

Yang disebut Sistem Catatan (System of Record, SoR), merujuk pada sumber fakta otoritatif dari data bisnis tertentu. Ini adalah tempat di mana versi resmi dari hubungan pelanggan, catatan karyawan, atau transaksi keuangan berada, dan juga merupakan sistem inti yang dibaca dan ditulis oleh alat lain. CRM adalah sistem pencatatan data terkait pendapatan, HRIS adalah sistem pencatatan data terkait SDM, dan ERP adalah sistem pencatatan data terkait dana dan keuangan.

Kekuatan sistem ini bukan hanya karena mereka menyimpan data, tetapi karena mereka akhirnya menjadi “versi realitas” yang digunakan bersama oleh seluruh organisasi.

Selama dua puluh tahun terakhir, yang dijual Salesforce kepada pelanggan sebenarnya adalah cara membantu manajer penjualan mengelola tim mereka. Dashboard, pandangan pipeline penjualan, alat prediksi, aliran informasi dinamis, adalah produk yang benar-benar dibeli. Model bisnisnya didasarkan pada penjualan kursi pengguna, yang secara esensial memberi akses ke fungsi-fungsi tersebut. Basis data dasar memang penting, tetapi lebih seperti infrastruktur tersembunyi dalam pengalaman produk.

Dengan kata lain, yang benar-benar mendorong ketergantungan pengguna adalah UI.

UI membatasi standar data, membentuk bahasa bersama: prospek, peluang, akun pelanggan. Ia memungkinkan ribuan tenaga penjualan terus memasukkan data yang mungkin awalnya mereka enggan masukkan. Dulu, UI adalah mekanisme untuk menjaga konsistensi dan ketersediaan data. Salesforce sangat melekat di hati pengguna, sehingga banyak manajer penjualan tetap membawa Salesforce ke perusahaan baru setelah pindah, bukan karena antarmukanya yang luar biasa, tetapi karena sudah menjadi bagian dari memori otot mereka.

Namun Agen mulai mengubah pola ini. Mereka tidak lagi perlu berinteraksi melalui UI, melainkan bisa langsung membaca dan menulis data dasar. Ini memunculkan berbagai alat dan solusi pengganti yang melewati antarmuka tradisional. Salesforce bukan satu-satunya contoh: baru-baru ini kita juga membahas ekosistem yang berkembang di sekitar SAP yang lebih cocok untuk panggilan AI.

Sementara itu, agen yang mampu mengoperasikan komputer juga akan membuat faktor-faktor manusia seperti preferensi, pelatihan, dan konteks yang belum terdokumentasi, menjadi kurang penting seiring waktu. Dengan kata lain, syarat agar menjadi sistem pencatatan yang tahan lama sedang berubah.

Kriteria penilaian masa lalu

Sebelum membahas apa yang akan berubah di era Agen, perlu kembali ke satu pertanyaan yang lebih tepat: apa sebenarnya yang membuat sistem pencatatan memiliki ketergantungan?

Beberapa faktor utama berkaitan dengan bagaimana manusia menggunakan perangkat lunak dan preferensi mereka sendiri. Sulitnya mengganti sistem ini sebagian besar bergantung pada UI, kebiasaan penggunaan, alur kerja manusia, dan aturan yang sudah tertanam dalam proses organisasi.

Pertama, seberapa sering sistem ini diakses?

CRM digunakan setiap hari oleh tim GTM dan departemen terkait lainnya. Penggunaan yang tinggi ini menjadikannya infrastruktur kunci. Sedangkan lapisan manusia yang dibangun di atasnya—misalnya rapat tim, kebiasaan operasional, ritme manajemen—seringkali merupakan bagian yang paling sulit dipindahkan. Alasannya, mereka bahkan sering tidak disadari sebagai sesuatu yang perlu dipindahkan.

Kedua, apakah sistem ini hanya untuk menulis data, atau juga untuk membaca dan menulis?

Sistem pencatatan yang benar-benar memiliki ketergantungan biasanya adalah sistem dua arah: membaca dan menulis. Contohnya CRM, bukan hanya sistem penyimpanan arsip, tetapi juga yang terus-menerus dibaca. Setiap panggilan telepon, pembaruan tahap, pembuatan tugas, semuanya diinput oleh pengguna, dan pengguna biasanya peduli bagaimana data ini digunakan selanjutnya.

Arus data dua arah ini berarti, pengganti harus mampu menampung data operasional secara real-time, bukan hanya mengekspor data historis. Selama migrasi, hampir tidak ada titik aman mutlak untuk beralih. Setelah perusahaan selesai migrasi, mereka cenderung tetap bertahan dalam ekosistem penyedia awal dalam jangka panjang.

Sebaliknya, sistem pelacakan kandidat (ATS) lebih dekat ke sistem “hanya untuk menulis”. Setelah kandidat diterima atau ditolak, alasan perusahaan menggunakan data tersebut menjadi terbatas.

Ketiga, berapa banyak SOP yang belum terdokumentasi?

Konteks bisnis yang benar-benar penting sering kali tidak tertulis di wiki mana pun, melainkan tersimpan dalam aturan alur kerja yang dibangun oleh administrator dan integrator selama bertahun-tahun.

Misalnya dalam sistem penjualan, konteks yang tidak terdokumentasi ini bisa termasuk: transaksi perusahaan di atas 100.000 dolar membutuhkan persetujuan VP; transaksi di EMEA harus melalui proses privasi; diskon untuk pelanggan strategis hanya bisa dilalui tanpa persetujuan keuangan di akhir kuartal.

Konteks ini menentukan apakah sebuah tugas bisa diproses tepat waktu atau tidak, dan apakah bisa diselesaikan tanpa melanggar proses utama. Migrasi sistem berarti harus membongkar setiap aturan otomatisasi ini; jika tidak, perusahaan bisa kehilangan sebagian memori organisasinya.

Keempat, seberapa kompleks ketergantungan internal dan eksternal?

Pertanyaan utama adalah: berapa banyak sistem internal, proses tim, atau pihak eksternal yang bergantung pada sistem pencatatan ini?

Keterhubungan internal mengacu pada berapa banyak perangkat lunak atau alur kerja hilir yang bergantung padanya. Keterhubungan eksternal mengacu pada apakah auditor, akuntan, regulator, dan pihak luar lain perlu mengakses data secara langsung. ERP adalah contoh klasik.

Baik keterhubungan internal maupun eksternal, semakin tinggi, semakin rumit hubungan yang harus dibongkar dan dibangun kembali saat migrasi.

Kelima, dari sudut pandang kepatuhan, seberapa penting data ini?

Intinya sederhana: apakah sistem ini merupakan sumber fakta yang penting secara hukum dan patuh?

Misalnya, sistem penggajian, ERP, data SDM yang terkait kepatuhan harus menyediakan sumber fakta yang sah secara hukum dan memiliki kontrol akses yang ketat. Migrasi ke sistem baru biasanya melibatkan auditor dan regulator secara langsung. Ini membuat ketergantungan mereka jauh lebih kuat.

Data penjualan dan alat dukungan pelanggan seperti Zendesk berada di ujung lain spektrum. Perusahaan tentu peduli terhadap kontinuitas dan konteks, tetapi jika data dipindahkan atau akses diberikan, biasanya tidak langsung menimbulkan risiko regulasi.

Tidak semua sistem pencatatan memiliki biaya switching yang sama. Membandingkan CRM dan ATS dalam satu dimensi menunjukkan perbedaan yang sangat besar.

ATS adalah alat alur kerja yang melayani proses terbatas, seperti perekrutan. Setelah kandidat diterima atau ditolak, data terkait biasanya menjadi data sekali pakai. Ruang integrasinya lebih sempit, dan penggunaannya lebih kecil dan terfokus.

ERP adalah ekstrem lain. Buku besar itu sendiri adalah jejak audit, dan akuntan, auditor, serta regulator akan menjadi pihak yang langsung terlibat dalam proses migrasi.

Mengganti ATS memang menyakitkan, tetapi masih bisa ditanggung. Mengganti CRM seperti menjalani operasi jantung terbuka. Mengganti ERP ibarat menjalani operasi jantung terbuka saat pasien sedang berlari marathon.

Secara tradisional, sistem pencatatan tidak benar-benar memanfaatkan data eksklusif, efek jaringan, dan sumber daya lain sebagai parit perlindungan; biasanya, alur kerja sendiri sudah cukup membentuk hambatan. Dalam beberapa hal, menggabungkan alat dan jaringan lebih banyak dilakukan dalam bisnis konsumsi; SoR di masa lalu tidak mengikuti jalur ini.

Data eksklusif. Banyak sistem pencatatan yang menyimpan data pelanggan dalam jumlah besar, tetapi tidak benar-benar mengembangkan penggunaan mendalam dari data tersebut, dan dalam banyak kasus, klausul kontrak melarangnya. Jadi, meskipun CRM memiliki kumpulan data yang kaya dan secara teori bisa menggabungkan data dari berbagai pelanggan untuk mendapatkan wawasan lintas pelanggan, mereka belum pernah melakukannya secara bermakna. Tentu saja, produk seperti Einstein dari Salesforce pernah melakukan beberapa percobaan.

Efek jaringan. Untuk sistem pencatatan, hambatan perlindungan yang ideal seharusnya adalah efek jaringan: misalnya, CRM akan menjadi lebih berharga karena penjual dapat menemukan pembeli di dalamnya. Tetapi seperti data, efek jaringan dari sistem pencatatan secara historis sangat lemah, bahkan hampir tidak ada.

Jika UI hilang, setelah kedatangan Agen, apa yang tersisa dari perangkat lunak?

Agen tidak memerlukan browser. Mereka membutuhkan API, konteks, instruksi, dan kemampuan untuk melakukan tindakan. Ada dua hal yang memungkinkan semuanya ini terjadi secara skala: pertama, LLM sudah memiliki kemampuan penalaran yang cukup kuat, sehingga Agen sekarang dapat membaca konteks, merencanakan, memilih alat, melakukan tindakan, dan mereview hasilnya, tanpa perlu intervensi manusia dalam banyak tugas; kedua, standar MCP telah menstandardisasi cara akses alat, menyediakan antarmuka umum untuk panggilan kemampuan eksternal oleh Agen.

Sebuah Agen yang memiliki akses MCP dapat menyelesaikan operasi yang dulu dilakukan manusia di platform dalam waktu milidetik secara massal, tanpa perlu browser. Dalam konteks yang cukup lengkap, Agen yang mampu mengoperasikan komputer bahkan bisa langsung menggunakan antarmuka perangkat lunak yang ada, tanpa harus API.

Secara sederhana, pembeli perangkat lunak saat ini memiliki tiga jalur:

Pertama, terus gunakan sistem yang ada, dan tambahkan Agen di atasnya.
Dengan menggunakan CLI dan API dari sistem yang ada, mereka bisa memakai produk Agen asli dari vendor, seperti Salesforce Agentforce, SAP Joule, atau membangun Agen sendiri. Tentu, di sini diasumsikan API lengkap dan dapat digunakan, dan mengabaikan kompleksitas “headless” yang mungkin muncul dalam operasional nyata.

Kedua, bangun sistem pencatatan sendiri dari nol.
Perusahaan bisa membangun model data, logika operasional, sistem izin, pelacakan audit, integrasi sistem, dan tumpukan Agen mereka sendiri. Jalur ini kemungkinan besar akan memanfaatkan alat pengembangan Agen pihak ketiga dan alat basis data.

Ketiga, beli pengganti berbasis AI asli.
Perusahaan juga bisa membeli produk generasi baru yang dirancang sejak awal untuk era Agen. Produk ini menekankan keterbacaan mesin, mengatur Agen sebagai kemampuan utama, bukan menambahkan fitur AI secara patch di sistem lama. Produk ini juga bisa bersifat headless.

Lalu, mana yang akan dipertahankan dari standar penilaian lama?

Faktor yang didorong oleh perilaku dan preferensi manusia akan berangsur melemah, seperti frekuensi akses, atribut baca-tulis dua arah, dan indikator terkait memori otot manusia. Agen mungkin akan melemahkan nilai “memori otot” sebagai hambatan, tetapi mereka tidak akan menghapus hambatan logika operasional dan konteks bisnis. Dalam arti tertentu, mereka malah akan membuat logika ini semakin penting, karena Agen harus menjalankan tugas secara aman dan harus bergantung pada aturan, izin, dan definisi proses yang jelas.

SOP yang belum terdokumentasi tetap penting dalam jangka pendek.
Logika sistem yang tersimpan dalam aturan alur kerja organisasi adalah hal yang dibutuhkan Agen untuk menjalankan tugas dengan benar. Ini juga bagian yang paling sulit untuk dibangun kembali. Saat ini, mereka belum bisa diekspor secara bersih, terutama jika beberapa proses masih melibatkan manusia. Namun, menangkap konteks menjadi semakin mudah; seiring Agen menggantikan lebih banyak pekerjaan manusia, faktor ini akan semakin berkurang pentingnya.

Keterhubungan tetap sulit diurai dan akan semakin mendalam.
Makna keterhubungan sedang berubah. Tidak lagi hanya untuk mendukung kerja manusia, tetapi juga untuk menjaga koneksi antara fungsi dan perangkat lunak yang selama ini terpisah.

Sebuah CRM Agent perlu menghubungkan data dan konteks dari berbagai bagian seperti penjualan, penagihan, dan keberhasilan pelanggan. Jika platform Anda menjadi titik transaksi antara berbagai organisasi eksternal, seperti pembeli, penjual, dan mitra, maka ketergantungan akan semakin dalam.

Ketika vendor lama menambahkan Agen, mungkin sulit untuk memastikan kolaborasi yang lancar antara objek dan logika dasar dari berbagai perangkat lunak; jika perusahaan hanya mengandalkan basis data dan sekumpulan Agen buatan sendiri, mereka juga akan menghadapi masalah serupa.

Data yang penting dari sudut pandang kepatuhan tetap relevan.
Data yang melibatkan regulator, risiko regulasi, atau risiko hukum, tetap membutuhkan sumber fakta yang tunggal dan terpercaya. Jika pelanggan sudah percaya pada produk yang ada, mereka cenderung lebih enggan beralih.

Contohnya data penggajian dan akuntansi, Agen mungkin memang perlu mengakses data ini, tetapi perusahaan biasanya tidak akan membangun dan memelihara sistem ini secara internal dalam jangka panjang.

Dalam dunia yang sepenuhnya didominasi Agen, salah satu masalah paling sulit adalah: agen mana yang diberi wewenang melakukan apa? Mereka mewakili siapa? Bagaimana tindakan ini diaudit? Jika sebuah sistem pencatatan bisa menjadi lapisan identitas dan izin antar Agen, maka sistem ini akan mendapatkan peran struktural yang benar-benar sulit digantikan. Hambatan di sini bukan hanya karena data yang dimiliki, tetapi karena arsitektur kepercayaan yang dijalankan.

Ke depan, bagi perusahaan startup berbasis AI asli, satu set faktor baru akan menjadi semakin penting dan menentukan kemampuan mereka membangun pertahanan.

Pertama, seberapa sulit membangun ulang sistem pencatatan ini?

Data akan menjadi lebih penting di beberapa tingkat.

Pertama, dalam jangka pendek, kunci adalah seberapa mudah mengekstrak dan membangun ulang data dasar dari sistem pencatatan. AI membuat proses ini menjadi lebih mudah, dengan berbagai alat yang membantu migrasi dan rekonstruksi.

Dalam jangka pendek, vendor yang ada bisa dan kemungkinan akan membuat proses ini lebih sulit: mereka bisa membatasi API, membuatnya tidak lengkap, atau secara ekonomi tidak menguntungkan, bahkan tidak menyediakan API sama sekali. Tetapi seiring kemajuan alat ekstraksi, terutama kemampuan Agen yang mampu mengoperasikan komputer, rekonstruksi data akan menjadi semakin mudah.

Selain itu, perusahaan baru juga mulai membangun data yang lebih kaya dari email, panggilan, suara Agen, dan dokumen internal. AI menurunkan biaya rekonstruksi 80% dari sistem pencatatan. Yang membedakan antara akses yang berguna dan pengganti yang benar-benar efektif adalah 20% sisanya: situasi luar biasa, proses persetujuan, persyaratan kepatuhan, dan alur kerja di skenario tepi.

Kedua, apakah mereka memiliki data eksklusif yang benar-benar bermakna?

Kedua, data itu sendiri akan menjadi lebih berharga.

Data yang benar-benar memiliki pertahanan bukanlah data yang diimpor, tetapi data yang secara unik dihasilkan oleh produk Anda. Kita sering menyebutnya “taman data eksklusif”: data ini harus bersifat eksklusif, diatur oleh regulasi, atau membutuhkan pembaruan terus-menerus. Penyedia perangkat lunak yang menginvestasikan banyak sumber daya untuk mengumpulkan data otoritatif dan lengkap akan memiliki keunggulan yang jelas dibandingkan pesaing yang bersifat umum atau kekurangan data tersebut.

Data juga memiliki arah penting lainnya: apakah bergantung pada tindakan yang dihasilkan dari dalam produk?

Perusahaan terbaik tidak hanya menyimpan data yang diinput dari luar. Mereka akan terus menghasilkan jejak data baru karena mereka berada dalam proses, seperti perilaku yang diamati, tingkat respons, pola waktu, hasil proses, tolok ukur industri, pola anomali, dan jejak eksekusi Agen.

Intinya: data saat ini adalah konteks.

Ketiga, apakah mereka menguasai lapisan tindakan?

Di dunia lama, menyimpan catatan saja sudah cukup. Tetapi di dunia baru, Agen akan langsung mengambil tindakan, dan ketahanan bisa beralih ke produk yang mampu membentuk siklus tertutup: dari tindakan, merekam hasil, hingga menggunakan umpan balik untuk mengoptimalkan keputusan di masa depan.

Untuk ERP, ini bisa termasuk menyetujui pengeluaran, memicu pembayaran gaji, memverifikasi faktur, mengirim pemberitahuan, dan lain-lain. Produk yang mampu menutup siklus ini lebih tahan terhadap gangguan karena mereka terintegrasi dalam proses eksekusi, bukan hanya pengamatan. Mereka akan menghasilkan data unik, terus membaik seiring penggunaan, dan lebih sulit digantikan karena menghilangkan bagian penting dari alur kerja.

Tentu saja, seiring akumulasi konteks dan penanganan skenario tepi yang lebih baik, nilai ini akan semakin meningkat.

Keempat, apakah mereka melibatkan eksekusi di dunia nyata?

Beberapa model bisnis terkait langsung dengan operasi dunia nyata, dan bagian ini tidak akan sepenuhnya otomatis. Contoh paling jelas adalah perusahaan yang memiliki jaringan operasional, seperti DoorDash. Mereka secara historis bukan bagian dari sistem pencatatan, tetapi di sini sangat relevan.

Secara lebih luas, perusahaan yang mampu memperluas siklus perangkat lunak ke layanan, pengiriman, logistik, operasi lapangan, atau pembayaran memiliki perlindungan berbeda dari SaaS murni. Mereka tidak hanya menyimpan catatan, tetapi juga mengirimkan personel, memindahkan barang, atau menyelesaikan layanan tertentu.

Bagi pengusaha, ini membuka peluang di pasar seperti ini: perangkat lunak semakin mampu membuat keputusan, Agen semakin mampu mengoordinasikan proses, tetapi tahap terakhir tetap membutuhkan eksekusi dunia nyata. Misalnya, perangkat lunak vertikal yang terkait dengan layanan lapangan adalah arah yang khas.

Kelima, apakah ada efek jaringan?

Secara historis, sebagian besar sistem pencatatan memiliki efek jaringan yang lemah karena mereka terutama perangkat lunak internal. Tetapi di era Agen, jika sebuah sistem mengintegrasikan alur kerja multi pihak, efek jaringan bisa menjadi jauh lebih penting.

Jika sebuah sistem bertanggung jawab untuk mengatur interaksi berulang antara banyak pihak, seperti pembeli dan penjual, pemberi kerja dan karyawan, perusahaan dan auditor, vendor dan pelanggan, atau pihak pembayaran dan layanan, maka setiap penambahan partisipan dapat meningkatkan nilai jaringan bagi partisipan berikutnya.

Salah satu caranya adalah berbagi alur kerja kolaboratif: produk menjadi tempat transaksi, pertukaran konteks, dan penanganan anomali antara kedua belah pihak.

Cara lain adalah berbasis standar dan kecerdasan: sistem dapat menampilkan norma industri, situasi abnormal, dan saran tindakan berdasarkan pola yang diamati di jaringan, yang memperkuat nilai data sebelumnya.

Ketiga, adalah kepercayaan dan standarisasi: jika lawan transaksi mulai bergantung pada satu set proses yang sama untuk persetujuan, transfer, kepatuhan, atau pembayaran, maka produk ini tidak lagi sekadar basis data, tetapi infrastruktur kolaborasi pasar itu sendiri, dan akan lebih sulit digantikan.

Keenam, seberapa kuat kemampuan teknologi pembeli?

Di dunia di mana siapa pun secara teori bisa membangun Agen sendiri, kemampuan membangun dan memelihara basis data, alur kerja, dan tumpukan Agen secara internal sangat bervariasi. Terutama di industri vertikal dan di kalangan pembeli yang sebelumnya tidak memiliki sumber daya rekayasa internal yang kuat, kemungkinan mereka membangun dan mengelola basis data, logika, dan sistem Agen sendiri tetap rendah.

Biaya juga menjadi faktor penting. Secara teori, DIY bisa mengurangi biaya lisensi perangkat lunak, tetapi biasanya memindahkan biaya ke implementasi, pemeliharaan, dan kompleksitas internal.

Ini berarti, di kategori dengan operasi kompleks tetapi sumber daya teknologi terbatas, masih ada peluang nyata. Misalnya, manufaktur, backend konstruksi, proses industri, alur kerja layanan lapangan, dan bidang akuntansi.

Ada juga faktor lain yang sama pentingnya dan akan menjadi standar dasar perangkat lunak secara bertahap.

Misalnya, ontologi perlu mengalami perubahan. Banyak gagasan “membangun basis data sendiri” meremehkan nilai dari model objek itu sendiri. Perangkat lunak lama dirancang untuk dashboard, laporan, dan pengguna manusia, dan mereka menangkap objek dalam alur kerja seperti peluang, tiket, dan kandidat.

Namun, schema di era Agen perlu menangkap penalaran, tindakan, pelacakan status, penanganan anomali, penugasan tugas, dan kolaborasi lintas sistem. Objek asli mungkin bukan lagi peluang, tiket, dan kandidat, tetapi tugas, niat, thread, strategi, atau hasil.

Begitu juga, sistem izin perlu diperbarui. Mereka tidak lagi hanya mengelola pengguna manusia, tetapi juga Agen. Ini termasuk: siapa yang bisa melakukan apa, melalui Agen mana, di bawah kebijakan apa, membutuhkan persetujuan apa, meninggalkan jejak audit apa, dan bagaimana melakukan rollback serta penanganan anomali.

Tentu saja, semua ini tidak lepas dari biaya: berapa biaya membangun dan memelihara Agen dan basis data, berapa biaya akses API. Ini kembali ke pertanyaan utama: seberapa sulit rekonstruksi data, berapa banyak ketergantungan, dan seberapa dalam sistem terintegrasi.

Lalu, apa kesimpulannya?

Seiring dengan vendor perangkat lunak yang beralih ke headless, mereka sebenarnya sedang membuat taruhan implisit: lapisan data akan tetap menjadi sumber nilai utama. Dalam beberapa kategori, terutama layanan keuangan yang sangat diatur, taruhan ini mungkin masih berlaku untuk beberapa waktu, dan proses headless mungkin berjalan lebih lambat.

Namun bagi pengembang perangkat lunak startup, saat vendor besar mulai menghilangkan antarmuka, cara bersaing dan membangun perangkat lunak yang memiliki pertahanan jangka panjang sedang berubah.

Sistem pencatatan generasi berikutnya sudah mulai menunjukkan bentuk berbeda: mereka tidak lagi hanya gudang data untuk mencatat pekerjaan manusia, tetapi lebih bersifat Agen—mampu menangkap konteks, secara aktif memulai pekerjaan, dan merekam jejak data selama proses eksekusi.

Lebih jauh lagi, perusahaan paling menarik akan memperluas ke lapisan eksekusi dunia nyata: mereka akan mengoordinasikan pekerja lapangan, penyedia logistik, tim layanan, dan aset fisik, atau menjadi lapisan tengah kolaborasi multi pihak.

Perusahaan-perusahaan ini akan memadukan berbagai model bisnis dunia lama. Dan inti dari sistem pencatatan tradisional, yaitu data, akan secara bertahap mundur ke latar belakang, menjadi fondasi yang menopang seluruh sistem operasional.

[Link artikel asli]

Klik untuk mengetahui posisi Low-Carbon BlockBeats dalam perekrutan

Selamat bergabung dengan komunitas resmi Low-Carbon BlockBeats:

Telegram Langganan: https://t.me/theblockbeats

Telegram Grup Diskusi: https://t.me/BlockBeats_App

Akun resmi Twitter: https://twitter.com/BlockBeatsAsia