Studi Kasus Vetmo: Turunkan Agent Tool Prefetch Stall Rate Asisten Booking dari 22 ke 6 Persen dan Pangkas p95 Latency Sesi 38 Persen dalam 28 Hari di 2026

TL;DR: Asisten booking Vetmo (pet care Indonesia) awalnya punya agent tool prefetch stall rate 22 persen, menyebabkan p95 latency sesi 1.640 ms dan banyak drop-off di langkah pilih dokter. Setelah audit budget prefetch dan reorder urutan prediksi tool, stall rate turun ke 6 persen dalam 28 hari. p95 sesi pangkas 38 persen, panggilan API sinkron berkurang, hemat sekitar Rp 2,1 juta per bulan biaya inferensi.

Pada awal April 2026, tim Vetmo melaporkan masalah yang tidak terlihat di metrik permukaan, conversion rate booking tetap di angka 4,2 persen, tapi feedback pengguna konsisten menyebut asisten "kadang nyangkut" saat memilih dokter atau cek jadwal. Saat Vito Atmo masuk untuk audit pada minggu kedua April, sumber masalahnya jelas, prefetch tool yang seharusnya menyiapkan data dokter dan jadwal di latar belakang sering belum tuntas saat user mengetik prompt.

Ini adalah pola klasik agent tool prefetch stall rate yang tinggi. Konteksnya, asisten Vetmo memakai tiga tool eksternal di sesi booking, list_dokter, cek_jadwal, dan create_booking. Strategi prefetch awal memuat ketiganya secara paralel di awal sesi, tapi rate limit Supabase Edge Functions dan urutan prediksi yang lemah membuat fetch sinkron sering terjadi.

Baseline: Di Mana Kerusakannya?

Instrumentasi OpenTelemetry awal yang dipasang minggu pertama menunjukkan distribusi yang mengejutkan, prefetch tuntas tepat waktu hanya 78 persen, sisanya stall. Yang menarik, stall tidak merata, terkonsentrasi di sesi dengan kueri panjang seperti "saya cari dokter hewan kucing terdekat hari Sabtu sore".

Intervensi: Tiga Perubahan, Tidak Lebih

Vito Atmo menerapkan tiga perubahan terfokus, sengaja menahan diri dari menulis ulang prompt atau ganti model. Tujuannya isolasi variabel.

1. Reorder prediksi tool berdasarkan intent. Daripada prefetch tiga tool paralel, intent classifier ringan (regex + rule, bukan LLM) memprediksi tool mana yang paling mungkin dipanggil pertama. list_dokter dipanggil di 81 persen sesi, jadi diprioritaskan. create_booking hampir tidak pernah jadi tool pertama, jadi prefetch ditunda.

2. Pasang budget prefetch eksplisit di angka 3 slot. Konsep ini Vito turunkan dari agent tool prefetch budget. Sebelumnya tidak ada batas, jadi prefetch agresif menghabiskan rate limit. Dengan 3 slot, sistem menolak prefetch ke-4 dengan graceful, mengizinkan rate limit untuk fetch sinkron yang benar-benar dibutuhkan.

3. TTL cache hasil prefetch dinaikkan dari 30 detik ke 120 detik. Data dokter dan jadwal Vetmo update relatif jarang (per jam), jadi TTL 30 detik terlalu konservatif dan memaksa refetch yang tidak perlu.

Hasil: 28 Hari, Tiga Metrik Bergerak Bersamaan

Stall rate turun progresif dari 22 ke 6 persen. p95 sesi turun dari 1.640 ms ke 1.020 ms (38 persen pangkas). Yang tidak terduga, booking completion rate naik dari 4,2 ke 5,1 persen, indikasi bahwa "kadang nyangkut" memang membuat user keluar sebelum menyelesaikan booking.

Biaya inferensi turun karena dua hal, panggilan tool sinkron berkurang 74 persen, dan token konteks lebih efisien karena hasil prefetch sudah ada di cache (lihat LLM context window utilization rate yang turun dari 68 ke 51 persen). Total hemat sekitar Rp 2,1 juta per bulan, angka ini spesifik untuk volume Vetmo dan tidak otomatis berlaku untuk bisnis lain.

Pelajaran yang Bisa Diterapkan

Intent classifier murah (regex + rule) sering cukup untuk reorder prediksi prefetch, tidak selalu butuh LLM kecil. Budget eksplisit adalah disiplin operasional yang sederhana tapi sering diabaikan, "tidak ada batas" sama dengan "tidak ada jaminan". TTL cache jangan default dari boilerplate, sesuaikan dengan frekuensi update data sebenarnya. Referensi konsep observabilitas yang Vito pakai dapat dibaca di OpenTelemetry.

Pertanyaan Umum

Apakah hasil ini akan sama di bisnis SaaS lain?

Angka spesifik tidak akan sama, tetapi pola intervensi (reorder prediksi, budget eksplisit, TTL realistis) berlaku umum untuk produk agentic dengan multiple tool eksternal.

Berapa lama biasanya melihat dampak setelah tuning?

Berdasarkan beberapa proyek similar, 14 hari biasanya sudah cukup untuk melihat tren, 28 hari untuk stabilisasi. Vetmo melihat sebagian besar gain di minggu pertama.

Apakah perlu mengganti vendor LLM untuk mencapai angka ini?

Tidak. Tiga intervensi di studi kasus ini dilakukan tanpa ganti model atau provider, hanya orkestrasi di sisi aplikasi.

Bagaimana cara mulai audit prefetch di pipeline saya?

Pasang OpenTelemetry span untuk fase prefetch dan fase tool-call. Hitung sesi yang fase tool-call menunggu prefetch. Itu adalah stall rate Anda, dan biasanya mengejutkan tinggi di pengukuran pertama.

Penutup

Studi kasus Vetmo menggarisbawahi pola yang sering Vito temui di pipeline agentic Indonesia, masalah latency yang dirasakan pengguna sering bukan masalah model atau prompt, tetapi masalah orkestrasi tool. Stall rate 22 persen di Vetmo adalah angka yang menyembunyikan diri di metrik agregat, tapi terasa nyata di pengalaman pengguna. Memasang instrumentasi yang tepat, kemudian melakukan tiga perubahan terfokus, sudah cukup untuk mengubah baik pengalaman pengguna maupun biaya operasional dalam waktu satu bulan.