Konteks, Bukan Kontrol
Setiap aturan dalam prompt agent Anda bermula dari sebuah bug.
Seseorang melihat perilaku yang buruk, menuliskan sebuah aturan, lalu melanjutkan pekerjaannya. Orang lain melakukan hal yang sama. Orang ketiga menambahkan "jangan pernah melakukan X" karena suatu kali, di hari Selasa, model melakukan sesuatu yang aneh. Tidak ada yang menghapus apa pun.
Enam bulan kemudian, agent 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 salah satu kesalahan desain terbesar yang dibuat tim saat membangun AI agent.
Contoh Kecil yang Mengungkap Pola yang Lebih Besar
Kami menemui masalah di mana sebuah agent yang dipicu oleh scheduled task terus-menerus membuat scheduled task baru dari dalam proses berjalannya. Rekursi tak terbatas, hanya saja dengan efek samping di dunia nyata.
Ada dua cara untuk meresponsnya.
Gaya kontrol: Larang. Tulis kode yang memblokir schedule agar tidak bisa membuat schedule. Tambahkan aturan prompt: "jangan pernah membuat schedule di dalam schedule." Rilis.
Gaya konteks: Beri tahu agent 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 yang sudah ditentukan dan pada awalnya diotorisasi oleh pengguna. Membuat scheduled task baru akan memperluas cakupan itu melampaui otorisasi awal.
Pendekatan pertama menambal satu perilaku. Pendekatan kedua memberi agent sebuah model atas situasinya.
Kini agent juga bisa menalar pertanyaan-pertanyaan terkait: Haruskah saya mengirim notifikasi pukul 3 pagi? Haruskah saya membuat proses lanjutan yang tidak diminta pengguna secara eksplisit? Haruskah saya mengubah sesuatu yang melampaui cakupan run aslinya?
Tidak perlu aturan. Agent itu memahaminya sendiri.
Banyak tim langsung meraih kontrol padahal yang sebenarnya mereka butuhkan adalah konteks.
Perbedaan yang Sama Muncul di Dalam Prompt
Ini bukan hanya soal penegakan di tingkat sistem. Pemisahan antara konteks dan kontrol juga ada di dalam prompt.
Prompting gaya konteks: sebagian besar fakta, sedikit opini:
Anda berjalan karena sebuah scheduled task. Dipicu pada pukul 3:00 pagi waktu Beijing. Task ID: sched_29x8f. Pengguna mengotorisasi run ini untuk cakupan tertentu.
Prompting gaya kontrol: penuh opini, bersifat preskriptif:
Hindari membuat schedule. Anda harus memberi tahu pengguna dengan tool X. Jangan pernah melakukan Y kecuali Z.
Terkadang instruksi preskriptif memang berguna. Tapi sangat sering instruksi itu hanya menutupi fakta yang hilang. Dan begitu Anda mulai menutupinya dengan cara itu, kebiasaan ini menjadi candu.
Bagaimana Prompt Berubah Menjadi Birokrasi
Inilah mode kegagalan yang lebih dalam.
Sebuah tim melihat satu masalah dan menambahkan sebuah aturan. Lalu satu lagi. Lalu satu lagi. Masing-masing menambal masalah lokal, tetapi bersama-sama mereka menciptakan sistem yang penuh dengan proxy.
Bezos menggambarkan pola ini dalam surat pemegang sahamnya tahun 2016: proses yang baik melayani Anda agar Anda bisa melayani pelanggan. Tapi jika Anda tidak berhati-hati, proses itu sendiri yang justru menjadi tujuannya.
Itulah persis yang terjadi dalam sistem agent.
Aturan bukanlah tujuannya. Aturan adalah proxy bagi hasil yang Anda inginkan. Dan proxy menumpuk. Satu proxy menciptakan kasus-kasus tepi yang membutuhkan lebih banyak lagi. Tak lama kemudian, agent menalar melewati lapisan-lapisan instruksi yang terakumulasi, masing-masing ditambahkan karena suatu alasan historis yang tak sepenuhnya diingat siapa pun.
Dalam organisasi manusia, ini menjadi birokrasi. Dalam sistem agent, ini menjadi prompt raksasa yang penuh jaringan parut.
Fakta Menua. Opini Membusuk.
Sebuah fakta seperti "run ini dipicu oleh scheduled task pada pukul 3 pagi" bersifat stabil. Fakta itu tetap benar tak peduli model mana yang membacanya: Claude, GPT, Gemini, atau apa pun yang dirilis kuartal berikutnya.
Sebuah pernyataan seperti "Anda sebaiknya menghindari pembuatan sub-schedule" itu rapuh. Pernyataan itu bergantung pada interpretasi. Ia mungkin membantu di satu situasi dan diam-diam meleset di situasi lain.
Saat Anda mengganti model, setiap opini dalam prompt Anda adalah ranjau yang berpotensi meledak. Model baru punya kecenderungan penalaran yang berbeda, dan kata "hindari" yang sudah Anda kalibrasi dengan cermat bisa berarti sesuatu yang sama sekali berbeda baginya.
Tapi fakta-fakta yang berlandasan 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 licik dari masalah kontrol: tim terus-menerus mengubah cacat model yang bersifat sementara menjadi struktur sistem yang permanen.
Sebuah model berperilaku buruk dalam suatu kasus sempit. Tim menambahkan sebuah guardrail: tambalan prompt, pemeriksaan kode, percabangan aneh yang hanya ada untuk menghentikan satu mode kegagalan tertentu.
Tambalan itu adalah taruhan bahwa keanehan tersebut akan bertahan. Hampir tidak pernah demikian.
Tiga bulan kemudian, model berubah. Perilaku aslinya menghilang. Tapi tambalannya tetap ada. Tidak ada yang mau menghapusnya, karena mungkin saja tambalan itu ada untuk suatu alasan.
Beginilah cara system prompt berubah menjadi legacy code.
Kita dengan mudah mengenali bahayanya saat dinyatakan secara abstrak. Tapi dalam praktiknya, menambal kecenderungan penalaran Sonnet yang berlaku saat ini di prompt demi prompt adalah pola yang sama dengan penyamaran.
Mendokumentasikan perilaku sistem yang stabil itu berharga. Menambal kecenderungan penalaran sebuah model itu seperti berlari di atas treadmill. Model akan berubah di bawah Anda lebih cepat daripada kemampuan Anda merawat tambalan-tambalan itu.
Kasus Uji yang Baik: Permission Denied
Anda bisa melihat perbedaannya dengan jelas dalam diagnostik tool. Saat sebuah agent menemui permission error:
Gaya kontrol:
TOKEN tidak ada. Jalankan "zero permissions request gmail.send" untuk memperbaikinya.
Langsung, tapi agent tidak belajar apa-apa. Lain kali ia menemui permission error yang berbeda, ia akan mentok.
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 agent tahu bahwa token-nya ada, connector-nya bekerja, dan izin yang spesifik itu ditolak. Ia memahami keadaan sistem dan bisa menalar situasi-situasi baru yang tidak pernah diantisipasi oleh penulis aturan.
Heuristiknya
Inilah yang terus saya pegang:
Setiap kali Anda hendak menulis "jangan," "hindari," atau "jangan pernah" dalam sebuah prompt. Berhenti. Tanyakan: fakta apa yang sedang ditutupi oleh aturan ini?
Biasanya ada sebuah fakta yang hilang. Agent tidak memahami lingkungan tempatnya berada, apa yang diotorisasi pengguna, tindakan mana yang tidak bisa dibatalkan, atau mengapa run ini berbeda dari interaksi chat biasa.
Tuliskan fakta itu. Hapus aturannya.
Terkadang Anda tetap menginginkan batasan tersebut, terutama di sekitar tindakan destruktif, perpindahan uang, atau batas keamanan. Kontrol yang tegas tetap penting.
Tapi banyak aturan prompt bukanlah batasan sejati. Aturan-aturan itu hanya kompensasi atas pemahaman yang hilang. Dan justru aturan-aturan itulah yang menumpuk dan membusuk.
Tujuannya
Tujuannya bukan agent yang menghafal daftar periksa.
Tujuannya adalah agent yang memahami situasinya dengan cukup baik untuk membuat keputusan yang baik di dalam batasan yang jelas.
Satu filosofi mengendalikan perilaku dengan menumpuk aturan. Yang lainnya memperbaiki perilaku dengan membuat dunia menjadi mudah dibaca.
Yang pertama cenderung menuju birokrasi. Yang kedua cenderung menuju pemahaman.
Bangun konteks. Hapus jaringan parutnya. Rilis agent yang bisa berpikir.
