Prompt Panjang Tidak Membuat Agent Lebih Pintar

Gue pernah punya prompt agent yang panjangnya seperti README proyek. Semua aturan dimasukkan: gaya bahasa, pengecualian, format, daftar larangan, dan instruksi untuk tidak lupa instruksi sebelumnya. Agent tetap salah—hanya sekarang salahnya ditulis lebih rapi.

Prompt panjang bukan desain sistem. Ia sering menjadi tempat kita menumpuk keputusan yang seharusnya dipindahkan ke tool, schema, atau kode.

Context bukan memori sempurna

Model dapat membaca banyak token, tetapi bukan berarti semua token diberi bobot yang sama. Instruksi yang bertabrakan, contoh yang terlalu banyak, dan konteks yang tidak relevan membuat perilaku sulit diprediksi. Menambah paragraf tidak memperbaiki konflik.

Mulai dengan kontrak kecil: tujuan agent, batas akses, format output, dan kondisi untuk berhenti. Jika agent harus mengambil data, berikan tool dengan parameter terstruktur. Jangan meminta model “ingat untuk selalu memvalidasi” jika validasi bisa dilakukan oleh server.

Ukur, jangan mengagumi prompt

Buat dataset kasus nyata: input ambigu, data kosong, permission ditolak, tool gagal, dan permintaan berbahaya. Jalankan setiap perubahan prompt terhadap dataset yang sama. Ukur akurasi, tool-call yang benar, latency, biaya, dan kapan agent memilih abstain.

Agent yang baik bukan yang selalu menjawab. Ia tahu kapan harus meminta klarifikasi, mengembalikan error yang jelas, atau menyerahkan keputusan kepada manusia.

Prompt tetap penting, tetapi prompt adalah interface kebijakan—bukan pengganti arsitektur. Kalau satu paragraf baru dapat merusak seluruh perilaku, sistem itu belum memiliki batas yang cukup kuat.

---

Pindahkan aturan dari prompt ke sistem

Kalau agent harus selalu mengembalikan JSON valid, schema validator harus menolak output yang rusak. Kalau agent hanya boleh membaca invoice milik pengguna yang sedang login, permission harus diperiksa di server. Kalau tool hanya boleh dipanggil setelah konfirmasi, buat approval step yang bisa diaudit.

Prompt tetap dibutuhkan untuk menjelaskan tujuan dan gaya komunikasi, tetapi jangan menjadikannya satu-satunya pagar. Model bisa salah memahami kalimat, konteks bisa terpotong, dan tool bisa gagal. Batas penting harus ditegakkan oleh kode.

Saya juga memisahkan instruksi berdasarkan sumbernya: policy yang stabil, konteks request, hasil tool, dan contoh. Pemisahan ini memudahkan evaluasi ketika perilaku berubah. Jangan mencampur data pengguna dengan instruksi sistem tanpa delimiter dan validasi.

Untuk mengevaluasi agent, simpan trace tool call, input yang dipakai, hasilnya, dan keputusan akhir. Redact data sensitif sebelum trace disimpan. Satu demo sukses tidak cukup; jalankan kasus ambigu, permission denied, timeout, prompt injection, dan permintaan di luar scope.

Prompt yang ringkas bukan tujuan. Tujuannya adalah sistem yang bisa dijelaskan, diuji, dan gagal dengan aman.

---

Sumber

• https://platform.openai.com/docs/guides/prompt-engineering
• https://www.anthropic.com/research/building-effective-agents
• https://www.nist.gov/itl/ai-risk-management-framework