Tiga minggu lalu di Show GN pertama saya, saya membagikan bahwa saya sedang membuat firewall 5-tier; sejak itu saya ingin membagikan revisi desain + apa yang benar-benar sudah saya kirimkan. Meski tenggelam dengan 1 poin/1 komentar, ada kemajuan jadi saya coba sekali lagi.
▶ Revisi 5-tier → 4-tier (PUSH / QUEUE / SILENT / AUTO)
Tier "Call" saya keluarkan dan tunda. Keputusan ini diambil berdasarkan data selama PoC berjalan.
▶ Loop agent end-to-end selesai
Email permintaan meeting masuk → klasifikasi tier → Klorn memeriksa konflik kalender → balasan + draft event kalender → menunggu sebagai PendingAction → pengguna approve dengan 1 klik → kirim. Semua aksi ditandatangani dengan hash payload sebelum dikirim, dan tidak bisa dieksekusi jika tidak ada kecocokan ActionReceipt.
▶ Bagian yang paling lama: invariant test (kurang dari 100 baris kode)
Sebuah test yang membuat build gagal jika aksi seperti send_email dijalankan tanpa approval pengguna. Jika seseorang menghapus pemeriksaan approval → test gagal → build gagal → deployment gagal. Melewati mekanisme ini sama sekali bukan opsi. Itulah alasan "agent tidak mengirim sendiri" bukan sekadar kalimat marketing, tapi benar-benar fakta.
▶ Saya juga menemukan satu bug nyata di production
OpenRouter memensiunkan SKU model :free, sehingga semua autonomous cycle mati dengan "404 No endpoints found". Failover yang lama hanya menangani 402 / 403 / 429. Kasus "model hilang" belum tertangani. Saya memasang multi-model fallback chain sehingga meski satu SKU upstream mati, agent tidak ikut mati.
▶ Sedang mengukur retensi Day 14+7
Aktivasi 5 orang ICP adalah kriteria lolos PoC. Saya juga sangat menghargai bahkan satu baris feedback yang jujur.
▶ Video 60 detik: https://klorn.ai
▶ Kode: https://github.com/k08200/klorn
Beta gratis + PRO diterapkan otomatis. Terima kasih banyak kepada semua yang memberi masukan pada tulisan pertama.
3 komentar
Satu pertanyaan — buat yang menjalankan agent / SaaS, apa failure mode yang paling sering kalian lihat ketika agent bertindak tanpa niat pengguna?
Kalau dari yang saya lihat saat operasional, urut berdasarkan frekuensi:
:freemati, siklus ikut mati tanpa fallbackPenasaran dengan pola yang kalian lihat.
Kasus nomor 2 sering terjadi, lalu saat pakai fallback sebagai alternatif, nomor 1 malah muncul sesuai prompt, dan akibatnya nomor 3 ikut terjadi wkwkwk.
Kalau selalu pakai model kelas atas sih mungkin tidak akan begitu, tapi untuk layanan yang ditujukan ke pelanggan, level Sonnet ke atas tetap terasa membebani ..
Haha, saya benar-benar relate dengan urutan itu. Saya juga paling sering kena di #2, dan waktu diturunkan ke free, prompt-nya jadi tidak cocok lalu #1 muncul juga—saya mengalami hal yang sama persis.
Jadi pada titik tertentu saya berhenti percaya pada model, dan sebagai gantinya, entah modelnya murah atau mahal, atau nanti di-retire, saya blok agar model tidak bisa memutuskan hal-hal seperti mengirim email, menghapus, atau meneruskan ke luar. Untuk itu harus selalu keluar setelah ada persetujuan manusia. Yang berjalan otomatis hanya hal-hal yang bisa dibatalkan seperti klasifikasi, tandai sudah dibaca, atau briefing.
Dengan begini, meskipun model drift, skenario terburuknya adalah "usulan aneh yang saya lihat lalu tolak", bukan "balasan yang sudah telanjur terkirim". #1 tidak merembet sampai #3.
Untuk #2, kemunculan 404 pada free SKU saya tangani dengan pengecekan katalog harian dan dialihkan lewat fallback chain, tetapi hanya classifier yang saya kunci ke flash berbayar. Memakai full kelas Sonnet untuk yang berhadapan dengan pelanggan juga terasa berat buat saya... jadi hanya klasifikasi yang pakai biaya, sementara pembuatan usulan tetap di free, dan gate persetujuan yang menyerap risikonya.
Pada akhirnya, saya rasa kuncinya adalah tidak menempatkan biaya dan keamanan pada sumbu yang sama. Model boleh murah, tapi gate tidak boleh murah.