Apakah software sedang menuju headless?

• Dengan Salesforce meluncurkan produk headless dan bertaruh bahwa pusat nilai ada pada lapisan data, bukan UI, muncul pertanyaan tentang di mana daya tahan SaaS di era agen masih tersisa
• Di era SaaS, parit pertahanan system of record dibentuk oleh kebiasaan pengguna yang terbentuk lewat UI, tetapi keunggulan ini melemah dalam struktur di mana agen membaca dan menulis langsung ke DB
• Daya tahan kini bergeser ke bawah menuju model data, perizinan, logika workflow, compliance, dan ke atas menuju jaringan, penciptaan data proprietari, kemampuan eksekusi di dunia nyata
• System of record AI-native generasi berikutnya memerlukan standar baru: model data yang ramah agen, pengelolaan izin per agen, penutupan loop eksekusi
• Bisnis generasi berikutnya yang paling menjanjikan adalah bentuk yang melampaui penyimpanan data sederhana hingga mencakup eksekusi dunia nyata dan koordinasi multipihak

---

Pertanyaan yang dilempar pengumuman headless Salesforce

• Bulan lalu Salesforce mengumumkan pembukaan API dan peluncuran produk headless, sebuah taruhan bahwa nilai di era agen ada pada lapisan data, bukan UI
  • Secara teknis hampir tidak ada yang benar-benar baru — API yang kini dipasarkan sebagai produk headless sudah ada selama bertahun-tahun, tipikal peluncuran pemasaran ala Salesforce
  • Ide intinya adalah struktur di mana agen mengakses langsung data system of record tanpa melewati UI untuk manusia
• Jika UI disingkirkan dan yang tersisa hanya DB, muncul pertanyaan mendasar: apa bedanya dengan Postgres + skema yang dirancang dengan baik + API?
  • Perlu ditinjau apakah elemen yang menopang system of record lama masih tetap berlaku, atau apakah diperlukan standar baru

Era SaaS ketika UI adalah produknya

• System of record adalah source of truth tunggal yang otoritatif untuk domain tertentu
  • CRM adalah system of record untuk pendapatan, HRIS untuk SDM, ERP untuk dana
  • Kekuatan sejatinya bukan sekadar menjadi tempat penyimpanan, melainkan menyediakan realitas bersama yang dipakai seluruh organisasi
• Selama 20 tahun terakhir, yang dijual Salesforce adalah cara pemimpin penjualan menjalankan timnya
  • Dashboard, tampilan pipeline, alat forecast, dan feed aktivitas adalah produk yang sebenarnya dijual, dan model bisnisnya berbasis penjualan seat pengguna
  • DB di bawahnya penting, tetapi bersifat sekunder
• UI menciptakan stickiness
  • Memaksa kebersihan data, membentuk kosakata bersama (Lead, Opportunity, Account), dan membuat sales rep mengisi data yang kalau tidak dipaksa tidak akan mereka input
  • Banyak pemimpin penjualan membawa Salesforce saat pindah kerja bukan karena UI-nya bagus, tetapi karena kebiasaan penggunaan yang sudah tertanam (muscle memory)
• Agen mulai membalik model ini
  • Dapat melakukan read/write langsung ke data tanpa melalui UI
  • Ekosistem yang ramah AI juga berkembang cepat di sekitar SAP
  • Agen computer-use, seiring waktu, meniadakan faktor berbasis manusia seperti preferensi, pelatihan, dan konteks yang tidak terdokumentasi

Kriteria lama untuk menilai stickiness system of record

• Faktor-faktor yang didasarkan pada cara manusia berinteraksi dengan software dan preferensi mereka

• Seberapa sering digunakan

  • CRM digunakan setiap hari oleh tim GTM → menjadi infrastruktur inti
  • Rutinitas kerja, operasi yang sudah terbiasa, dan cadence manajemen yang ditempa selama bertahun-tahun yang dibangun di atasnya adalah unsur yang paling sulit dipindahkan
  • Sering kali bahkan tidak dianggap sebagai sesuatu yang mungkin dimigrasikan

• Write-only atau Read-write

  • System of record yang sticky bersifat read-write
  • CRM terus-menerus dibaca — setiap log panggilan, pembaruan tahap, dan pembuatan tugas membentuk aliran dua arah
  • Karena harus menangani data operasional live, tidak ada titik perpindahan yang aman → sekali diadopsi, sulit ditinggalkan
  • Sebaliknya, ATS (applicant tracking system) lebih dekat ke write-only — setelah rekrutmen selesai, hampir tidak ada alasan untuk melihat kembali datanya

• Seberapa banyak SOP yang tidak terdokumentasi

  • Konteks inti bisnis sering kali tidak dienkode di wiki, melainkan dalam aturan workflow
  • Contoh penjualan: deal enterprise di atas 100 ribu dolar memerlukan persetujuan VP, deal EMEA wajib ditinjau privasi, diskon untuk strategic logo hanya bisa melewati finance di akhir kuartal
  • Konteks seperti ini menentukan perbedaan antara penanganan tepat waktu dan hal yang terlewat
  • Migrasi berarti merekayasa ulang seluruh otomatisasi atau kehilangan memori organisasi secara menyeluruh

• Skala dependensi internal dan eksternal

  • Kebutuhan akses langsung dari sistem internal di bawahnya, auditor eksternal, akuntan, dan regulator
  • Semakin tinggi keterhubungan di kedua sisi, semakin banyak simpul yang harus diurai saat migrasi

• Pentingnya compliance

  • Data payroll, ERP, dan HR memerlukan source of truth tunggal yang dapat dipertahankan secara hukum, kontrol akses admin yang ketat, serta keterlibatan langsung auditor dan regulator
  • Sangat tinggi stickiness-nya
  • Data penjualan dan alat customer support seperti Zendesk berada di sisi sebaliknya — kontinuitas dan konteks penting, tetapi tanpa eksposur regulasi

• Perbandingan biaya perpindahan antar system of record

  • ATS adalah alat workflow dengan batas yang jelas, yaitu perekrutan, dengan integrasi sempit dan sedikit pengguna
  • ERP justru kebalikannya — ledger adalah audit trail itu sendiri, dan akuntan, auditor, serta regulator adalah pemangku kepentingan langsung
  • Mengganti ATS memang menyakitkan, tetapi masih tertahankan; mengganti CRM seperti operasi jantung terbuka; mengganti ERP seperti operasi jantung terbuka pada pasien yang sedang berlari maraton

• Unsur parit pertahanan yang secara tradisional lemah

  • Data proprietari — CRM memang memiliki data kaya, tetapi upaya membangun insight lintas pelanggan sangat minim (hanya ada beberapa upaya seperti Salesforce Einstein)
  • Efek jaringan — dulu dianggap holy grail, tetapi secara historis lemah dalam system of record

Jika UI hilang dan agen datang, apa yang tersisa?

• Agen tidak membutuhkan browser — cukup API, konteks, instruksi, dan kemampuan bertindak

• Dua perubahan memungkinkan hal ini

  • Peningkatan kemampuan penalaran LLM: agen dapat membaca konteks, menyusun rencana, memilih alat, mengeksekusi, dan meninjau hasil tanpa campur tangan manusia
  • Standarisasi akses alat lewat MCP: agen memanggil fungsi eksternal melalui antarmuka bersama
  • Agen computer-use juga dapat menavigasi antarmuka software lama tanpa API jika diberi konteks yang tepat

• Tiga jalur bagi pembeli software

  • Sistem lama + agen: memakai CLI/API milik pemain SaaS lama, produk agen native (Salesforce Agentforce, SAP Joule), atau membangun agen sendiri — tetapi ini mengasumsikan API lengkap dan dapat dipakai, serta transisi ke headless cukup sederhana secara operasional
  • Membangun system of record sendiri (DIY): membangun model data, logika operasional, izin, audit, integrasi, dan agen sendiri dari nol (bisa memakai alat pihak ketiga)
  • Membeli alternatif AI-native: software generasi baru yang sejak awal dibangun berdasarkan machine readability, dengan orkestrasi agen sebagai fitur kelas utama dan siap headless

• Apa yang bertahan dari kriteria evaluasi lama

  • Faktor berbasis perilaku manusia (frekuensi penggunaan, read vs read-write) → menghilang bersama kebiasaan penggunaan
  • Agen membunuh parit pertahanan berbasis kebiasaan, tetapi tidak membunuh parit pertahanan logika operasional dan konteks
  • Bahkan, agar agen dapat bertindak dengan aman, aturan, izin, dan definisi proses yang eksplisit justru menjadi lebih penting

• Dalam jangka pendek, SOP yang tidak terdokumentasi tetap penting

  • Logika organisasi yang dienkode dalam aturan workflow adalah inti agar agen bekerja dengan benar
  • Tidak bisa diekspor dengan rapi (terutama ketika manusia masih terlibat dalam sebagian proses)
  • Namun, seiring konteks makin mudah ditangkap dan agen makin menggantikan tenaga kerja, unsur ini perlahan menjadi kurang relevan

• Konektivitas tetap sulit dan justru makin meluas

  • Fokusnya bukan lagi mengikuti manusia, tetapi mempertahankan konektivitas antara fungsi dan software yang terfragmentasi
  • Agen CRM harus menjahit data dan konteks di antara penjualan, billing, dan customer success
  • Jika menjadi node tempat agen dari berbagai organisasi eksternal bertransaksi, dependensinya akan makin dalam
  • Baik kombinasi pemain lama + agen maupun kombinasi DIY DB + agen sama-sama sulit melintasi berbagai software di bawahnya

• Data compliance tetap penting

  • Data dengan risiko regulasi dan hukum tetap membutuhkan satu sumber data tepercaya
  • Kecil kemungkinan payroll dan data akuntansi akan dibangun serta dipelihara sendiri
  • Masalah tersulit yang belum terpecahkan di dunia agen penuh: agen mana, mewakili siapa, melakukan apa, dengan otorisasi seperti apa yang bisa diaudit
  • System of record yang menjadi lapisan identitas dan otorisasi bagi interaksi antaragennya memaksakan arsitektur kepercayaan, sehingga secara struktural sulit digantikan

Unsur daya tahan baru untuk startup AI-native

• Tingkat kesulitan mereproduksi system of record

  • Dalam jangka pendek, kemudahan mengekstrak dan mereproduksi data berbasis system of record menjadi kunci
  • Pemain SaaS lama membuat API sulit dipakai, terhalang gate, tidak lengkap, atau tidak ekonomis
  • Dengan berkembangnya alat ekstraksi, terutama agen computer-use, hal ini makin mudah
  • Pada saat yang sama, muncul perusahaan baru yang merekonstruksi data lebih kaya dari email, telepon, agen suara, dan dokumen internal
  • AI menurunkan biaya untuk mereproduksi 80% pertama dari system of record, tetapi 20% sisanya (penanganan pengecualian, persetujuan, compliance, dan workflow edge case) adalah titik pembeda antara pengganti sungguhan dan sekadar wedge

• Apakah memiliki data proprietari yang benar-benar bermakna

  • Data yang dapat dipertahankan bukanlah data impor, melainkan data yang secara unik dihasilkan oleh produk itu sendiri
  • Walled garden data — data yang proprietari, teregulasi, atau memerlukan pembaruan berkelanjutan
  • Penyedia software yang berinvestasi pada data yang otoritatif dan lengkap mendapat keunggulan dibanding penyedia generik
  • Data berbasis perilaku yang dihasilkan secara internal: perilaku yang diamati, tingkat respons, pola waktu, hasil proses, benchmark, pola pengecualian, pelacakan performa agen
  • Data adalah konteks itu sendiri (data is the context)

• Apakah memiliki lapisan aksi

  • Dulu cukup menyimpan catatan, tetapi di era baru agenlah yang bertindak
  • Daya tahan bergeser ke produk loop tertutup aksi → penangkapan hasil → umpan balik → perbaikan keputusan
  • Contoh ERP: persetujuan pengeluaran, trigger payroll, penyelesaian invoice, pengiriman notifikasi
  • Produk yang menutup loop berada di dalam eksekusi, bukan sekadar observasi → menghasilkan data unik, membaik seiring penggunaan, dan sulit dicabut tanpa merusak workflow

• Unsur eksekusi dunia nyata

  • Model bisnis dengan konektivitas ke operasi dunia nyata yang tidak akan sepenuhnya diotomatisasi
  • Contoh jaringan operasional seperti DoorDash — secara historis bukan system of record, tetapi memberi pelajaran penting
  • Software yang menutup loop hingga layanan, fulfillment, logistik, operasi lapangan, dan pembayaran memiliki jenis daya tahan yang berbeda dari SaaS murni
  • Bukan hanya menyimpan catatan atau memberi rekomendasi, tetapi mengirim orang, memindahkan barang, dan menuntaskan layanan
  • Bagi builder, peluang ada di pasar tempat software makin banyak mengambil keputusan dan agen mengoordinasikan, tetapi last mile tetap memerlukan eksekusi dunia nyata — misalnya software vertikal yang dipadukan dengan layanan lapangan

• Efek jaringan

  • Dalam system of record lama, efek ini lemah karena software terutama dipakai untuk internal
  • Jika tertanam dalam workflow multipihak, efek jaringan bisa menjadi jauh lebih penting
  • Ketika memediasi interaksi berulang seperti pembeli-penjual, pemberi kerja-karyawan, perusahaan-auditor, vendor-pelanggan, payer-provider, bertambahnya peserta meningkatkan nilai jaringan
  • Cara implementasinya
    • Koordinasi workflow bersama — menjadi tempat kedua pihak bertransaksi, bertukar konteks, dan menyelesaikan pengecualian
    • Benchmarking dan intelligence — memberi norma, anomali, dan rekomendasi berdasarkan pola jaringan
    • Kepercayaan dan standarisasi — jika menjadi rel bersama untuk persetujuan, handoff, compliance, dan pembayaran, ia bukan lagi sekadar DB melainkan bagian dari infrastruktur koordinasi pasar

• Kapabilitas teknis pembeli

  • Walaupun secara teori semua orang kini bisa membuat agen, kemampuan nyata tetap sangat bervariasi
  • Di vertical end market dan fungsi pembeli yang sumber daya engineering internalnya lemah, kecil kemungkinan mereka bisa membangun, memelihara, dan meningkatkan sendiri DB, logika workflow, stack agen, dan governance
  • Biaya juga krusial — DIY mungkin memangkas biaya lisensi, tetapi biaya itu dipindahkan ke implementasi, pemeliharaan, dan kompleksitas internal
  • Peluang ada pada kategori yang operasinya kompleks tetapi secara teknis underserved — manufaktur, back office konstruksi, workflow layanan industri dan lapangan, akuntansi

Unsur lain yang wajib ada (table stakes)

• Model data baru (ontologi)

  • Cara berpikir "DIY DB" cenderung meremehkan nilai dari model objek itu sendiri
  • Software lama dibuat untuk menangkap dashboard, laporan, dan workflow manusia → Opportunity, Ticket, Candidate, dll.
  • Skema untuk agen perlu menangkap penalaran, tindakan, pelacakan status, penanganan pengecualian, delegasi, koordinasi antar sistem
  • Model objek native akan bergeser ke bentuk seperti task, intent, thread, policy, outcome

• Manajemen izin agen

  • Diperlukan sistem perizinan bukan hanya untuk manusia, tetapi juga untuk mengelola agen
  • Mendefinisikan siapa, melalui agen yang mana, di bawah kebijakan apa, dengan persetujuan, audit trail, rollback, dan penanganan pengecualian seperti apa dapat melakukan apa

• Konteks biaya

  • Biaya membangun dan memelihara agen serta DB, biaya akses API, dan seterusnya
  • Ini juga terkait dengan tingkat kesulitan reproduksi data dan jumlah dependensi

Kesimpulan — arah evolusi system of record

• Para pemain SaaS lama yang bergerak ke headless pada dasarnya bertaruh secara implisit bahwa lapisan data tetap menjadi sumber nilai
• Di kategori yang sangat terikat compliance seperti layanan keuangan, taruhan ini akan tetap valid untuk sementara, dan transisi ke headless juga masih lebih jauh di masa depan
• Dari sudut pandang builder, struktur peluang untuk bersaing melawan pemain lama yang beralih ke headless sedang berubah
• System of record generasi berikutnya bukan sekadar tempat menyimpan catatan, melainkan bentuk yang ramah agen untuk menangkap konteks, memulai pekerjaan, dan merekam data exhaust
• Bisnis yang paling menarik adalah yang meluas ke eksekusi dunia nyata — mengoordinasikan tenaga lapangan, penyedia logistik, tim layanan, aset fisik atau berada di tengah banyak pihak
• Mencampurkan model bisnis dunia lama dan inti dari system of record tradisional (data), tetapi dengan data yang ditempatkan di latar belakang