Jawaban langsungnya: demo yang berhasil tidak membuktikan apa pun tentang keandalan agen AI, karena pertanyaan yang tepat bukanlah apakah agen menyelesaikan tugas sekali, melainkan apakah ia menyelesaikannya dengan benar setiap kali. Dalam studi yang diterbitkan Microsoft pada 20 Agustus 2026, model terkuat mencetak skor 65,36% ketika setiap tugas dijalankan sekali, tetapi lolos di kedua puluh percobaan hanya pada 25,25% tugas. Kesenjangan itu persis merupakan jarak antara agen yang membuat Anda terkesan dalam rapat dan agen yang dapat Anda percayai untuk mengelola data pelanggan.

Apa yang sebenarnya dibangun Microsoft

Alat ini bernama Thinkingbox, sebuah lingkungan pengujian open source yang dirilis di bawah lisensi MIT di GitHub. Idenya sederhana dan cerdas: alih-alih menghubungkan alat langsung ke agen, Anda mendefinisikannya sebagai server yang kompatibel dengan MCP, menjalankan agen di dalam sesi terisolasi dengan database pendukungnya sendiri, dan merekam jejak eksekusi secara lengkap.

Inti pentingnya ada pada cara penilaiannya. Framework ini tidak membaca apa yang dikatakan agen telah dilakukannya; framework ini memeriksa apa yang benar-benar berubah di database setelah tugas selesai. Perbedaan itu bukan detail teknis. Agen sangat pandai menulis ringkasan meyakinkan tentang pekerjaan yang tidak pernah terjadi, dan setiap evaluasi yang didasarkan pada transkrip percakapan mengukur kualitas tulisan, bukan kualitas eksekusi.

Di atas lingkungan tersebut, tim membangun benchmark bernama Thinkingbox-bench yang berisi 507 alur kerja yang dibatasi kebijakan di lima domain: ritel dan e-commerce, perjalanan dan perhotelan, asuransi kendaraan, dukungan TI internal di sebuah neobank, serta dukungan TI dan SDM di sebuah firma konsultan. Setiap tugas dijalankan dua puluh kali pada dua belas model, baik proprietary maupun open-weight.

Mengapa angka itu penting bagi pemilik bisnis

Bayangkan Anda menyerahkan tugas memproses permintaan retur di toko Anda kepada agen. Tingkat keberhasilan 65% terlihat dapat diterima di atas kertas. Secara operasional, artinya sepertiga permintaan berakhir dengan hasil yang salah: pengembalian dana yang diterbitkan dua kali, pesanan yang ditutup tanpa mengembalikan stok ke inventaris, atau pengecualian yang diberikan kepada pelanggan yang tidak diizinkan oleh kebijakan Anda.

Lebih buruk lagi, kegagalan dalam studi ini bukan crash yang kentara. Makalah tersebut secara eksplisit menggambarkan banyak kegagalan berakhir dengan rapi dan mengambil langkah-langkah yang tampak valid, sementara status akhir sistem tetap salah. Tidak ada pesan kesalahan, tidak ada penghentian, tidak ada yang menyala di dasbor pemantauan. Hanya log yang terbaca normal dan data yang diam-diam menjadi salah.

Kegagalan yang menghentikan sistem memang menjengkelkan, tetapi terlihat. Kegagalan yang menyelesaikan alur dan membuat data Anda salah adalah yang benar-benar merugikan, karena Anda baru menemukannya sebulan kemudian saat rekonsiliasi.

Hal ini juga menjelaskan sumber kekecewaan yang umum. Uji coba lolos karena uji coba menjalankan tugas sekali dengan data yang bersih. Operasional nyata adalah tugas yang sama ribuan kali di atas status yang menumpuk dan berantakan, dan di situlah perbedaan antara 65% dan 25% muncul.

Yang harus dilakukan sebelum mengadopsi agen apa pun

  • Tuntut eksekusi berulang, bukan satu demo. Jadikan dua puluh eksekusi berturut-turut atas tugas yang sama dengan data yang sama sebagai kriteria penerimaan Anda. Vendor yang menolak sedang memberi tahu Anda sesuatu.
  • Ukur status data, bukan teks balasan. Tentukan sejak awal seperti apa seharusnya catatan di database Anda setelah tugas selesai, lalu bandingkan kenyataannya dengan itu. Jangan puas hanya membaca ringkasan buatan agen sendiri.
  • Uji kebijakan, bukan hanya tugas mudah. Sebagian besar pekerjaan Anda tidak bersifat bebas; pekerjaan itu dibatasi aturan: batas waktu retur, limit kredit, pengecualian untuk pelanggan prioritas. Agen yang berhasil tanpa batasan bisa runtuh pada kondisi nyata pertama.
  • Bangun set pengujian dari kasus Anda sendiri. Ambil dua puluh kasus nyata dari beberapa bulan terakhir, termasuk kasus aneh yang membingungkan staf Anda, lalu jadikan rangkaian uji tetap yang Anda jalankan pada model apa pun sebelum mengadopsinya dan setelah setiap pembaruan.
  • Berikan wewenang secara bertahap. Mulailah dengan agen yang mengusulkan tetapi tidak mengeksekusi, lalu biarkan ia melakukan operasi berdampak rendah, kemudian perluas cakupannya seiring terkumpulnya catatan pengukuran yang nyata. Wewenang harus diraih dengan data, bukan dengan kesan.

Cara kami menanganinya di Origami

Saat kami membangun sistem yang menyertakan agen AI, kami memperlakukan agen seperti komponen perangkat lunak lainnya: agen mendapatkan rangkaian uji otomatis, pemeriksaan verifikasi yang memeriksa status database setelah setiap operasi, dan titik serah terima yang jelas kepada manusia saat ambang keyakinan terlampaui. Model itu sendiri tetap menjadi pengaturan yang dapat diganti, bukan sesuatu yang dilas ke dalam kode, karena model terbaik hari ini mungkin bukan yang terbaik tiga bulan dari sekarang.

Kesimpulan yang patut diambil dari studi ini bukanlah bahwa agen tidak dapat digunakan. Melainkan bahwa tolok ukur yang kita pakai untuk menilainya selama ini keliru. Agen saat ini adalah alat yang andal di dalam cakupan yang terdefinisi dengan baik dan terus diukur, dan sangat lemah ketika proses yang sensitif diserahkan kepadanya hanya berdasarkan demo yang meyakinkan. Perbedaannya bukan pada model; perbedaannya ada pada disiplin rekayasa di sekitarnya.

Sumber