Studi Kasus Vetmo: Pasang Agent Tool Retry Budget di Asisten Booking Pet Care, Pangkas Token Inferensi 34 Persen dan Naikkan Task Completion Rate 19 Persen di 2026

TL;DR: Asisten booking AI di Vetmo (platform pet care) sebelumnya membakar token tinggi karena retry tak terbatas saat API kalender pet clinic down. Setelah dipasang retry budget eksplisit (2 untuk database write, 3 untuk read, 1 untuk payment), token per task turun 34 persen dan task completion rate naik dari 71 ke 90 persen dalam 30 hari di Q1 2026.

Vetmo punya asisten AI untuk booking konsultasi pet. Saat audit produksi April 2026, kami menemukan satu task booking bisa membakar 28 ribu token karena agen terus retry tool call yang gagal. Worst case: agen masuk loop 14 kali sebelum menyerah, semua dalam satu sesi.

Diagnosa Awal

Sample 200 sesi booking selama 7 hari, distribusi retry per task:

Masalah: tidak ada batas eksplisit. Agen retry sampai max tokens habis. Konsep ini saya jelaskan rinci di glosarium Agent Tool Retry Budget. Untuk pola dasar backoff yang relevan, lihat AWS Builder Library tentang retry strategy.

Implementasi Retry Budget

Konfigurasi budget per kategori tool:

RETRY_BUDGET = {
  "search_pet_clinic": 3,    # network blip lazim
  "get_available_slot": 3,   # idempoten, read-only
  "create_booking": 1,       # write, hindari double-book
  "send_confirmation": 4,    # SMTP throttling pulih
  "process_payment": 1       # idempoten ditegakkan di backend
}

Logika eskalasi: setelah budget habis, agen tidak retry lagi. Sebaliknya, agen menjelaskan ke user "sistem klinik sedang sibuk, coba 5 menit lagi atau hubungi tim Vetmo". Approach ini juga melengkapi Agent Tool Call Success Rate sebagai metrik observability.

Hasil 30 Hari

Penurunan biaya 33 persen mungkin terasa kontras dengan kenaikan completion rate. Logikanya: agen yang berhenti retry lebih cepat membebaskan budget untuk eskalasi ke fallback yang benar-benar bekerja (kontak manusia, slot alternatif).

Pertanyaan Umum

Apakah retry budget rendah membuat agen kurang persistent?

Tidak, kalau fallback dirancang baik. Agen yang menyerah ke fallback bermanfaat lebih cepat menyelesaikan task daripada agen yang loop tak bermakna.

Bagaimana menentukan budget optimal per tool?

Mulai dari rekomendasi default (read 3, write 1-2, payment 1). Monitor 2 minggu, sesuaikan berdasar data success rate per percobaan.

Apakah strategi ini cocok untuk asisten chatbot non-booking?

Ya. Pola ini berlaku untuk semua agen produksi yang punya tool call. Customer support assistant, research assistant, sales qualifier, semua relevan.

Bagaimana hubungannya dengan exponential backoff?

Saling melengkapi. Backoff atur jarak antar retry, budget atur jumlah maksimum. Dua-duanya wajib di produksi.

Penutup

Retry budget bukan optimasi mewah. Untuk asisten AI yang melayani transaksi (booking, payment, write), tanpa batas eksplisit Anda membakar token untuk loop tak bermakna. Mulai dari konfigurasi konservatif, monitor 2 minggu, lalu kalibrasi.