Merancang AI Agent yang Siap Production

Demo AI agent biasanya terlihat meyakinkan: pengguna bertanya, model menjawab, lalu sebuah tool dipanggil. Tantangan sebenarnya baru muncul ketika agent dipakai oleh banyak pengguna, terhubung ke data nyata, dan diberi izin untuk melakukan tindakan.

Di production, kualitas agent tidak hanya ditentukan oleh seberapa pintar modelnya. Sistem juga harus dapat diprediksi, diamati, dan dihentikan ketika sesuatu berjalan tidak sesuai rencana.

Mulai dari kontrak, bukan prompt

Prompt penting, tetapi kontrak antar-komponen lebih penting. Setiap tool sebaiknya memiliki:

• Nama dan tujuan yang spesifik
• Input schema yang ketat
• Output yang konsisten
• Batas izin yang jelas
• Pesan error yang bisa ditindaklanjuti

Tool bernama manage_course terlalu luas. Memisahkannya menjadi get_course, search_course_materials, dan submit_course_feedback membuat intent lebih mudah dipahami dan hak akses lebih mudah dibatasi.

type SearchCourseMaterialsInput = {
  courseId: string;
  query: string;
  limit?: number;
};

type SearchCourseMaterialsResult = {
  items: Array<{
    id: string;
    title: string;
    excerpt: string;
  }>;
};

Schema seperti ini bukan sekadar bantuan untuk model. Ia adalah batas sistem yang dapat divalidasi, diuji, dan didokumentasikan.

Pisahkan keputusan dari eksekusi

Agent sebaiknya tidak langsung mengeksekusi semua keputusan yang dihasilkan model. Gunakan lapisan orchestrator di antara model dan layanan aplikasi:

1. Model memilih tool dan menyusun argumen.
2. Orchestrator memvalidasi schema, identitas, serta izin pengguna.
3. Policy layer menentukan apakah tindakan boleh dilanjutkan.
4. Service menjalankan operasi dan mengembalikan hasil terstruktur.
5. Model menyusun jawaban berdasarkan hasil tersebut.

Pemisahan ini membuat business rules tetap berada di aplikasi. Model boleh mengusulkan tindakan, tetapi aplikasi tetap menjadi sumber kebenaran.

Bedakan operasi baca dan tulis

Tidak semua tool memiliki risiko yang sama. Pencarian materi memiliki dampak berbeda dari mengubah nilai, mengirim pesan, atau menghapus data.

Saya biasanya membagi tool menjadi tiga tingkat:

Tingkat	Contoh	Perlindungan
Read	Mencari materi	Otorisasi dan rate limit
Write	Menyimpan preferensi	Validasi dan audit log
Sensitive	Menghapus atau mengirim	Konfirmasi eksplisit pengguna

Untuk operasi sensitif, agent sebaiknya menampilkan ringkasan tindakan sebelum eksekusi. Pengguna perlu mengetahui apa yang akan berubah, bukan sekadar melihat tombol konfirmasi tanpa konteks.

Context harus relevan, bukan sebanyak mungkin

Memasukkan seluruh riwayat percakapan dan semua dokumen ke prompt terlihat praktis, tetapi cepat menjadi mahal dan membingungkan. Context yang baik dipilih berdasarkan kebutuhan saat itu.

Beberapa strategi yang lebih sehat:

• Simpan identitas dan izin di luar prompt
• Ringkas percakapan lama menjadi state terstruktur
• Ambil dokumen hanya ketika dibutuhkan
• Sertakan sumber agar jawaban dapat diperiksa
• Batasi data berdasarkan tenant dan hak akses pengguna

Tujuannya bukan memberi model semua informasi. Tujuannya memberi informasi minimum yang cukup untuk mengambil keputusan dengan benar.

Observability adalah bagian dari fitur

Ketika agent gagal, log something went wrong hampir tidak berguna. Catat alur keputusan tanpa menyimpan data sensitif secara sembarangan:

• Model dan versi prompt
• Tool yang dipilih
• Durasi setiap tahap
• Hasil validasi dan policy check
• Token usage dan estimasi biaya
• Error category, retry, dan fallback

Gunakan correlation ID agar satu percakapan dapat ditelusuri dari request pengguna hingga panggilan service. Dengan itu, tim dapat membedakan apakah masalah berasal dari retrieval, model, schema, otorisasi, atau layanan downstream.

Uji perilaku, bukan hanya fungsi

Unit test untuk validator dan service tetap diperlukan. Namun AI agent juga membutuhkan sekumpulan skenario evaluasi yang stabil, misalnya:

• Pertanyaan ambigu harus memicu klarifikasi
• Pengguna tanpa izin tidak boleh mengakses data tertentu
• Tool tidak boleh dipanggil jika informasi wajib belum tersedia
• Jawaban harus menyebutkan sumber saat menggunakan retrieval
• Kegagalan service harus menghasilkan respons yang jujur

Jalankan evaluasi tersebut setiap kali prompt, model, schema, atau retrieval pipeline berubah. Prompt adalah bagian dari software dan perlu diperlakukan seperti kode yang dapat mengalami regresi.

Kesimpulan

AI agent yang siap production bukan chatbot dengan prompt yang lebih panjang. Ia adalah sistem terdistribusi kecil yang memiliki input tidak deterministik.

Kualitasnya datang dari kontrak yang ketat, izin yang terbatas, context yang relevan, observability, dan evaluasi berulang. Model memberi kemampuan bernalar, tetapi arsitektur yang disiplin membuat kemampuan itu aman untuk digunakan.