Studi Kasus Atmo LMS: Pasang Agent Tool Circuit Breaker Window 120 Detik di Asisten Kurikulum, Pangkas Cascading Failure 67 Persen dan Hemat Biaya Inferensi Rp 7,4 Juta per Bulan dalam 34 Hari di 2026

TL;DR: Setelah satu episode cascading failure di asisten kurikulum Atmo LMS bulan April 2026, tim kami pasang Agent Tool Circuit Breaker Window 120 detik di empat tool downstream. Dalam 34 hari, cascading failure turun 67 persen, biaya inferensi turun Rp 7,4 juta per bulan, dan p95 latency sesi agen stabil di 760 ms. Catatan ini menjelaskan parameter, trade-off, dan langkah aplikasi di stack Next.js Supabase.

Asisten kurikulum Atmo LMS menangani 1.200 sesi per hari, sebagian besar pertanyaan siswa tentang materi modul. Pada awal April 2026, satu tool reranker eksternal mengalami timeout berturut-turut selama 14 menit. Agen tidak punya pemutus sirkit, retry terus berjalan, dan token konteks habis sebelum jawaban siap. Insiden itu menjadi pemicu pemasangan circuit breaker window.

Konteks Insiden

Reranker eksternal yang kami gunakan punya SLA 99,5 persen. Pada hari insiden, latency p99 melonjak dari 180 ms ke 8 detik. Agen, tanpa circuit breaker, terus memanggil reranker dan menumpuk retry budget sampai habis. Akibatnya 64 sesi gagal total dalam 14 menit, biaya inferensi spike Rp 1,2 juta hanya untuk retry storm. Pola kegagalan ini menyerupai apa yang didefinisikan di Agent Tool Retry Budget Burnout, tetapi pemicu inti bukan habisnya retry budget, melainkan tidak adanya pemutus eksplisit.

Parameter yang Diuji

Kami menjalankan ablation singkat selama 8 hari, menguji tiga konfigurasi window:

Window 120 detik dipilih sebagai default. Definisi parameter ini mengikuti pola yang dijelaskan di Agent Tool Circuit Breaker Window.

Eksekusi di Next.js Supabase

Implementasi dipasang di middleware tool client. Setiap pemanggilan tool dilewatkan melalui wrapper yang mencatat hasil ke tabel agent_tool_health. Saat window terbuka, wrapper mengembalikan fallback (cached answer atau "tool tidak tersedia, coba ulang") tanpa memanggil tool. Pendekatan ini berdampingan dengan Agent Tool Degradation Policy yang sudah lebih dulu kami pasang sejak Maret 2026.

Untuk monitoring, kami pasang dashboard di Supabase Studio yang membaca tabel kesehatan setiap 30 detik, mirip pola observability yang direkomendasikan Google SRE Handbook untuk sistem dengan dependency eksternal.

Hasil 34 Hari

Setelah pemasangan, indikator utama bergerak sebagai berikut:

Penghematan biaya berasal dari dua sumber. Pertama, retry storm yang dipangkas. Kedua, sesi-sesi gagal yang dulu menelan token tanpa hasil sekarang dihentikan lebih awal lewat fallback. Hasil ini konsisten dengan studi kasus Atmo LMS terkait Degradation Policy yang juga menyoroti dampak pemutusan pada beban downstream.

Trade-Off

Tidak ada solusi resiliensi tanpa biaya. Window 120 detik berarti ada periode 2 menit di mana sebagian siswa mendapat pesan fallback alih-alih jawaban kontekstual. NPS asisten turun sementara 3 poin pada minggu pertama, tetapi pulih setelah copy fallback diperhalus. Angka ini bervariasi tergantung industri dan ukuran user base, jadi tim disarankan mengukur sendiri.

Pertanyaan Umum

Bisakah window terlalu pendek?

Bisa. Window 30 detik membiarkan agen kembali memanggil tool yang belum benar-benar pulih, memicu open-close-open dan menambah noise di logging. Kami sarankan minimum 60 detik untuk tool dengan recovery cepat.

Bagaimana cara menentukan threshold kegagalan?

Mulai dari 50 persen dari 10 panggilan terakhir. Sesuaikan turun bila tool punya volatilitas tinggi dan biaya retry mahal. Sesuaikan naik bila tool sering false-positive failure.

Apakah pendekatan ini bisa dipakai tanpa Supabase?

Bisa. Logika circuit breaker tidak tergantung database. Tabel agent_tool_health hanya untuk audit dan dashboard. Implementasi minimal cukup in-memory untuk single-instance.

Penutup

Cascading failure jarang datang dari satu titik. Biasanya satu tool yang lambat menyeret seluruh sesi agen ke jurang yang sama. Circuit breaker window adalah salah satu cara murah memutus rantai itu. Untuk tim yang menjalankan asisten LLM di produksi, parameter ini lebih layak diperdebatkan dibanding pilihan model.