Pengembangan AI agent yang bertahan di produksi

Pengembangan AI agent berarti membangun perangkat lunak di mana sebuah model bahasa memutuskan langkah apa yang diambil, memanggil alat nyata untuk mengambilnya, membaca hasilnya, lalu memutuskan lagi — sampai tujuan tercapai atau sebuah batas menghentikannya. Produknya bukan model, melainkan lingkar di sekitarnya. Di situlah engineering-nya: apa yang boleh dipanggil agent, bagaimana kegagalan kembali kepadanya, bagaimana state dibawa antar langkah, apa yang terjadi saat ia melenceng, dan bagaimana Anda tahu setelahnya apakah pekerjaannya beres. Chatbot menjawab. Agent bertindak — dan tindakan itulah yang menjadikannya proyek perangkat lunak, bukan sekadar prompt.

Prototipe yang jalan untuk satu tugas sempit biasanya butuh satu sampai tiga minggu. Membawa prototipe itu ke kondisi yang berani Anda tunjukkan ke pelanggan jauh lebih lama — umumnya dua sampai empat bulan — dan hampir tidak ada waktu itu yang habis untuk prompt. Waktunya habis di integrasi yang gagal dengan cara yang harus ditangani model, di set evaluasi yang menangkap regresi, di izin akses, di log yang bisa dipakai men-debug, dan di jalur serah terima ke manusia untuk kasus yang tidak boleh diputuskan agent sendirian. Tim yang menganggarkan demo tapi tidak fase kedua adalah tim yang agent-nya tak pernah lulus dari pilot.

Mulailah dari yang paling ringan yang menyelesaikan tugas. Untuk satu agent dengan segelintir alat, SDK penyedia model plus lingkar yang Anda tulis sendiri sering kali sudah seluruh pekerjaannya, dan Anda tetap bisa men-debug setiap langkah. Ambil framework orkestrasi ketika Anda benar-benar butuh state yang tahan lama, alur kendali bercabang, percobaan ulang pada langkah panjang, atau beberapa agent yang berkoordinasi. Ongkos sebuah framework bukan API-nya, melainkan bahwa bagian yang paling perlu Anda periksa saat hari buruk justru berada di dalam abstraksi orang lain. Apa pun pilihannya, simpan prompt, definisi alat, dan set evaluasi di luar framework supaya berpindah memakan sehari, bukan penulisan ulang.

Ada dua biaya dan tim rutin merencanakan yang keliru. Biaya membangun: agent internal bercakupan sempit biasanya menelan $8.000–$30.000 engineering; agent yang menghadap pelanggan dengan integrasi nyata, evaluasi, dan pemantauan lebih sering di $30.000–$120.000. Biaya menjalankan: belanja token biasanya pos yang lebih kecil dan paling mudah ditekan — mengarahkan langkah sederhana ke model lebih murah, cache, dan memangkas konteks kerap memotongnya separuh. Pos yang terlupa adalah pemeliharaan: model dihentikan, API berubah, set evaluasi perlu dijalankan ulang. Sisihkan sekitar 15–25% dari biaya membangun per tahun.

Dengan membatasi apa yang bisa dilakukannya, bukan berharap ia berperilaku baik. Praktiknya: sandarkan jawaban pada dokumen yang diambil dan minta agent menyebut sumbernya; beri alat argumen bertipe yang ketat dan validasi sebelum dieksekusi; biarkan alat mengembalikan “tidak ditemukan” secara jujur dan ajari agent bahwa tidak mengembalikan apa pun adalah hasil yang sah; batasi jumlah langkah dan belanja per eksekusi; dan pasang persetujuan manusia di depan segala yang tak bisa dibatalkan — pembayaran, penghapusan, pesan keluar ke pelanggan. Lalu ukur. Set evaluasi berisi lima puluh kasus nyata, termasuk yang canggung, bercerita lebih banyak tentang keandalan daripada penyetelan prompt mana pun.

Pakai platform no-code kalau tugasnya standar, volumenya sedang, dan biaya jawaban salah rendah — merutekan FAQ internal, triase prospek, menyusun draf balasan pertama. Platform memang lebih cepat sampai hasil dan mengajarkan apa yang sebenarnya dibutuhkan tugas itu. Bangun sendiri bila agent harus menyentuh sistem Anda dengan izin nyata, bila latensi atau biaya per unit penting pada volume Anda, bila Anda butuh evaluasi dan jejak audit sendiri, atau bila agent adalah bagian dari produk yang Anda jual. Jalur yang lazim itu masuk akal: buktikan alurnya di platform, lalu bangun ulang bagian yang memang pantas.