Pengguna Perangkat Lunak Anda Berikutnya Adalah Agen AI. Siapkah Arsitektur Anda?

Bayangkan sebuah agen AI menangani sengketa tagihan pelanggan. Agen itu membaca keluhan, memeriksa riwayat akun, lalu menyimpulkan bahwa kredit layak diberikan. Semua itu dilakukan dalam hitungan detik.

Mengesankan. Sekarang, mintalah agen itu benar-benar menerbitkan kredit tersebut.

Perjanjian pelanggan tersimpan di sistem lain. Aturan persetujuannya tersembunyi dalam kode aplikasi. Perangkat penagihan mengharuskan seseorang mengeklik beberapa layar.

Agen itu memahami apa yang perlu dilakukan, tetapi arsitekturnya tidak memungkinkan agen tersebut menuntaskan pekerjaan.

Itulah masalah yang saya perkirakan akan dihadapi lebih banyak perusahaan seiring AI berbasis agen mulai diterapkan. Namun, yang aneh adalah bahwa hambatan untuk menyelesaikan tugas itu sangat sedikit kaitannya dengan kecerdasan agen.

Selama bertahun-tahun, kita telah memodernisasi perangkat lunak perusahaan untuk orang-orang yang menggunakannya. Kini, kita perlu memodernisasinya untuk agen yang akan semakin sering mengoperasikannya.

Antarmuka Pengguna Tidak Pernah Menjadi Keseluruhan Produk

Pikirkan cara kerja perangkat lunak perusahaan saat ini. Orang membuka aplikasi, menjelajahi dasbor, mengambil keputusan, dan meneruskan pekerjaan dari satu sistem ke sistem lain. Antarmuka pengguna adalah sarana mereka berinteraksi dengan bisnis.

Agen belum tentu memerlukan layar-layar tersebut. Agen dapat mengambil informasi dan memulai tindakan melalui API, server Protokol Konteks Model (MCP), serta antarmuka terprogram lainnya. Ini merupakan bagian dari peralihan menuju arsitektur tanpa antarmuka.

Namun, tanpa antarmuka bukan berarti aplikasinya hilang. Data, aturan bisnis, izin, dan persyaratan kepatuhannya tetap penting. Bahkan, menurut saya, semua itu menjadi lebih penting.

Selama bertahun-tahun, vendor perangkat lunak membangun keunggulan kompetitif lewat antarmuka pengguna yang dirancang dengan baik, kebiasaan pengguna, dan biaya pelatihan ulang karyawan. Keunggulan tersebut melemah ketika agen melakukan lebih banyak pekerjaan tanpa membuka antarmuka aplikasi. Yang menjadi lebih bernilai adalah sistem pencatatan yang mendasarinya: data tepercaya, logika domain yang tervalidasi, tata kelola operasional, dan transaksi yang dapat diaudit.

Ada pula konsekuensi komersial: hingga $234 miliar belanja aplikasi perusahaan dapat terdampak disrupsi AI berbasis agen pada 2030. Belanja itu berisiko terdampak disrupsi, bukan dipastikan akan hilang. Selain itu, ketika agen mengerjakan tugas yang sebelumnya dilakukan orang melalui dasbor, harga per pengguna kemungkinan semakin bergeser ke model berbasis penggunaan, tindakan, atau hasil.

Bagi vendor perangkat lunak, ini merupakan tantangan model bisnis. Bagi perusahaan yang mengandalkan aplikasi mereka, ini merupakan tantangan arsitektur.

Kita Memodernisasi Bagian-Bagiannya, Bukan Alur Kerjanya

Sebagian besar perusahaan telah menjalankan modernisasi selama bertahun-tahun. Satu tim memperbarui aplikasi lama. Tim lain mengonsolidasikan data yang terpencar ke dalam platform modern. Tim ketiga membangun integrasi atau sekadar menyegarkan antarmuka pengguna.

Setiap proyek dapat berhasil jika dijalankan sendiri. Masalah mulai muncul ketika agen harus menjalankan alur kerja yang mencakup semuanya.

Anda dapat memberikan informasi pelanggan yang akurat kepada agen, tetapi jika aplikasi yang bertanggung jawab menindaklanjutinya masih menyembunyikan aturan penting dalam kode lama, apa yang terjadi selanjutnya? Atau, Anda dapat menyediakan API yang rapi, sementara data di baliknya tetap tidak konsisten. Agen dapat mengambil tindakan, tetapi dapatkah Anda memercayai keputusannya?

Dalam kedua kasus, kita telah memodernisasi sebagian teknologi tanpa memodernisasi pekerjaannya.

AI berbasis agen tidak peduli proyek modernisasi mana yang berhasil. Yang penting baginya adalah apakah seluruh alur kerja berjalan.

Begini gambaran penerapannya. Seorang klien perlu mempercepat penyusunan penawaran untuk perbaikan mesin yang rumit, yang kontraknya menentukan komponen mana yang boleh diperbaiki, diganti, atau direkondisi. Setiap penawaran membutuhkan riset manual selama berhari-hari, bahkan terkadang berminggu-minggu, dengan menelusuri kontrak dan manual perawatan. Klien tersebut telah memodernisasi platform datanya, tetapi penyusunan penawaran tidak menjadi lebih cepat karena hambatannya bukan data. Hambatannya adalah riset. Kami membangun ulang alur kerja itu dengan serangkaian agen riset, memangkas waktu riset sebesar 80%, dan membuat proses penyusunan penawaran berjalan dengan kecepatan yang sama sekali berbeda.

Karena itulah modernisasi aplikasi dan data tidak dapat direncanakan sebagai dua alur kerja yang terpisah. Arsitektur harus mendukung hasil bisnis secara menyeluruh.

API Tidak Membuat Sistem Siap Digunakan Agen

Kita mungkin tergoda untuk berpikir bahwa solusinya sederhana: buka titik akhir, hubungkan agen, lalu selesai.

Andai semudah itu.

Mengambil informasi adalah satu hal. Menerbitkan kredit, memperbarui catatan keuangan, atau memesan komponen pengganti adalah hal yang sama sekali berbeda. Di sini, kita membahas pelaksanaan, bukan sekadar akses.

Di sinilah saya menggunakan istilah permukaan kendali agen: antarmuka terbatas dengan tata kelola yang jelas, yang menjadi jalur bagi agen untuk membaca dan menulis ke sistem pencatatan.

API dan server MCP dapat menyediakan alat dan data bagi agen. Namun, MCP tidak otomatis menegakkan aturan bisnis atau menentukan siapa yang berwenang bertindak. Kontrol tersebut tetap harus dirancang ke dalam sistem dan alur kerja yang mendasarinya.

Dapatkah agen mengambil data yang otoritatif? Apakah aturan bisnis dirumuskan dengan jelas dan diterapkan secara konsisten? Dapatkah agen merekomendasikan tindakan, tetapi hanya menjalankan tindakan yang berwenang dilakukannya? Jika terjadi masalah, dapatkah kita melacak tindakan tersebut, menangani pengecualian, dan, jika memungkinkan, membatalkannya?

Ini bukan masalah yang dapat diselesaikan sendiri oleh model yang lebih baik. Ini adalah pertanyaan tentang alur kerja, desain aplikasi, arsitektur data, integrasi, dan tata kelola. Semuanya harus dijawab secara bersamaan.

Mulailah dari Pekerjaannya, Bukan Teknologinya

Jadi, dari mana sebaiknya Anda memulai?

Saya tidak akan memulai dengan membuat setiap aplikasi tanpa antarmuka pengguna atau membuka akses ke semua API yang tersedia. Saya akan memulai dengan satu alur kerja bisnis yang bermakna.

Telusuri alur tersebut dari awal hingga akhir. Sistem mana yang menyimpan catatan? Di mana logika bisnis berada? Data apa yang dapat dipercaya oleh agen? Keputusan mana yang memerlukan persetujuan manusia? Apa yang terjadi jika sistem gagal di tengah proses? Bagaimana tata kelola dipertahankan?

Anda akan menemukan kesenjangan yang penting. Itulah peta jalan modernisasi Anda: daftar pekerjaan terkoordinasi di berbagai aplikasi, data, integrasi, dan kontrol, yang didorong oleh hasil bisnis, bukan proyek teknologi yang tidak saling terhubung.

Ukurlah berdasarkan hal-hal yang sesuai. Bukan dari jumlah API yang telah Anda buka aksesnya atau banyaknya data yang telah dimigrasikan, melainkan dari apakah alur kerja dapat diselesaikan dengan andal, bagaimana pengecualian ditangani, dan apakah hasil bisnis membaik.

Tujuannya bukanlah otonomi di segala hal. Tujuannya adalah pelaksanaan yang andal dan tepercaya, dengan pertimbangan manusia di tempat yang semestinya.

Perubahan Nyata Jauh Lebih Besar daripada Sekadar Tanpa Antarmuka

Yang membuat saya bersemangat bukanlah menyingkirkan dasbor, melainkan apa yang terjadi ketika orang tidak lagi harus memindahkan pekerjaan secara manual di antara sistem yang tidak saling terhubung untuk menyelesaikan tugas.

Namun, kita tidak akan sampai ke sana dengan menempatkan agen di atas arsitektur yang sejak awal tidak dirancang untuk mendukungnya.

Generasi berikutnya dari perangkat lunak perusahaan tidak hanya akan ditentukan oleh apa yang dapat dilihat orang. Generasi ini akan ditentukan oleh apa yang dapat dilakukan agen secara andal dan bertanggung jawab.