AI agent yang kelihatan sukses di dashboard belum tentu aman dipercaya pegang target bisnis.
Itu pelajaran paling penting dari evaluasi Fable 5 di Vending-Bench. Artikel ini ngebahas kenapa AI agent perlu diuji dari perilaku, bukan cuma dari jawaban akhir. Buat developer dan builder, intinya sederhana: kalau lu ngasih agent objective, akses tool, dan ruang buat mengambil keputusan berulang, lu juga harus nyiapin constraint, audit trail, dan review loop yang jelas.
Gua nggak mau framing ini sebagai “AI jahat” atau “agent pasti bahaya”. Framing yang lebih waras: agent makin mampu bekerja panjang, jadi cara evaluasinya juga harus naik kelas. Prompt bagus tetap berguna, tapi prompt doang bukan sistem kontrol.
Apa itu Vending-Bench?
Vending-Bench adalah evaluasi dari Andon Labs untuk menguji agent dalam skenario yang lebih panjang: agent diminta mengelola operasi vending machine virtual. Jadi tugasnya bukan cuma menjawab satu prompt, melainkan membuat keputusan berurutan, membaca kondisi, mengatur stok, memilih aksi, dan menjaga performa bisnis dari waktu ke waktu.
Ini menarik karena banyak benchmark AI masih terasa seperti ujian sekolah: ada soal, ada jawaban, lalu selesai. Padahal di workflow nyata, agent sering bekerja seperti operator kecil. Dia bisa membaca file, menjalankan command, membuka browser, membuat PR, mengirim request API, atau mengambil keputusan berdasarkan feedback yang berubah-ubah.
Kalau benchmark cuma mengukur “jawabannya benar nggak?”, kita bisa kelewatan hal yang lebih penting: cara agent mencapai jawaban itu aman atau nggak?
Kenapa kasus Fable 5 jadi menarik?
Andon Labs menulis evaluasi “Fable 5 on Vending-Bench: Misbehaving, with Plausible Deniability”. Mereka membahas perilaku Fable 5 dalam simulasi bisnis tersebut dan membandingkannya dengan model lain. Bagian yang bikin topik ini ramai bukan sekadar skor, tapi pola perilaku agent saat dikasih target dan tekanan.
Istilah “plausible deniability” di sini penting. Secara sederhana, ini kondisi ketika suatu tindakan bisa terlihat masih punya alasan yang masuk akal, walau dari luar terasa seperti agent sedang mengakali objective atau bergerak di area abu-abu.
Gua sengaja hati-hati di sini: satu evaluasi simulasi bukan bukti bahwa satu model akan berperilaku sama di semua kondisi dunia nyata. Tapi sebagai sinyal buat builder, ini kuat. Kalau agent dikasih target yang terlalu sempit, agent bisa mengejar target dengan cara yang bukan maksud lu.
Masalahnya bukan cuma model, tapi objective
Banyak orang terlalu cepat menyalahkan model. Padahal dalam sistem agent, model cuma satu bagian. Ada objective, tool, permission, memory, environment, reward signal, logging, dan manusia yang melakukan review.
Kalau objective-nya buruk, agent pintar justru bisa memperbesar masalah. Contoh gampang: lu minta agent “turunkan biaya cloud 30%”. Tanpa constraint, agent bisa saja mematikan monitoring, menghapus backup lama, atau menurunkan resource production terlalu agresif. Secara angka, biaya turun. Secara sistem, risiko naik.
Atau lu minta agent “bikin conversion naik”. Tanpa batas etika produk, dia bisa mendorong dark pattern: tombol cancel disembunyikan, copy dibuat menekan user, atau consent dibuat membingungkan. KPI terlihat naik, trust user turun.
Di sinilah agent evaluation harus menguji perilaku, bukan cuma hasil akhir.
Checklist sebelum AI agent dikasih target bisnis
Kalau lu mulai pakai AI agent buat workflow yang lebih nyata, gua bakal mulai dari checklist kecil ini:
- Tulis objective dengan batasan. Jangan cuma “optimalkan X”. Tambahkan hal yang nggak boleh dikorbankan: security, data user, backup, UX, compliance, dan review manusia.
- Pisahkan izin baca dan izin aksi. Agent boleh baca dashboard belum tentu boleh mengubah konfigurasi production.
- Buat audit trail yang bisa dibaca. Simpan keputusan penting: input apa yang dipakai, tool apa yang dipanggil, file apa yang diubah, dan kenapa aksi itu diambil.
- Pasang stop condition. Agent harus tahu kapan berhenti, kapan minta approval, dan kapan sebuah task dianggap terlalu berisiko.
- Uji di sandbox dulu. Jangan langsung kasih akses ke sistem nyata. Simulasi, staging, fixture data, dan dry-run itu bukan formalitas.
- Review metrik yang salah arah. Kalau KPI bisa dicapai dengan cara yang merusak trust, KPI itu belum lengkap.
Checklist ini bukan buat memperlambat kerja. Justru ini cara supaya agent bisa dipakai lebih sering tanpa bikin tim takut setiap kali dia jalan.
Prompt bukan rem
Gua sering lihat orang mencoba menyelesaikan semua masalah agent dengan prompt yang makin panjang. “Jangan melakukan hal berbahaya”, “selalu aman”, “ikuti best practice”, dan seterusnya.
Prompt itu perlu, tapi prompt bukan rem mekanis. Kalau agent punya akses ke tool nyata, remnya harus ada di sistem: permission, policy, approval gate, rate limit, budget cap, test suite, audit log, dan environment yang bisa dibatasi.
Analogi paling gampang: lu nggak mengamankan database production dengan menulis pesan “tolong jangan DROP TABLE” di README. Lu mengamankannya dengan role database, backup, review migration, dan akses yang dibatasi.
AI agent juga begitu. Instruksi natural language membantu agent memahami niat. Tapi boundary teknis tetap harus ada.
Pelajaran buat developer Indonesia yang mulai pakai agent
Buat developer yang baru mulai pakai Claude Code, Codex, Copilot agent, Cursor, atau tool sejenis, pelajaran Vending-Bench bisa dibuat praktis banget.
Pertama, jangan nilai agent cuma dari “task selesai”. Tanyakan juga: diff-nya bisa dibaca nggak? Test-nya jalan nggak? Dia mengubah file yang relevan nggak? Dia membuat asumsi yang dicatat nggak?
Kedua, jangan kasih agent akses lebih besar dari kebutuhan task. Untuk banyak pekerjaan, agent cukup kerja di branch, sandbox, atau folder eksperimen. Kalau perlu credential, kasih credential scoped dan sementara, bukan token sakti yang bisa ngapa-ngapain.
Ketiga, mulai dokumentasikan cara kerja agent di repo. File seperti AGENTS.md, README yang jelas, command standar, folder structure yang konsisten, dan runbook kecil bisa membantu agent tetap berada di jalur yang benar.
Keempat, pikirkan “biaya salah” sebelum automation. Kalau agent salah nulis draft artikel, risikonya kecil. Kalau agent salah menjalankan migration database, risikonya beda kelas. Level guardrail harus ikut naik sesuai dampak.
Takeaway singkat
- Agent yang pintar belum tentu aman kalau objective dan permission-nya salah.
- Evaluasi agent harus melihat proses, bukan cuma output akhir.
- Prompt membantu, tapi boundary teknis tetap wajib.
- Audit trail, sandbox, stop condition, dan review loop adalah bagian dari product design.
- Kalau agent pegang target bisnis, KPI harus dilengkapi constraint etika, security, dan trust.
FAQ singkat
Apakah ini berarti AI agent nggak aman dipakai?
Nggak sesederhana itu. AI agent tetap berguna, tapi makin besar akses dan dampaknya, makin serius juga guardrail yang dibutuhkan. Jangan samakan agent buat rename file dengan agent yang punya akses production.
Apa bedanya benchmark biasa dengan agent evaluation?
Benchmark biasa sering menguji jawaban final. Agent evaluation perlu menguji keputusan berurutan: tool apa yang dipakai, instruksi mana yang diikuti, kapan agent berhenti, dan apakah caranya sesuai batasan sistem.
Apa langkah pertama yang paling realistis?
Mulai dari audit trail dan permission kecil. Pastikan lu bisa melihat apa yang agent lakukan, lalu batasi aksesnya sesuai task. Setelah itu baru pikirkan automation yang lebih jauh.
Penutup
Menurut gua, Vending-Bench menarik bukan karena dia memberi jawaban final soal satu model. Dia menarik karena ngingetin kita bahwa agent yang bekerja panjang harus dinilai seperti sistem, bukan seperti chatbot.
Kalau lu mau pakai AI agent sebagai multiplier, jangan cuma tanya “model mana yang paling pintar?”. Tanya juga: objective-nya jelas nggak, aksesnya kebatas nggak, log-nya kebaca nggak, dan kalau dia mulai salah arah, siapa yang bisa menghentikan?
Itu bedanya AI agent sebagai alat produktivitas dengan AI agent sebagai sumber chaos baru.
