Agent AI membaca stok lama: periksa ulang sebelum menjanjikan barang

2026-10-19 · Agus Ramdan

Seorang pelanggan menanyakan dua unit barang. Agent AI membaca stok: masih ada dua. Ia menyusun jawaban, staf menyetujuinya, lalu pelanggan menerima kabar bahwa barang tersedia. Sayangnya, kasir sudah menjual satu unit saat jawaban itu disiapkan.

Dalam contoh hipotetis ini, model tidak mengarang angka. Ia mengambil data yang benar pada saat pembacaan. Kesalahannya muncul ketika sistem memperlakukan hasil pembacaan sebagai jaminan yang tetap berlaku setelah keadaan berubah.

Untuk UMKM yang mulai memakai agent AI dalam penjualan, masalah ini patut diperiksa sebelum menambah kebebasan bertindak. Bahasa jawaban bisa sangat meyakinkan, sementara persediaannya sudah berbeda. Meminta model agar lebih teliti tidak menyelesaikan persaingan antara dua transaksi.

Data yang benar punya konteks waktu

Angka persediaan sebaiknya dibaca bersama identitas produk, lokasi, jenis kuantitas, dan waktu pengambilannya. Dua unit yang tercatat secara fisik belum tentu sama dengan dua unit yang bebas dijual. Sebagian barang mungkin sudah dialokasikan untuk pesanan lain atau menunggu pemeriksaan.

Sistem perlu menentukan angka mana yang boleh dipakai untuk menjawab pelanggan. Ini keputusan bisnis dan integrasi data, bukan sesuatu yang layak ditebak model dari nama kolom. Bila definisinya belum jelas, agent sebaiknya menyampaikan bahwa ketersediaan perlu dikonfirmasi.

Dokumentasi PostgreSQL memberi penjelasan teknis yang relevan. Pada tingkat isolasi bawaan Read Committed, perintah baca biasa melihat data yang sudah dikomit sebelum perintah tersebut dimulai. Dua perintah baca berturut-turut bahkan dapat melihat hasil berbeda dalam transaksi yang sama jika transaksi lain mengomit perubahan di antaranya.

Artinya, berhasil membaca database tidak berarti keadaan berhenti berubah. Mengambil angka dari sumber resmi memperbaiki dasar jawaban, tetapi belum memberi hak untuk menjanjikan barang itu kepada seseorang.

Pisahkan informasi, penawaran, dan reservasi

Tiga tindakan ini sering tercampur dalam percakapan penjualan. Memberi informasi berarti melaporkan kondisi yang terbaca. Menyiapkan penawaran berarti menyusun syarat transaksi. Melakukan reservasi berarti sistem mengalokasikan barang menurut aturan tertentu.

Dalam rancangan yang disarankan di sini, agent pembaca stok tidak otomatis mendapat kewenangan reservasi. Jawabannya dapat berbunyi, “Saat pengecekan, tersedia dua unit; ketersediaan akan dikonfirmasi saat pemesanan.” Kalimat tersebut lebih jujur daripada menjamin barang yang belum dialokasikan.

Jika usaha membutuhkan kepastian selama pelanggan membayar, buat mekanisme reservasi tersendiri. Tentukan kapan reservasi dimulai, berapa lama berlaku, siapa yang boleh membatalkan, dan bagaimana barang kembali tersedia setelah kedaluwarsa. Ini usulan desain, bukan klaim bahwa semua aplikasi toko menyediakan kemampuan tersebut.

Reservasi juga bukan bukti pembayaran atau bukti pengiriman. Status yang ditampilkan kepada staf dan pelanggan harus mengikuti hasil masing-masing proses. Model tidak boleh menaikkan status hanya karena percakapan terdengar sudah selesai.

Periksa syarat ketika perubahan disimpan

Membaca ulang tepat sebelum bertindak membantu memperkecil jeda, tetapi masih menyisakan celah. Transaksi lain dapat mengubah stok di antara pembacaan terakhir dan penyimpanan. Karena itu, backend perlu menegakkan syarat pada operasi yang mengubah keadaan.

Salah satu pola adalah pembaruan bersyarat: lakukan perubahan hanya jika keadaan yang menjadi dasar keputusan masih sesuai. Dokumentasi Shopify untuk inventorySetQuantities menjelaskan dukungan compare-and-set. Secara konsep, pembaruan jumlah hanya dilakukan bila jumlah tersimpan cocok dengan nilai pembanding; ketidakcocokan menghasilkan kesalahan.

Batas penggunaannya penting. Shopify menyatakan operasi penetapan jumlah absolut tersebut ditujukan bagi sistem yang menjadi sumber kebenaran persediaan. Dokumentasinya juga memperingatkan bahwa melewati pemeriksaan pembanding dapat menghasilkan jumlah tidak akurat ketika permintaan berlangsung bersamaan. Ini contoh kendali konkurensi, bukan anjuran agar agent penjualan bebas menetapkan stok.

Untuk aplikasi sendiri, tim pengembang perlu memilih transaksi, penguncian, atau pembaruan bersyarat sesuai aturan bisnis. PostgreSQL mendokumentasikan bahwa kondisi WHERE pada pembaruan diperiksa ulang terhadap versi baris yang sudah diperbarui setelah menunggu transaksi bersamaan. Namun, keselamatan satu pembaruan tidak otomatis menjamin semua aturan pesanan yang melibatkan banyak baris.

LLM cukup meminta tindakan bisnis yang terbatas, misalnya mencoba membuat reservasi. Backend memeriksa kewenangan dan syaratnya, lalu mengembalikan hasil. Hindari menyerahkan kueri database bebas kepada agent hanya supaya integrasi terlihat fleksibel.

Persetujuan staf juga bisa kedaluwarsa

Persetujuan manusia sering dianggap penutup masalah. Padahal staf bisa menyetujui draf berdasarkan informasi yang sudah berubah saat tombol eksekusi ditekan. Persetujuan menjawab apakah tindakan diizinkan; validasi keadaan menjawab apakah tindakan masih dapat dilakukan.

Dalam rancangan penawaran, simpan dasar persetujuannya: produk, jumlah, harga, dan syarat relevan. Jika perubahan berikutnya mengubah nilai transaksi atau mengganti barang, jangan memakai persetujuan lama untuk tindakan yang berbeda. Tampilkan perubahan dan minta keputusan lagi sesuai kebijakan usaha.

Untuk perubahan stok yang membuat pesanan tidak mungkin dipenuhi, hentikan janji lama. Agent dapat menjelaskan bahwa ketersediaan berubah dan menawarkan langkah berikutnya yang memang diizinkan. Jangan menyisipkan substitusi produk tanpa pemberitahuan demi mengejar status sukses.

Aturan kedaluwarsa harus ditetapkan pemilik proses. Barang yang cepat terjual mungkin membutuhkan perlakuan berbeda dari jasa dengan jadwal tetap. Artikel ini tidak menetapkan angka menit universal karena batas yang masuk akal bergantung pada cara usaha bekerja.

Konflik data bukan alasan mengulang secara buta

Ketika pemeriksaan bersyarat menolak perubahan, sistem memperoleh informasi baru: asumsi awal tidak lagi cocok dengan keadaan tersimpan. Mengirim permintaan yang sama berulang kali tidak memperbaiki asumsi itu.

Alur yang lebih aman adalah membaca keadaan terbaru, menilai kembali apakah tujuan masih mungkin dipenuhi, lalu menentukan apakah perlu persetujuan baru. Batasi pengulangan dan bedakan konflik bisnis dari gangguan jaringan. Pesan “stok sudah berubah” memerlukan respons berbeda dari layanan yang sementara tidak dapat dihubungi.

Kunci idempotensi menyelesaikan masalah lain, yaitu menghubungkan percobaan ulang dengan operasi yang sama agar tidak menghasilkan tindakan ganda sesuai jaminan implementasinya. Ia tidak membuktikan bahwa stok yang dibaca sebelumnya masih tersedia. Kedua kendali bisa dibutuhkan bersamaan, tetapi tidak saling menggantikan.

Jika hasil penyimpanan belum diketahui akibat koneksi terputus, cari status operasi melalui mekanisme yang disediakan aplikasi sebelum menyatakan gagal atau mencoba membuat operasi baru. Kepastian harus berasal dari backend, bukan dari keyakinan model.

Uji dua pembeli, bukan hanya satu percakapan

Pengujian awal sebaiknya memakai data dummy dan lingkungan terpisah. Siapkan kasus ketika agent membaca persediaan, lalu transaksi lain mengurangi barang sebelum reservasi diminta. Hasil yang diharapkan adalah penolakan atau penyesuaian yang sesuai aturan, bukan stok negatif atau janji yang tetap dikirim.

Uji pula dua permintaan yang bersaing untuk unit terakhir, persetujuan yang terlambat, reservasi kedaluwarsa, dan koneksi yang putus setelah perubahan tersimpan. Periksa catatan backend serta pesan yang diterima pengguna. Jawaban yang sopan belum membuktikan transaksi benar.

Catat alasan penolakan dan jalur penanganannya tanpa memasukkan data pelanggan yang tidak diperlukan. Dari sana, pemilik usaha dapat melihat apakah kendalanya berasal dari data yang terlambat, definisi stok yang rancu, atau aturan reservasi yang belum lengkap.

Mulailah dari satu alur kecil: informasi stok dengan konteks yang jelas, lalu reservasi terbatas jika backend sudah mendukungnya. Sebelum memperluas otomatisasi, buktikan bahwa dua pelanggan tidak sama-sama menerima kepastian atas barang terakhir. Itu ukuran yang lebih berguna daripada seberapa lancar agent berbicara.

Sumber