Konteks, Bukan Kontrol
Setiap aturan dalam prompt agen Anda bermula dari sebuah bug.
Seseorang melihat perilaku buruk, menulis sebuah aturan, lalu melanjutkan pekerjaannya. Orang lain melakukan hal yang sama. Orang ketiga menambahkan aturan "jangan pernah melakukan X" karena suatu kali pada hari Selasa model itu melakukan sesuatu yang aneh. Tidak ada yang menghapus apa pun.
Enam bulan kemudian, agen itu menghabiskan lebih banyak context window-nya untuk menavigasi buku aturannya sendiri daripada memikirkan tugas yang sebenarnya.
Itulah cara berpikir bergaya kontrol. Dan menurut saya, itu adalah salah satu kesalahan desain terbesar yang dilakukan tim saat membangun agen AI.
Contoh Kecil yang Mengungkap Pola yang Lebih Besar
Kami pernah menemui masalah di mana sebuah agen yang dipicu oleh scheduled task terus-menerus membuat scheduled task baru dari dalam proses berjalannya. Rekursi tak terhingga, hanya saja dengan efek samping di dunia nyata.
Ada dua cara untuk merespons.
Gaya kontrol: Larang saja. Tulis kode yang memblokir jadwal agar tidak membuat jadwal lain. Tambahkan aturan prompt: "jangan pernah membuat jadwal di dalam sebuah jadwal." Rilis.
Gaya konteks: Beri tahu agen apa yang sebenarnya sedang terjadi.
Anda dipicu oleh sebuah scheduled task pada pukul 3:00 pagi waktu Pasifik. Schedule ID: sched_29x8f. Sebuah scheduled run adalah eksekusi terisolasi dengan cakupan terdefinisi yang awalnya diizinkan oleh pengguna. Membuat scheduled task baru akan memperluas cakupan itu melampaui otorisasi aslinya.
Pendekatan pertama menambal satu perilaku. Pendekatan kedua memberi agen sebuah model dari situasinya.
Sekarang agen itu juga bisa bernalar tentang pertanyaan-pertanyaan terkait: Haruskah saya mengirim notifikasi pada pukul 3 pagi? Haruskah saya membuat proses tindak lanjut yang tidak secara eksplisit diminta pengguna? Haruskah saya mengubah sesuatu yang melampaui cakupan proses berjalan aslinya?
Tidak perlu aturan. Agen itu menemukan jawabannya sendiri.
Banyak tim meraih kontrol padahal yang sebenarnya mereka butuhkan adalah konteks.
Pembedaan yang Sama Muncul di Dalam Prompt
Ini bukan hanya soal penegakan di tingkat sistem. Pembedaan antara konteks dan kontrol juga ada di dalam prompt.
Prompting bergaya konteks: sebagian besar fakta, opini seminimal mungkin:
Anda berjalan karena sebuah scheduled task. Dipicu pada pukul 3:00 pagi waktu Beijing. Task ID: sched_29x8f. Pengguna mengizinkan proses berjalan ini untuk cakupan tertentu.
Prompting bergaya kontrol: penuh opini, bersifat preskriptif:
Hindari membuat jadwal. Anda harus memberi tahu pengguna dengan tool X. Jangan pernah melakukan Y kecuali Z.
Kadang instruksi preskriptif memang berguna. Tapi sering kali instruksi itu hanyalah kompensasi atas fakta yang hilang. Dan begitu Anda mulai melakukan kompensasi dengan cara itu, kebiasaan ini menjadi adiktif.
Bagaimana Prompt Berubah Menjadi Birokrasi
Inilah mode kegagalan yang lebih dalam.
Sebuah tim melihat sebuah masalah dan menambahkan aturan. Lalu satu lagi. Lalu satu lagi. Masing-masing menambal masalah lokal, tetapi secara bersama-sama mereka menciptakan sistem yang penuh dengan proxy.
Bezos menggambarkan pola ini dalam surat kepada pemegang sahamnya pada tahun 2016: proses yang baik melayani Anda agar Anda bisa melayani pelanggan. Tapi jika Anda tidak berhati-hati, proses itu sendiri yang menjadi tujuan.
Itulah yang persis terjadi dalam sistem agen.
Aturan bukanlah tujuannya. Aturan hanyalah proxy untuk hasil yang Anda inginkan. Dan proxy itu menumpuk. Satu proxy menciptakan kasus tepi (edge case) yang membutuhkan proxy lainnya. Tak lama kemudian agen itu bernalar melalui lapisan-lapisan instruksi yang menumpuk, masing-masing ditambahkan karena suatu alasan historis yang tak seorang pun benar-benar mengingatnya.
Dalam organisasi manusia, ini menjadi birokrasi. Dalam sistem agen, ini menjadi prompt raksasa yang penuh dengan jaringan parut.
Fakta Menua. Opini Membusuk.
Sebuah fakta seperti "proses berjalan ini dipicu oleh sebuah scheduled task pada pukul 3 pagi" bersifat stabil. Fakta itu tetap benar terlepas dari model mana yang membacanya: Claude, GPT, Gemini, atau apa pun yang dirilis kuartal depan.
Sebuah pernyataan seperti "Anda sebaiknya menghindari membuat sub-jadwal" bersifat rapuh. Pernyataan itu bergantung pada interpretasi. Ia mungkin membantu dalam satu situasi dan diam-diam keliru dalam situasi lain.
Saat Anda mengganti model, setiap opini dalam prompt Anda adalah potensi ranjau darat. Model baru memiliki kecenderungan penalaran yang berbeda, dan kata "hindari" yang sudah Anda kalibrasi dengan cermat bisa jadi berarti sesuatu yang sama sekali berbeda baginya.
Tetapi fakta-fakta yang berlandaskan kenyataan tentang lingkungan, izin, cakupan, dan batasan cenderung dapat digeneralisasi lintas model dan kasus tepi. Itulah sebabnya fakta adalah bahan bangunan yang lebih baik.
Jebakan Keanehan Model
Ini mungkin versi paling berbahaya dari masalah kontrol: tim terus-menerus mengubah cacat model yang sementara menjadi struktur sistem yang permanen.
Sebuah model berperilaku buruk dalam suatu kasus yang sempit. Tim menambahkan pengaman: sebuah tambalan prompt, sebuah pemeriksaan kode, sebuah cabang aneh yang hanya ada untuk menghentikan satu mode kegagalan tertentu.
Tambalan itu adalah taruhan bahwa keanehan itu akan bertahan. Hampir tidak pernah demikian.
Tiga bulan kemudian, model berubah. Perilaku aslinya menghilang. Tapi tambalannya tetap ada. Tidak ada yang ingin menghapusnya, karena mungkin tambalan itu ada untuk suatu alasan.
Beginilah cara system prompt berubah menjadi legacy code.
Kita bisa dengan mudah mengenali bahayanya ketika dinyatakan secara abstrak. Tapi dalam praktiknya, menambal kecenderungan penalaran Sonnet saat ini di prompt demi prompt adalah pola yang sama dalam penyamaran.
Mendokumentasikan perilaku sistem yang stabil itu berharga. Menambal kecenderungan penalaran sebuah model adalah treadmill yang tak ada habisnya. Model akan berubah di bawah kaki Anda lebih cepat daripada kemampuan Anda memelihara tambalan-tambalan itu.
Sebuah Studi Kasus yang Baik: Permission Denied
Anda bisa melihat pembedaan ini dengan jelas dalam diagnostik tool. Ketika sebuah agen menemui permission error:
Gaya kontrol:
TOKEN tidak ada. Jalankan "zero permissions request gmail.send" untuk memperbaikinya.
Langsung, tapi agen tidak belajar apa-apa. Lain kali ketika ia menemui permission error yang berbeda, ia akan buntu.
Gaya konteks:
process.env.GMAIL_TOKEN → ada zero connectors inspect gmail → terhubung zero permissions inspect gmail.send → ditolak
Opsi:
- Minta persetujuan pengguna untuk gmail.send
- Gunakan jalur yang sudah diotorisasi jika ada
Kini agen tahu bahwa token-nya ada, connector-nya berfungsi, dan izin spesifik itu ditolak. Ia memahami keadaan sistem dan bisa bernalar tentang situasi-situasi baru yang tak pernah diantisipasi oleh si penulis aturan.
Heuristiknya
Inilah hal yang terus saya pikirkan:
Setiap kali Anda hendak menulis "jangan," "hindari," atau "jangan pernah" dalam sebuah prompt. Berhentilah. Tanyakan: fakta apa yang sedang dikompensasi oleh aturan ini?
Biasanya ada fakta yang hilang. Agen tidak memahami lingkungan apa yang sedang ia tempati, apa yang diizinkan pengguna, tindakan mana yang tidak dapat dibatalkan, atau mengapa proses berjalan ini berbeda dari interaksi obrolan biasa.
Tuliskan fakta itu. Hapus aturannya.
Kadang Anda tetap menginginkan batasan itu, terutama di sekitar tindakan yang merusak, perpindahan uang, atau batas-batas keamanan. Kontrol yang tegas tetap penting.
Tapi banyak aturan prompt yang bukan merupakan batasan sejati. Aturan-aturan itu adalah kompensasi atas pemahaman yang hilang. Dan justru itulah jenis aturan yang menumpuk dan membusuk.
Tujuannya
Tujuannya bukanlah agen yang menghafal sebuah daftar periksa.
Tujuannya adalah agen yang memahami situasinya dengan cukup baik untuk membuat keputusan yang baik di dalam batasan yang jelas.
Satu filosofi mengendalikan perilaku dengan menumpuk aturan. Yang lain memperbaiki perilaku dengan membuat dunia menjadi mudah dipahami.
Yang pertama cenderung menuju birokrasi. Yang kedua cenderung menuju pemahaman.
Bangun konteks. Hapus jaringan parutnya. Rilis agen yang bisa berpikir.
