3 hafta önceki ilk Show GN gönderimde 5 katmanlı bir firewall yaptığımı paylaşmıştım; bu arada yaptığım tasarım düzeltmelerini ve gerçekten ship ettiğim şeyleri paylaşıyorum.
▶ 5-tier → 4-tier düzeltmesi (PUSH / QUEUE / SILENT / AUTO)
"Call" katmanı çıkarıldı ve beklemeye alındı. Buna PoC sürecinde elde edilen verilerle karar verildi.
▶ Agent loop uçtan uca tamamlandı
Toplantı talep e-postası gelir → tier sınıflandırması yapılır → Klorn takvim conflict durumunu kontrol eder → yanıt + takvim etkinliği taslağı oluşturur → PendingAction olarak bekler → kullanıcı tek tıkla onaylar → gönderilir. Tüm aksiyonlar gönderimden önce payload hash ile imzalanır; ActionReceipt eşleşmesi yoksa çalıştırılamaz.
▶ En uzun süren kısım: invariant test (100 satırdan az kod)
send_email gibi bir aksiyon kullanıcı onayı olmadan çalışırsa build'i bozan test. Biri approval check'i kaldırırsa → test başarısız → build başarısız → deploy başarısız. Dolanmak başlı başına bir seçenek olmuyor. "agent kendi kendine göndermiyor" ifadesinin pazarlama söylemi değil de gerçek olmasının nedeni bu.
▶ Gerçek prod bug'lardan birini de yakaladım
OpenRouter :free model SKU'sunu emekliye ayırdı, bu yüzden tüm autonomous cycle'lar "404 No endpoints found" ile çöküyordu. Mevcut failover yalnızca 402 / 403 / 429 durumlarını işliyordu. "Model ortadan kayboldu" durumunu ele almıyordu. Multi-model fallback chain ekledim; böylece upstream'deki tek bir SKU ölse bile agent ölmüyor.
▶ Day 14+7 retention ölçülüyor
ICP içinden 5 aktif kullanıcı, PoC'yi geçme kriteri. Dürüst tek satırlık geri bildirim bile memnuniyetle karşılanır.
▶ 60 saniyelik video: https://klorn.ai
▶ Kod: https://github.com/k08200/klorn
Beta ücretsiz + PRO otomatik uygulanıyor. İlk yazıya görüş bırakan herkese gerçekten teşekkürler.
3 yorum
Bir soru — agent / SaaS işletenler, agent kullanıcı niyeti olmadan hareket ettiğinde en sık gördüğünüz failure mode neydi?
Benim işletirken gördüğüm sıklık sırasına göre:
:freeSKU kapanınca fallback olmadan cycle’ın ölmesiBaşkalarının gördüğü pattern’leri merak ediyorum.
2 numara sık yaşanıyordu; buna alternatif olarak fallback uygulayınca bu kez prompta bağlı olarak 1 numara ortaya çıktı ve onun sonucunda da 3 numara yaşandı haha
Tabii her zaman gelişmiş bir model kullansanız böyle olmazdı ama müşteri odaklı bir hizmette sonuçta Sonnet seviyesi ve üzeri modeller maliyet açısından yük getiriyor ..
Haha, o sıralamaya gerçekten katılıyorum. Ben de en çok #2 yüzünden yara aldım; free’e düşürünce prompt uymayıp #1 patlamasını da birebir yaşadım.
Ben de bu yüzden bir noktadan sonra modele güvenmeyi bıraktım; onun yerine model ucuz mu pahalı mı, retire mı oldu fark etmeksizin, mail gönderme, silme ya da dışarı aktarma gibi şeyleri modelin karar veremeyeceği şekilde engelledim. Bunlar mutlaka insan onayı alıp öyle çıkıyor. Otomatik çalışanlar ise sadece sınıflandırma, okundu işaretleme, briefing gibi geri alınabilir şeyler.
Böyle kurunca model drift etse bile en kötü senaryo "benim görüp reddedeceğim garip bir öneri" oluyor; "çoktan gönderilmiş bir yanıt" olmuyor. #1, #3’e kadar sıçramıyor.
#2 tarafında, free SKU’nun 404 vermesini günlük katalog kontrolüyle yakalayıp fallback chain ile dolaşıyorum; ama sadece sınıflandırıcıyı ücretli flash’a sabitledim. Sonnet seviyesinde olanı full kullanmak bana da müşteri tarafında yük oluyor... Yani parayı sadece sınıflandırmaya harcayıp öneri üretmeyi free’de bırakıyorum, riski de onay kapısının üstlenmesini sağlıyorum.
Sonuçta maliyetle güvenliği aynı eksene koymamanın kilit nokta olduğunu düşünüyorum. Model ucuz olabilir ama gate ucuz olmamalı çünkü.