Sistem Spiral Kematian — dan Bagaimana Agen AI Memperbaikinya

TL;DR:Setelah delapan tahun membangun sistem, saya menemukan pola yang dapat diprediksi: setiap sistem pada akhirnya menjadi tidak dapat digunakan karena kesenjangan antara alur kerja yang dirancang dan kompleksitas dunia nyata. Kesenjangan ini tumbuh dari kreativitas manusia, batasan waktu, alat yang tumpang tindih, dan utang dokumentasi. Saya berhenti mencoba membangun sistem yang sempurna. Sebagai gantinya, saya membangun trio agen AI yang menangani entri data, deteksi anomali, dan pemeliharaan sistem — menciptakan infrastruktur yang dapat menyembuhkan diri sendiri yang menghilangkan kesenjangan alih-alih mengelolanya.

Pola yang Tidak Pernah Dibicarakan

Sejak 2016, Mercury telah membangun dan bereksperimen dengan banyak sistem.

Kami membangun ERP dan CRM kami sendiri. Mendefinisikan alur kerja kami. Mengadopsi alat siap pakai dan menyatukannya dengan Zapier, n8n, dan integrasi kustom. Kami bangga dengan tumpukan kami. Rasanya canggih. Rasanya seperti kami melakukan apa yang seharusnya dilakukan oleh perusahaan modern.

Tetapi selama enam bulan terakhir, saya melihat kembali delapan tahun terakhir dan melihat sesuatu yang tidak ingin saya lihat:

Sebuah spiral kematian. Dan itu ada di mana-mana.

Inilah cara kerjanya. Anda membangun sebuah sistem. Anda mendefinisikan alur kerja. Kasus penggunaan dibatasi pada alur kerja itu berdasarkan desain. Kemudian bisnis tumbuh. Situasi baru muncul. Kasus tepi berlipat ganda. Orang mulai menggunakan sistem dengan cara "kreatif" yang tidak pernah dimaksudkan. Data berakhir di kolom yang salah. Laporan menjadi tidak dapat diandalkan. Seseorang membuat spreadsheet bayangan untuk "memperbaiki" masalah. Sekarang Anda memiliki dua sumber kebenaran. Kemudian tiga.

Kesenjangan antara sistem dan kenyataan terus meluas.

Akhirnya, sistem menjadi tidak dapat digunakan. Bukan karena teknologinya gagal. Melainkan karena jarak antara apa yang diasumsikan sistem dan apa yang sebenarnya dilakukan bisnis menjadi terlalu besar untuk dijembatani.

Di Mercury, ini terjadi secara perlahan. Data CRM kami tidak berada di CRM kami. Itu berada di platform pesan kami, inti CRM kami, catatan panggilan PBX kami, dan utas email. Pelanggan yang sama. Lima representasi berbeda. Tidak ada yang sepenuhnya konsisten. Ketika kami menjalankan laporan triwulanan, rekonsiliasi sumber-sumber ini memakan waktu berhari-hari. Terkadang kami menemukan ketidaksesuaian yang telah ada selama berbulan-bulan — data yang dimasukkan "secara kreatif" oleh staf yang merasa alur kerja resmi terlalu kaku untuk situasi klien yang nyata.

Saya telah menyaksikan pola ini di perusahaan klien. Saya telah menyaksikannya di perusahaan besar dengan departemen TI beranggotakan seratus orang. Mekaniknya bervariasi. Polanya bersifat universal.

Dari Mana Jarak Itu Datang

Jarak memiliki empat sumber. Tidak ada yang bersifat teknis.

Kreativitas manusia.Staf Anda bukan robot. Ketika sistem tidak sesuai dengan situasi, mereka berimprovisasi. Mereka memasukkan data di bidang alternatif. Mereka menggunakan bagian "catatan" untuk data terstruktur. Mereka membuat proses paralel di luar sistem karena lebih cepat daripada menunggu TI untuk memperbaiki sesuatu.

Waktu.Bahkan ketika Anda mengidentifikasi celah, perbaikan memerlukan waktu. Selalu ada prioritas yang lebih tinggi. Celah tersebut terletak di backlog selama berbulan-bulan. Sementara itu, solusi sementara menjadi hal yang baru normal.

Pengambilan keputusan.Apa yang harus Anda perbaiki? Mengapa? Dalam urutan apa? Kebanyakan organisasi tidak dapat menjawab ini dengan jelas. Celah tersebut tetap ada karena tidak ada yang memiliki wewenang dan konteks untuk memutuskan apa yang dimaksud dengan "benar".

Dokumentasi.Pada saat seseorang mendokumentasikan bagaimana solusi sementara bekerja, tiga solusi sementara lainnya telah muncul. Dokumentasi selalu tertinggal dari kenyataan. Terkadang itu bahkan menyesatkan.

Dan kemudian ada faktor yang memperburuk: tumpang tindih.

Data CRM Anda tidak hidup di CRM Anda. Itu hidup di platform pesan Anda, inti CRM Anda, sistem PBX Anda, utas email Anda, dan catatan pribadi perwakilan penjualan. Pelanggan yang sama. Lima representasi berbeda. Tidak ada yang sepenuhnya konsisten. Ketika Anda menjalankan laporan, yang mana yang benar?

Ini bukan bug. Ini adalah keadaan alami dari organisasi mana pun yang telah ada selama lebih dari dua tahun.

Jawaban Tradisional (dan Mengapa Itu Gagal)

Jawaban tradisional adalah membangun sistem yang lebih baik. Lebih fleksibel. Lebih dapat dikonfigurasi. Lebih "tahan masa depan."

Saya sudah mencoba ini. Itu tidak berhasil.

Semakin fleksibel Anda membuat suatu sistem, semakin kompleks itu menjadi. Semakin kompleks itu menjadi, semakin lebar kesenjangan antara kemampuan yang dirancang dan penggunaan aktual. Fleksibilitas tidak menghilangkan kesenjangan. Itu hanya memindahkannya ke tingkat abstraksi yang lebih tinggi.

Vendor perangkat lunak perusahaan telah menjual "fleksibilitas" selama beberapa dekade. Setiap implementasi dimulai dengan "kami akan mengonfigurasinya sesuai alur kerja Anda" dan diakhiri dengan "alur kerja Anda perlu berubah untuk cocok dengan sistem." Kesenjangan selalu menang.

Apa yang Saya Bangun Sebagai Gantinya

Sekitar sebulan yang lalu, saya berhenti mencoba membangun sistem yang sempurna.

Sebagai gantinya, saya merancang untuk kesenjangan itu sendiri.

Saya membangun tiga agen AI. Bukan chatbot. Bukan asisten. Sebuah lapisan operasional yang berada di antara manusia dan sistem dan menangani kekacauan yang selalu terakumulasi.

Agen Satu: Titik Masuk.

Staf berinteraksi dengan agen ini untuk entri data. Bahasa alami. Tanpa formulir. Tanpa kolom. Agen ini mengajukan pertanyaan klarifikasi, menyusun data, dan menulisnya ke tempat yang tepat dalam format yang tepat. Jika situasi tidak cocok dengan kategori yang ada, ia tidak memaksakan paku persegi ke dalam lubang bulat. Ia memberi tanda.

Agen Dua: Analis.

Ketika Agen Satu mendeteksi anomali — sesuatu yang tidak sesuai dengan skema saat ini, pola baru, solusi sementara yang sedang berlangsung — itu meningkatkan ke Agen Dua. Agen ini menganalisis anomali, mengidentifikasi akar penyebab, dan menghasilkan laporan: apa yang terjadi, mengapa itu terjadi, perubahan sistem apa yang akan menghilangkan celah, dan apa saja trade-off-nya.

Laporan itu mendarat di meja saya. Saya meninjaunya. Saya menyetujui atau memodifikasi rekomendasi tersebut.

Agen Tiga: Sang Pelaksana.

Setelah disetujui, Agen Tiga mengeksekusi. Ia memperbaiki sistem. Memperbarui skema. Memodifikasi integrasi. Menulis dokumentasi. Dan ini dilakukan bukan sebagai proyek sekali jalan, tetapi sebagai proses yang berkelanjutan.

Celah tidak lagi terakumulasi. Ia ditutup secara real-time.

Hasilnya, bahkan di bulan pertama ini, sangat mencolok. Rata-rata siklus celah-ke-perbaikan kami — waktu antara mengidentifikasi ketidakcocokan alur kerja sistem dan memperbaikinya — dulunya diukur dalam kuartal. Pada awal 2026, kami telah memperpendeknya menjadi sekitar dua minggu melalui disiplin proses yang lebih baik. Dengan trio agen, siklus saat ini adalah di bawah empat jam untuk perubahan non-struktural, dan hari yang sama untuk penyesuaian tingkat skema yang memerlukan persetujuan saya.

Spreadsheet bayangan menghilang. Bukan karena kami mewajibkannya. Karena sistem sekarang mencerminkan kenyataan dengan cukup akurat sehingga orang tidak memerlukan solusi alternatif.

Ini adalah prinsip yang sama yang mendasari metodologi GEO kami. Kerangka audit GEO terpadu kami — yang mendapatkan skor mtsoln.com 82 (Metode A 91, Metode B 76) pada audit ulang 27 Agustus — dibangun di atas penutupan celah yang berkelanjutan, bukan optimasi satu kali. Celah antara bagaimana sistem AI mewakili merek Anda dan bagaimana Anda sebenarnya beroperasi tidak tertutup dalam proyek. Itu tertutup melalui pengamatan dan adaptasi yang terus menerus. Kami menerapkannya pada situs klien. Sekarang kami menerapkannya pada infrastruktur kami sendiri.

Apa Artinya Ini Sebenarnya

Ini bukan otomatisasi. Otomatisasi mengasumsikan prosesnya diketahui dan dapat diulang. Ini adalah sesuatu yang berbeda. Ini adalah infrastruktur adaptif.

Sistem tidak berusaha untuk memprediksi setiap kasus penggunaan. Itu tidak perlu. Ia mengamati apa yang sebenarnya terjadi, mengidentifikasi deviasi, dan berkembang untuk mengakomodasi mereka. "Sistem yang sempurna" menjadi tidak perlu karena sistem tidak pernah selesai — ia terus menjadi lebih akurat relatif terhadap kenyataan.

Pendekatan ini sekarang menjadi dasar dari dua hal di Mercury:

Layanan GEO kami.Optimisasi Mesin Generatif bukan tentang praktik terbaik yang statis. Ini tentang terus beradaptasi dengan bagaimana sistem AI mewakili merek Anda. Prinsip yang sama berlaku: amati, analisis, adaptasi, implementasi.

Inti ERP/CRM kami.Sistem tidak memaksakan alur kerja yang kaku. Ia belajar dari alur kerja. Kesenjangan antara proses yang dirancang dan proses yang sebenarnya menjadi sinyal yang mendorong perbaikan, bukan kebisingan yang merusak keandalan.

Keberatan yang Anda Pikirkan

"Ini terdengar tidak stabil." "Bagaimana jika agen membuat perubahan yang salah?" "Bagaimana dengan tata kelola?"

Ini adalah kekhawatiran yang valid. Berikut cara saya mengatasinya:

Persetujuan manusia adalah wajib untuk perubahan struktural.Agen Dua mengusulkan. Saya menyetujui. Agen Tiga melaksanakan. Prosesnya cepat — seringkali dalam hari yang sama — tetapi keputusan manusia tetap menjadi gerbang. Dalam bulan pertama ini, saya telah menolak atau memodifikasi sekitar 15% proposal. Biasanya karena agen mengidentifikasi celah nyata tetapi mengusulkan solusi yang akan menciptakan tumpang tindih di tempat lain. Analis tidak memiliki konteks bisnis yang lengkap. Itulah sebabnya manusia tetap terlibat.

Perubahan dapat dibalik.Setiap patch didokumentasikan dan versi. Jika sesuatu rusak, kami akan mengembalikannya. Dokumentasi ditulis oleh agen yang melakukan perubahan, jadi sebenarnya akurat — tidak seperti dokumentasi manusia yang tertinggal dari kenyataan selama berbulan-bulan.

Alternatifnya lebih buruk.Model tradisional memberi Anda ilusi stabilitas sementara celah tumbuh diam-diam di bawah permukaan. Pada saat Anda menyadari, sistem sudah tidak dapat digunakan dan migrasi menjadi proyek enam bulan. Saya lebih suka melakukan penyesuaian kecil yang terlihat, sering, daripada kerusakan bertahap yang tidak terlihat.

Ada juga argumen biaya.Kami menjalankan infrastruktur agen kami di swarm Mac Studio, mengarahkan melalui Mercury Flux — lapisan pengaturan model kami yang mengirimkan ~18 miliar token per bulan dengan biaya campuran sekitar $0,07 per juta token. Setara ritel akan menjadi $20.000–200.000 per bulan. Trio agen menambah biaya komputasi marginal ke infrastruktur yang sudah kami jalankan. Bandingkan itu dengan biaya proyek migrasi sistem tunggal, atau biaya peluang dari laporan yang memerlukan waktu berhari-hari untuk disesuaikan karena data berada di lima tempat.

Ekonominya bahkan tidak mendekati.

Apakah Ini Akan Diterima?

Saya tidak tahu.

Ini adalah perubahan radikal dari cara organisasi memikirkan sistem. Kami dilatih untuk percaya bahwa sistem yang baik adalah sistem yang stabil. Bahwa perubahan adalah risiko. Bahwa tujuannya adalah untuk melakukannya dengan benar di awal.

Tetapi "benar di awal" adalah fantasi di lingkungan mana pun yang tumbuh, beradaptasi, atau berurusan dengan manusia. Pertanyaannya bukan apakah sistem Anda akan menyimpang dari kenyataan. Ini adalah apakah Anda memiliki mekanisme untuk menutup kesenjangan lebih cepat daripada ia terbuka.

Kebanyakan organisasi tidak. Mereka memiliki tumpukan pekerjaan. Mereka memiliki "kami akan memperbaikinya di rilis berikutnya." Mereka memiliki spreadsheet bayangan dan dokumentasi solusi sementara yang hidup di thread Slack.

Saya mengusulkan sesuatu yang berbeda: terima kesenjangan sebagai hal yang tak terhindarkan, dan bangun kemampuan untuk menutupnya secara terus-menerus.

Beberapa orang akan membenci ini. Ini mengancam kompleks industri perencanaan proyek. Ini menjadikan "implementasi" sebagai biaya operasional yang berkelanjutan alih-alih proyek satu kali yang dapat dikapitalisasi. Ini memerlukan kepercayaan pada agen AI untuk melakukan perubahan sistem yang sebelumnya dikendalikan oleh manusia.

Tapi saya telah menjalankan ini selama sebulan. Celah yang dulunya membutuhkan kuartal untuk ditutup sekarang dapat ditutup dalam hitungan jam. Spreadsheet bayangan menghilang karena sistem sebenarnya mencerminkan kenyataan. Dokumentasinya terkini karena dihasilkan, bukan dipelihara.

Ini tidak sempurna. Tapi ini lebih baik daripada spiral kematian.

Implikasi yang Lebih Luas

Ini bukan hanya tentang sistem internal Mercury.

Pola yang sama berlaku untuk setiap organisasi yang bergulat dengan transformasi digital. Alasan mengapa begitu banyak proyek transformasi gagal bukan karena teknologinya tidak berfungsi. Ini karena celah antara sistem baru dan bisnis yang sebenarnya selalu tumbuh lebih cepat daripada tim implementasi dapat menutupnya.

Agen AI mengubah ekonomi dari persamaan ini. Ketika adaptasi otomatis dan berkelanjutan, celah menjadi dapat dikelola. Ketika itu manual dan berbasis proyek, celah selalu menang.

Organisasi yang pertama kali memahami ini akan memiliki keuntungan struktural. Bukan karena sistem mereka dirancang lebih baik, tetapi karena sistem mereka lebih baik dalam menjadiapa yang sebenarnya dibutuhkan bisnis.

Inilah juga mengapa saya tidak khawatir tentang AI yang mengkomoditaskan industri kita.

43% prospek yang hilang melalui celah AI-ke-manusia? Angka itu berasal dari pengamatan yang sama. Sistem yang dirancang untuk alur kerja ideal melewatkan perilaku nyata. Bisnis yang menangkap 43% itu tidak akan menjadi yang memiliki chatbot yang lebih baik. Mereka akan menjadi yang infrastrukturnya beradaptasi terus-menerus dengan cara manusia sebenarnya bekerja — bukan bagaimana diagram proses mengatakan mereka seharusnya bekerja.

Itulah taruhan yang saya ambil.

Ditulis dari Hong Kong, di mana kelembapan tinggi dan selisih antara pendingin udara dan kenyataan sekitar 12 derajat.