Agent Bilang Beres, Databasenya Bilang Belum

Agent customer service kalian bisa kelihatan sempurna — sembilan tool call rapi, jawaban sopan, tiket ditutup — padahal paket pelanggan masih nyangkut di gudang dan belum ada yang beresin. Itu bukan skenario rekaan, itu temuan dari riset ThinkingBox yang baru dirilis bareng oleh Microsoft dan Hugging Face.

Apa yang baru

• ThinkingBox adalah framework evaluasi baru yang nilai agent AI bukan dari jawaban akhirnya, tapi dari kondisi database dan efek samping yang ditinggalkan di backend setelah agent selesai kerja — mirip kayak ngecek tiket order di dapur restoran, bukan cuma dengerin pelayan bilang "pesanannya udah masuk."
• Gap antara keliatan beres dan beneran beres itu lebar: dari 121.680 percobaan valid di 12 model LLM, 79.853 di antaranya gagal lolos pengecekan kondisi akhir (executable checks).
• 67,24% dari kegagalan itu tetap keliatan mulus — proses berhenti bersih, tool pengubah data terpanggil, dan sistem gak lapor error apa pun.
• 77,61% dari kegagalan itu ninggalin nilai field yang salah, 43,30% bikin efek samping yang gak diminta, dan 25,36% malah lupa ngejalanin efek yang wajib ada.
• 20 kali percobaan berulang dijalanin buat tiap satu dari 507 tugas bisnis, dari kondisi backend yang identik persis — buat ngukur konsistensi, bukan cuma sekali coba lalu diklaim berhasil.

Kenapa ini penting

Kalau kalian lagi bangun agent buat customer service atau automasi workflow, riset ini nunjukin blind spot yang gampang kelewat: tes yang cuma ngecek "apakah agent manggil tool yang benar" atau "apakah jawabannya sopan" itu gak cukup. Agent yang nyasar ke Wiki Jerman selama sebulan tanpa ketahuan itu contoh lain dari pola yang sama — proses jalan mulus di permukaan, tapi hasil akhirnya salah total dan gak ada yang sadar sampai lama.

Yang bikin ini lebih genting buat tim kecil: kesenjangan kemampuan antar model gede banget tergantung domain. Claude Opus 4.6 misalnya skor 68,62% di tugas retail tapi anjlok ke 8,30% di tugas asuransi mobil — model yang sama, konteks beda, hasil jomplang. Kalau kalian pilih satu model buat semua use case tanpa ngetes tiap alur kerja secara terpisah, kalian bisa nganggep agent itu reliable padahal cuma kebetulan cocok di satu skenario yang kalian test doang.

Ini juga alasan kenapa testing sebelum production harus ngecek kondisi akhir di database, bukan cuma transcript percakapan. Tiket yang ditandai "resolved" padahal sebenarnya belum resolved itu bisa lolos review manual kalau reviewer cuma baca jawabannya doang.

Buat kalian

• Yang harus peduli: kalian yang udah atau lagi bangun agent buat ubah data pelanggan, refund, atau tiket support — di mana kesalahan baru ketahuan pas pelanggan komplain lagi.
• Yang boleh santai: kalau agent kalian cuma buat nanya-jawab info (FAQ, pencarian dokumen) tanpa nulis apa pun ke database, risiko state-nya jauh lebih kecil.
• Langkah kecil pertama: sebelum agent kalian ke production, bikin satu test case yang ngecek kondisi database SETELAH agent selesai kerja — bukan cuma transcript-nya. Jalanin tugas yang sama minimal 5-10 kali dari kondisi awal yang identik, terus liat berapa kali hasil akhirnya beneran benar.

Masalah yang diungkap ThinkingBox sebenarnya bukan soal AI-nya pintar atau enggak — ini soal kalian percaya pada apa. Transcript yang rapi itu gampang bikin orang lengah, padahal satu-satunya bukti yang gak bisa bohong adalah apa yang beneran ketulis di sistem. Prinsip ini yang gw tekenin ke murid-murid tiap kali mereka mulai nyambungin agent ke sistem produksi beneran, di kelas gw.

Sumber primer: blog resmi Microsoft dan Hugging Face (huggingface.co/blog/microsoft/thinkingbox).