Agen AI Berhasil Saat Demo. Ini yang Bisa Rusak Saat Dipakai Pelanggan

Saat demo, pelanggan mengajukan pertanyaan yang rapi. Agen menemukan catatan yang tepat, memilih tool yang benar, lalu memberikan jawaban berguna. Semua orang melihat jalur berhasil. Tidak ada yang melihat kejadian ketika catatan hilang, pelanggan mengubah keinginan di tengah proses, atau layanan eksternal menerima tindakan tetapi mengalami timeout sebelum mengirim konfirmasi.

Lingkungan produksi memuat ketiga keadaan itu, terkadang sebelum satu sore yang sibuk berakhir.

Jarak antara demo yang bekerja dan layanan yang dapat diandalkan tidak cukup dijelaskan dengan persentase kegagalan yang dramatis. Klaim tingkat kegagalan memerlukan penelitian yang bisa ditelusuri, pembagi yang jelas, dan definisi yang sesuai. Tanpa itu, angka tersebut tidak layak menjadi dasar investasi. Kriteria rilis milik bisnis sendiri dapat memberikan bukti yang lebih berguna.

Pastikan pekerjaannya memang membutuhkan agen

Sebagian pekerjaan terbantu oleh sistem yang memilih tindakan berikutnya secara dinamis. Pekerjaan lain sudah memiliki urutan tetap: memvalidasi formulir, mencari catatan, menjalankan aturan perhitungan, lalu menyiapkan balasan. Memberikan otonomi tambahan pada pekerjaan jenis kedua dapat menambah ketidakpastian tanpa manfaat bisnis yang sepadan.

Anthropic membedakan workflow dengan urutan yang ditetapkan dari agen yang mengarahkan penggunaan tool sendiri, serta menyarankan pendekatan sederhana sebagai titik awal. Pembedaan ini berguna untuk memilih arsitektur terkecil yang memenuhi kebutuhan. Building effective agents.

Misalnya, bisnis jasa ingin mengonfirmasi ketersediaan jadwal. Query ketersediaan yang deterministik, diikuti balasan dengan batas jelas, mungkin sudah cukup. Agen menjadi lebih relevan ketika harus menyelidiki permintaan ambigu dari beberapa sumber. Meski demikian, kewenangan memesan slot atau mengubah kontrak tetap perlu dikendalikan secara terpisah dari kemampuan menyusun jawaban.

Tentukan selesai berdasarkan keadaan sistem

Pernyataan agen bahwa tugas telah selesai bukan bukti bahwa tugas benar-benar terjadi. Definisikan keberhasilan melalui sistem pencatatan utama. Booking dinyatakan ada ketika layanan pemesanan mengembalikan identitas konfirmasi dan catatan tersimpan sesuai pelanggan, waktu, serta layanan yang dimaksud. Draft email dinyatakan dibuat ketika dapat dibaca kembali dari kotak surat yang benar.

Tuliskan hasil kegagalan dengan ketelitian yang sama. Jika ketersediaan tidak dapat diperiksa, agen harus menjelaskan bahwa slot belum terkonfirmasi dan mengarahkan permintaan ke penanganan yang tepat. Kegagalan tool tidak boleh berubah menjadi tebakan penuh keyakinan. Jika pelanggan mengganti informasi penting, sistem perlu memvalidasi ulang sebelum bertindak.

Dengan cara ini, tim memiliki kontrak rilis yang praktis. Pengujian tidak berhenti pada apakah percakapan terdengar membantu. Pengujian memeriksa apakah keadaan yang benar berubah, apakah keadaan yang tidak boleh disentuh tetap terlindungi, dan apakah pelanggan menerima penjelasan akurat tentang kejadian sebenarnya.

Rancang tool agar tindakan dapat dipulihkan

Tool terlalu luas seperti kelola_pelanggan memberi ruang interpretasi yang besar. Operasi sempit dengan input serta output eksplisit lebih mudah divalidasi. Pisahkan pembacaan catatan, penyusunan usulan perubahan, dan penerapan perubahan yang disetujui ketika konsekuensinya memerlukan pemisahan tersebut.

Tangani permintaan ganda secara sengaja. Bayangkan pemesanan berhasil, tetapi responsnya hilang. Pengulangan tanpa pemeriksaan bisa membuat booking kedua. Gunakan identitas operasi dan pemeriksaan duplikasi di sisi layanan, sehingga pengulangan maksud yang sama mengembalikan hasil sebelumnya. Jaminan penting ini sebaiknya berada pada layanan, bukan hanya menjadi instruksi dalam prompt.

Anggap penyelesaian sebagian sebagai keadaan yang nyata. Jika invoice sudah dibuat tetapi pengirimannya gagal, tindakan pemulihan adalah mengulang pengiriman, bukan membuat invoice lain. Simpan kemajuan terstruktur yang cukup untuk melanjutkan dengan aman. Operator juga membutuhkan penjelasan yang mudah dipahami tentang bagian yang sudah selesai dan bagian yang masih tertunda.

Buat evaluasi yang berani mempermalukan sistem

Contoh yang bersih berguna untuk memeriksa fungsi dasar. Keputusan rilis juga memerlukan kasus sulit: catatan bertentangan, kebijakan kedaluwarsa, identitas pelanggan tidak lengkap, beberapa orang bernama serupa, dan tool yang mengembalikan kesalahan. Sertakan permintaan yang harus ditolak atau dialihkan oleh agen.

Simpan sebagian contoh evaluasi di luar proses penyetelan prompt. Jika semua contoh terus dimasukkan sebagai latihan, tim bisa menjadi sangat mahir melewati soal yang dikenal tanpa memahami kemampuan pada kasus baru. Nilai pemilihan tool, keadaan akhir, batas izin, dan ketepatan fakta secara terpisah. Jawaban ramah tidak boleh menutupi tindakan tanpa kewenangan.

Catat hasil yang diharapkan sebelum menjalankan pengujian. Minta ahli bidang terkait meninjau contoh ambigu dan menjelaskan alternatif yang dapat diterima. Pekerjaan ini membutuhkan waktu, tetapi hasilnya menjadi aset bisnis yang dapat dipakai ulang: gambaran konkret tentang perilaku layanan ketika kondisi tidak sempurna.

Tempatkan manusia pada keputusan yang tepat

Review manusia berguna jika reviewer memiliki informasi, waktu, dan kewenangan untuk campur tangan. Tampilan yang meminta persetujuan terhadap rencana panjang dan tidak transparan mudah berubah menjadi formalitas. Tampilkan tindakan yang diusulkan, bukti relevan, konsekuensi, serta ketidakpastian khusus yang membutuhkan penilaian.

Mulailah dengan persetujuan sebelum tindakan eksternal yang berdampak penting. Bisnis dapat mengizinkan kategorisasi otomatis, sambil mewajibkan konfirmasi sebelum pengembalian dana atau perubahan syarat kontrak. Batas tepatnya mengikuti dampak, kemungkinan pembatalan, dan kewajiban organisasi. Dokumentasikan batas tersebut dan, jika memungkinkan, tegakkan melalui lapisan tool.

Ukur antrean pemeriksaan. Jika setiap permintaan membutuhkan campur tangan besar, pilot mungkin membuktikan manfaat workflow berbantuan, belum membuktikan operasi mandiri yang layak. Hasil itu tetap bisa berguna. Jelaskan dengan jujur dan masukkan kapasitas manusia ke dalam model operasional, bukan menyembunyikannya sebagai pekerjaan tambahan yang dianggap gratis.

Perluas penggunaan melalui tahapan yang berbeda

Pertama, jalankan evaluasi offline pada data contoh yang disetujui. Berikutnya, gunakan mode bayangan: sistem menghasilkan usulan tindakan, sementara proses lama tetap menjadi penentu. Bandingkan usulan dengan hasil nyata tanpa membiarkan agen mengubah catatan pelanggan.

Setelah itu, aktifkan kelompok pengguna kecil yang terdefinisi, dengan batas jelas dan operator tersedia. Pilih kelompok berdasarkan relevansi serta risiko, bukan hanya kemudahan menghasilkan kesan baik. Amati kondisi yang sulit ditiru oleh tes offline, termasuk keterlambatan, pesan pelanggan berulang, dan perubahan catatan dari sistem lain saat proses berlangsung.

Perluas hanya setelah kriteria yang disepakati bertahan selama masa pengamatan yang bermakna. Satu pagi yang sepi tidak membuktikan keandalan. Pertahankan proses sebelumnya dan tetapkan keadaan yang memicu penghentian sementara atau rollback. Putuskan siapa yang berwenang mengambil tindakan itu sebelum insiden memaksa tim berunding secara terburu-buru.

Amati pekerjaan tanpa merekam semuanya

Catat identitas permintaan, versi model dan prompt, tool yang dipanggil, latensi, biaya, status akhir, serta alasan eskalasi. Informasi ini membantu membedakan kegagalan penalaran, pencarian informasi, integrasi, atau data bisnis. Samarkan atau batasi akses ke konten sensitif. Tidak setiap pertanyaan diagnostik membutuhkan penyimpanan percakapan lengkap tanpa batas.

Berikan operator tampilan ringkas tentang pekerjaan yang belum selesai. Peringatan perlu menjelaskan kegagalan, tindakan pelanggan yang mungkin sudah terjadi, dan langkah aman berikutnya. Tumpukan trace mentah bukan prosedur operasi. Uji apakah orang di luar tim pengembang dapat menggunakan panduan pemulihan untuk menangani kegagalan rutin.

Perhatikan perubahan lingkungan. Vendor dapat mengubah API, kebijakan bisa kedaluwarsa, dan versi model baru dapat berperilaku berbeda. Beri versi pada komponen penting dan jalankan kembali evaluasi terkait ketika terjadi perubahan. Kesiapan produksi dipertahankan melalui pemeriksaan tersebut, bukan status permanen yang didapat setelah satu peluncuran.

Ambil keputusan rilis dengan perhitungan jujur

Dalam contoh hipotetis, pilot menghemat empat menit pada permintaan rutin tetapi menambahkan lima belas menit pemeriksaan pada setiap pengecualian. Hasil akhirnya sangat dipengaruhi tingkat pengecualian. Ukur tingkat itu menggunakan lalu lintas yang mewakili sebelum membuat proyeksi penghematan atau kebutuhan tenaga kerja.

Masukkan keandalan layanan, beban pemeriksaan, biaya operasional, dan hasil pelanggan dalam keputusan rilis. Jika hasilnya belum cukup baik, persempit tugas atau pertahankan mode berbantuan sambil memperbaiki titik lemah. Menyebut workflow yang rapuh sebagai sistem otonom tidak menghasilkan keuntungan komersial dengan sendirinya.

Agen yang dapat diandalkan merupakan layanan dengan kewenangan jelas, hasil yang dapat diverifikasi, dan jalur pemulihan yang bisa dijalankan. Demo membuktikan keberhasilan mungkin terjadi. Proses produksi harus menunjukkan bahwa keberhasilan dapat diulang ketika jalur mudahnya tidak tersedia.