Agentic Web Application: Merancang Aplikasi yang Bekerja untuk Pengguna

Salah satu arah menarik dalam pengembangan web adalah membangun Agentic Web Application: aplikasi yang dapat membantu menjalankan pekerjaan, bukan hanya menyediakan tempat untuk pengguna mengerjakannya sendiri. UI yang nyaman dan fitur yang lengkap tetap dibutuhkan. Namun, ada ruang untuk merancang aplikasi yang menerima tujuan, mengolah konteks, lalu mengeksekusi langkah yang diizinkan sampai hasilnya dapat diperiksa.

Bayangkan pengguna meminta aplikasi menyiapkan penawaran berdasarkan kebutuhan pelanggan. Aplikasi membaca informasi yang relevan, mengidentifikasi kekurangan data, menyusun draf, dan meminta persetujuan sebelum mencatatnya ke sistem bisnis. Pengguna tidak perlu mengarahkan setiap klik, tetapi tetap memegang kendali atas keputusan yang berdampak.

Bagi saya, arah ini menarik karena membuka kemungkinan software bekerja untuk manusia. Tantangannya ada pada fondasi aplikasi: bagaimana AI berinteraksi dengan data dan proses bisnis tanpa mengambil kewenangan yang seharusnya tetap berada pada pengguna atau backend.

Dari percakapan menuju eksekusi berbasis tujuan

Chatbot bisa menjelaskan cara membuat penawaran atau membantu menulis isinya. AI agent mendapat peran tambahan: menggunakan tools, memilih langkah berdasarkan konteks, dan memeriksa hasil tindakan. Pembeda utamanya bukan bentuk antarmuka percakapan, melainkan kewenangan eksekusi dan mekanisme kontrol di belakangnya. Chatbot yang terhubung ke tools pun dapat memiliki kemampuan agentic.

Dalam interaksi berbasis tujuan, pengguna menyampaikan hasil yang diinginkan beserta batasannya. Misalnya, “Siapkan draf penawaran untuk kebutuhan ini, gunakan katalog aktif, dan jangan kirim ke pelanggan sebelum saya setujui.” Sistem kemudian mengelola langkah menuju hasil tersebut. Jika spesifikasi belum jelas, agent harus bertanya, bukan mengisi kekosongan dengan asumsi yang terdengar meyakinkan.

Otonomi di sini bersifat terbatas. Agent boleh mengusulkan produk yang sesuai, tetapi tidak bebas menentukan harga, pajak, atau status pembayaran. Menulis batasan itu dalam prompt saja tidak cukup; aplikasi perlu menegakkannya melalui kode, otorisasi, dan aturan layanan domain.

Tidak semua pekerjaan membutuhkan agent. Jika alurnya tetap dan seluruh keputusan dapat dirumuskan sebagai aturan, workflow deterministik sering lebih mudah diuji. LLM berguna ketika aplikasi perlu memahami kebutuhan berbahasa alami atau menangani variasi konteks. Bagian yang sudah pasti sebaiknya tetap dijalankan oleh program biasa.

Contoh hipotetis: menyiapkan quotation

Contoh berikut adalah rancangan proses bisnis hipotetis, bukan klaim bahwa fitur ini sudah diterapkan pada suatu produk. Anggap sebuah distributor ingin membantu staf penjualan menyiapkan quotation atau penawaran harga dari permintaan pelanggan.

Agent terlebih dahulu membaca kebutuhan, katalog, ketersediaan stok, dan aturan penawaran melalui API yang diizinkan. Jika pelanggan meminta “perangkat untuk kantor kecil” tanpa jumlah atau spesifikasi, agent meminta klarifikasi. Data stok juga harus memiliki konteks waktu, karena ketersediaan saat penyusunan draf belum tentu sama ketika penawaran disetujui.

Setelah informasi cukup, agent menyusun draf berisi item, kuantitas, dan catatan asumsi. Layanan backend menghitung harga serta pajak memakai aturan resmi. UI menampilkan hasilnya agar pengguna dapat mengubah pilihan atau menolak usulan. Diskon di luar kewenangan staf harus masuk ke proses persetujuan yang sesuai, bukan diterima hanya karena agent menganggapnya masuk akal.

Persetujuan pengguna harus terikat pada versi draf tertentu. Jika item atau total berubah, persetujuan lama tidak otomatis berlaku. Sesudah approval, backend memvalidasi ulang data dan membuat record quotation melalui transaksi yang sah. Agent lalu membaca kembali record tersebut untuk memeriksa nomor dokumen, item, total, dan statusnya.

Jawaban “penawaran berhasil dibuat” baru boleh muncul setelah pemeriksaan itu. Jika permintaan mengalami timeout, sistem perlu mencari status transaksi sebelum mencoba ulang. Tanpa langkah ini, satu permintaan pengguna dapat menghasilkan dua penawaran. Membuat quotation juga tidak berarti mengirimkannya ke pelanggan; pengiriman merupakan tindakan terpisah dengan izin tersendiri.

Arsitektur yang menempatkan aturan di backend

Susunan sederhananya dapat dibaca seperti ini:

Browser/UI → orchestrator dan policy → tools/API → layanan domain, database, event/job → validasi dan hasil

Browser menerima tujuan dan menampilkan perkembangan pekerjaan. Orchestrator mengelola konteks serta urutan langkah, sedangkan policy menentukan tindakan yang diizinkan dan kapan approval diperlukan. Tools menyediakan operasi terbatas, seperti mencari produk atau membuat draf, bukan akses bebas untuk menjalankan query database sesuka model.

LLM mengusulkan langkah. Backend tetap bertanggung jawab menegakkan aturan bisnis dan mengotorisasi setiap transaksi. Permintaan model untuk membuat penawaran dengan harga tertentu harus diperlakukan seperti input lain yang belum dipercaya. Backend memeriksa referensi produk, hak pengguna, dan aturan perhitungan sebelum menerima perubahan.

Kontrak tools perlu bertipe jelas: parameter wajib, format respons, status kesalahan, serta batas ukuran data. Validasi struktur membantu menolak input yang salah, tetapi validasi bisnis tetap diperlukan. Kuantitas yang bertipe angka, misalnya, belum tentu merupakan kuantitas yang diperbolehkan.

Untuk operasi tulis, gunakan kunci idempotensi dan transaksi sesuai kebutuhan. Kunci idempotensi menghubungkan percobaan ulang dengan operasi yang sama, sehingga retry tidak membuat record baru. Setelah itu, verifikasi hasil dari backend menjadi dasar laporan kepada pengguna, bukan sekadar narasi LLM tentang tindakan yang direncanakannya.

Kendali pengguna, keamanan, dan pekerjaan asinkron

UI tetap penting ketika aplikasi semakin mampu bekerja mandiri. Pengguna perlu melihat tujuan yang sedang diproses, langkah yang selesai, data yang masih kurang, dan tindakan yang menunggu persetujuan. Tombol cancel juga harus memiliki arti yang jelas: menghentikan langkah berikutnya tidak selalu membatalkan transaksi yang sudah tersimpan. Untuk tindakan yang terlanjur terjadi, aplikasi perlu menjelaskan apakah tersedia operasi pembatalan atau kompensasi.

Hak akses agent mengikuti identitas pengguna dan batas peran agent itu sendiri. RBAC dan prinsip least privilege membatasi akses pada operasi yang diperlukan. Staf yang tidak berhak membaca data pelanggan tertentu tidak boleh mendapatkan akses tersebut lewat agent. Backend harus memeriksa otorisasi pada setiap pemanggilan tool, termasuk ketika pekerjaan berjalan sebagai job di latar belakang.

Pekerjaan panjang sebaiknya memakai job asinkron dengan status tersimpan. Tetapkan timeout, jumlah retry, batas langkah, dan batas biaya pemanggilan model. Kesalahan validasi tidak perlu dicoba ulang terus-menerus; gangguan sementara mungkin layak mendapat retry terbatas. Jika batas tercapai atau agent menemui keputusan di luar kewenangannya, sistem berhenti dan melakukan eskalasi kepada manusia.

Memori perlu dibatasi menurut pengguna, organisasi, dan tujuan tugas. Simpan konteks yang diperlukan dengan kebijakan retensi yang jelas, hindari memasukkan data sensitif yang tidak relevan, dan cegah konteks satu pelanggan terbawa ke pelanggan lain. Audit mencatat pemanggil, tindakan, approval, serta hasil tanpa menyalin rahasia secara berlebihan.

Dokumen pelanggan dan keluaran tools juga merupakan data yang belum dipercaya. Teks yang memerintahkan agent mengabaikan aturan dapat menjadi prompt injection. Isi dokumen tidak boleh berubah menjadi kebijakan sistem atau memberi hak akses tambahan. Pemisahan instruksi dan data perlu didukung pembatasan tools serta pemeriksaan backend.

Menguji hasil kerja dan memilih cakupan awal

Mulailah dari tugas kecil dengan kriteria selesai yang konkret, seperti membuat draf quotation tanpa mengirimkannya. UAT bersama pemilik proses perlu memeriksa record aktual, perhitungan, dan jalur approval. Jawaban yang persuasif tidak membuktikan pekerjaan telah selesai.

Skenario negatif sama pentingnya: produk tidak ditemukan, stok berubah, pengguna kehilangan izin, approval kedaluwarsa, API timeout setelah transaksi tersimpan, atau dokumen berisi instruksi berbahaya. Uji pula pembatalan saat job berjalan. Hasil yang diharapkan harus menyebut keadaan backend dan apa yang pengguna lihat, termasuk kapan sistem wajib menolak atau meminta bantuan.

Model bisa salah menafsirkan kebutuhan maupun memilih langkah. Karena itu, evaluasi perlu mengamati kualitas hasil dan perilaku saat gagal, bukan hanya kelancaran percakapan. Jika workflow biasa sudah menyelesaikan masalah dengan baik, tidak ada kewajiban menggantinya dengan agent.

Penutupnya, Agentic Web Application menawarkan cara merancang software yang bekerja untuk pengguna dengan kontrol yang jelas. Takeaway utama: bangun fondasi yang andal terlebih dahulu, terutama aturan backend, batas kewenangan, approval, dan verifikasi hasil. Kemampuan tersebut lebih menentukan kegunaan aplikasi daripada sekadar menambahkan chatbot pada layar yang sudah ada.