AI agent yang menghasilkan jawaban bagus dalam satu menit mungkin berguna untuk menyiapkan laporan, tetapi terlalu lambat saat petugas harus melayani pelanggan di loket. Latensi AI agent bisnis harus dinilai terhadap waktu keputusan operasional. Sebelum memilih model atau menambah tool, tentukan berapa lama pengguna dapat menunggu dan apa yang harus terjadi ketika batas itu terlewati.
Panduan ini membantu COO, pemilik produk, dan tim TI merancang pilot berbasis waktu respons. Angka yang dipakai adalah ilustrasi anggaran waktu, bukan benchmark model atau janji performa Layana. Kapabilitas dan batas layanan penyedia harus diverifikasi pada dokumentasi resminya ketika produk tertentu dipilih.
Bedakan Respons Awal dan Pekerjaan Selesai
Pesan “permintaan sedang diproses” dapat muncul cepat, tetapi belum berarti pekerjaan selesai. Ukur waktu sampai hasil yang dapat dipakai tersedia, termasuk pengambilan data, penalaran model, pemanggilan tool, validasi, dan review manusia bila diperlukan. Jika hasilnya berupa tindakan, penyelesaian berarti status tindakan sudah dibaca balik, bukan sekadar model menyatakan berhasil.
Pisahkan tiga ukuran: waktu pengakuan penerimaan, waktu keluaran awal yang berguna, dan waktu penyelesaian terverifikasi. Untuk proses asinkron, pengguna perlu ID pekerjaan dan status yang dapat diperiksa. Jangan menyamakan animasi mengetik atau token pertama dengan manfaat operasional yang sudah diterima.
Tentukan Kelas Layanan Berdasarkan Alur Kerja
Interaktif dengan Pengguna Menunggu
Pada layar petugas, keterlambatan dapat mengganggu antrean dan membuat pengguna mengulangi permintaan. Prioritaskan satu keluaran yang cukup untuk keputusan berikutnya. Tawarkan jalur manual yang jelas ketika AI tidak selesai. Jangan mewajibkan petugas menunggu agent menelusuri seluruh histori bila dua data penting sudah dapat ditampilkan lewat sistem biasa.
Asinkron dengan Tenggat Bisnis
Ringkasan untuk rapat besok tidak memerlukan pengalaman yang sama dengan loket. Pekerjaan dapat diantrekan dengan tenggat, pemilik, dan pemberitahuan yang disetujui. Namun, laporan yang selesai setelah rapat tetap terlambat meskipun proses teknis berhasil. Definisikan waktu mulai, batas selesai, dan tindakan saat tenggat tidak tercapai.
Pemilik proses menentukan toleransi waktu, sedangkan tim TI menjelaskan komponen yang dapat dikendalikan. Jangan menetapkan SLA hanya dari demonstrasi satu permintaan pada koneksi yang ideal. Volume serentak, panjang dokumen, cache kosong, dan gangguan sistem sumber perlu masuk rancangan uji.
Bagi Anggaran Waktu sampai ke Dependensi
Misalkan sebuah proses ilustratif memiliki batas total 30 detik. Tim mungkin mengalokasikan 5 detik untuk membaca sumber, 15 detik untuk model dan tool, serta 10 detik untuk validasi dan cadangan. Pembagian ini hanya contoh untuk memperlihatkan bahwa seluruh tahap berbagi satu batas total. Jika tahap awal sudah menghabiskan anggaran, tahap berikutnya tidak boleh terus berjalan tanpa kebijakan yang jelas.
Catat waktu antrean, setiap pemanggilan model, retrieval, tool eksternal, dan pembacaan balik. Tool yang lambat dapat menjadi penyebab utama meski model cepat. Tetapkan batas jumlah langkah dan batas waktu keseluruhan; membatasi tiap tool saja masih memungkinkan agent mengulang banyak tool hingga waktu total melampaui kebutuhan bisnis.
Panduan arsitektur Anthropic mengingatkan bahwa agentic systems dapat menukar latensi dan biaya dengan peningkatan kinerja tugas. Prinsip itu mendukung pengujian pendekatan sederhana terlebih dahulu; bukan bukti bahwa semua agent selalu lebih lambat atau bahwa produk tertentu memenuhi target waktu.
Rancang Timeout Tanpa Menciptakan Tindakan Ganda
Timeout berarti pemanggil berhenti menunggu; sistem tujuan mungkin masih memproses permintaan. Jika tool mengubah transaksi ERP, jangan langsung mengulangi hanya karena jawaban tidak datang. Cari status melalui ID operasi atau objek yang sama. Keluaran harus menyatakan “status belum terkonfirmasi” sampai bukti menunjukkan berhasil atau gagal.
Pisahkan pembatalan permintaan pengguna dari pembatalan pekerjaan di server. Menutup tab belum tentu menghentikan tugas. Untuk tindakan yang tidak mudah dibatalkan, kebijakan perlu menetapkan apakah pekerjaan boleh diteruskan setelah pengguna pergi dan siapa yang menerima hasil. Persetujuan yang kedaluwarsa harus diperiksa lagi sebelum langkah yang berdampak dijalankan.
Rancangan pemulihan dapat merujuk circuit breaker dan pemulihan aplikasi. Agent tidak boleh memperluas hak akses, mengganti sumber ke entitas lain, atau melewati approval demi mengejar tenggat. Kecepatan bukan alasan mengubah mandat.
Gunakan Fallback yang Memiliki Arti Bisnis
Fallback bisa berupa data terakhir dengan penanda waktu, hasil sebagian yang diberi label, formulir manual, atau penyerahan ke petugas. Pilih berdasarkan risiko keputusan. Untuk saldo terkini, snapshot lama mungkin tidak layak; untuk pencarian dokumen umum, hasil parsial dapat tetap membantu. Pemilik bisnis harus menyetujui arti dan batas keluaran tersebut.
Jangan menurunkan model atau menghilangkan verifikasi secara diam-diam. Jika jalur alternatif menghasilkan kualitas berbeda, pengguna dan log perlu mengetahuinya. Cache harus memiliki batas entitas, hak akses, versi data, dan kedaluwarsa. Jawaban cepat dari cache yang sudah tidak berlaku dapat lebih merugikan daripada penolakan yang jelas.
Ukur Distribusi Waktu Bersama Mutu Hasil
Rata-rata menyembunyikan permintaan yang sangat lambat. Catat median serta persentil seperti p95, yaitu waktu yang mencakup 95% pengamatan pada sampel uji. Laporkan ukuran sampel, jenis tugas, kondisi beban, dan jendela ukur agar hasil dapat ditafsirkan. Sampel kecil atau beban yang tidak mewakili produksi tidak cukup untuk menjanjikan SLA.
Pasangkan metrik waktu dengan proporsi hasil yang diterima, pekerjaan yang timeout, pengguna yang beralih manual, dan tindakan yang statusnya ambigu. Ukur waktu total manusia, termasuk menunggu dan koreksi. Agent yang lebih cepat tetapi lebih sering salah dapat memperbesar waktu penyelesaian proses. Sebaliknya, proses asinkron yang lebih lama bisa tetap berguna bila hasilnya tersedia sebelum tenggat nyata.
Susun Pilot dengan Kondisi Sulit yang Terkendali
Mulai dari pengukuran read-only pada sumber yang diizinkan. Uji dokumen pendek dan panjang, data kosong, konektor lambat, antrean penuh, pembatalan, serta permintaan berulang. Pengujian gangguan dilakukan di lingkungan yang memang berwenang untuk diuji, bukan dengan merusak layanan produksi. Catat batas sumber daya dan kondisi pemulihan sebelum memulai.
Setelah mutu stabil, tentukan gerbang keputusan: lanjut bila keluaran diterima dalam batas operasional, ubah alur menjadi asinkron bila pengguna tidak dapat menunggu, atau gunakan workflow tetap bila agent tidak memberi nilai tambahan. Rencana tersebut perlu konsisten dengan kriteria penghentian pilot AI, tanpa menganggap target tercapai sebelum ada bukti.
Bawa Tenggat dan Contoh Tugas ke Diskusi Kebutuhan
Siapkan satu alur, contoh input tersamarkan, volume serentak yang diperkirakan, batas waktu keputusan, dan jalur manual saat AI gagal. Layanan AI dan machine learning Layana dapat menjadi titik pembahasan pilot dan integrasinya. Diskusikan batas waktu dan fallback pilot AI agent agar pengalaman pengguna dan kontrol operasional dirancang bersama.
Featured image merupakan ilustrasi konseptual review dokumen bisnis, bukan dashboard pemantauan atau bukti benchmark performa.