3 हफ्ते पहले पहले Show GN में मैंने शेयर किया था कि मैं 5-tier firewall बना रहा हूँ, और इस बीच की design correction + जो वास्तव में ship किया, वह साझा कर रहा हूँ. 1 point/1 comment के साथ दब गया था, लेकिन प्रगति हुई है इसलिए एक बार फिर.
▶ 5-tier → 4-tier correction (PUSH / QUEUE / SILENT / AUTO)
"Call" tier को हटाकर hold पर रखा है. PoC के दौरान मिले data के आधार पर यह फैसला किया.
▶ Agent loop end-to-end पूरा
Meeting request email आता है → tier classification → Klorn calendar conflict चेक करता है → reply + calendar event draft बनाता है → PendingAction में wait करता है → user 1-click approve करता है → launch. सभी actions को launch से पहले payload hash से sign किया जाता है, और ActionReceipt match न हो तो execution संभव नहीं.
▶ सबसे ज्यादा समय लेने वाला हिस्सा: invariant test (100 lines से कम code)
ऐसा test जिसमें send_email जैसी action अगर user approval के बिना execute हो जाए तो build टूट जाए. अगर कोई approval check हटा दे → test fail → build fail → deploy fail. Bypass अपने आप में option नहीं बनता. "agent अपने आप नहीं भेजता" marketing copy नहीं, बल्कि सच क्यों है, इसकी यही वजह है.
▶ एक असली prod bug भी पकड़ा
OpenRouter ने :free model SKU retire कर दिया, इसलिए सभी autonomous cycle "404 No endpoints found" के साथ मर रहे थे. पहले का failover सिर्फ 402 / 403 / 429 संभालता था. "model गायब हो गया" केस handle नहीं होता था. Multi-model fallback chain डाल दी, इसलिए ऊपर वाला कोई एक SKU मर जाए तब भी agent नहीं मरता.
▶ Day 14+7 retention माप रहा हूँ
ICP के 5 active users PoC pass करने का मानदंड हैं. ईमानदार feedback की एक लाइन भी स्वागतयोग्य है.
▶ 60-second video: https://klorn.ai
▶ Code: https://github.com/k08200/klorn
Beta मुफ़्त है + PRO अपने आप apply हो रहा है. पहली पोस्ट पर राय देने वाले सभी लोगों का सच में धन्यवाद.
3 टिप्पणियां
एक सवाल — agent / SaaS चलाने वाले लोगों, जब agent ने user की मंशा के बिना काम किया, तब आपने सबसे ज़्यादा कौन-सा failure mode देखा?
मैंने ऑपरेशन के दौरान जो frequency के क्रम में देखा:
:freeSKU बंद होते ही बिना किसी fallback के cycle भी बंद हो गयादूसरे लोगों के patterns जानने की जिज्ञासा है.
2 नंबर वाली स्थिति अक्सर होती थी, और उसके विकल्प के तौर पर fallback करने पर prompt के मुताबिक 1 नंबर वाली स्थिति हो जाती थी, और उसके चलते 3 नंबर वाली स्थिति भी हो जाती थी haha
अगर हमेशा advanced model इस्तेमाल करें तो शायद ऐसा न हो, लेकिन आखिरकार customer-facing service में Sonnet-स्तर या उससे ऊपर का मॉडल रखना काफ़ी महंगा पड़ता है ..
haha उस क्रम से मैं सच में बहुत relate करता/करती हूँ। मैं भी #2 की वजह से सबसे ज़्यादा जला/जली हूँ, और free पर गिराते ही prompt नहीं बैठता, तो #1 हो जाना भी मैंने बिल्कुल वैसे ही झेला है.
इसलिए मैंने भी एक समय के बाद model पर भरोसा करना छोड़ दिया, और उसकी जगह यह रोक लगा दी कि model सस्ता हो, महंगा हो, या retire हो जाए, उससे फर्क नहीं — mail भेजना, delete करना, या बाहर handoff करना जैसे काम model तय ही न कर सके। ऐसे काम हमेशा human approval के बाद ही बाहर जाएँ। जो चीज़ें अपने-आप चलें, वे सिर्फ classification, read processing, briefing जैसी हों जिन्हें वापस पलटा जा सके।
ऐसा करके रखा तो model drift हो जाए तब भी सबसे बुरा मामला "मैं देखकर reject कर दूँ ऐसा अजीब suggestion" होता है, "पहले ही भेजा जा चुका reply" नहीं। #1, #3 तक फैलता नहीं है।
#2 के लिए free SKU 404 आने वाली चीज़ मैं रोज़ catalog check करके पकड़ता/पकड़ती हूँ और fallback chain से bypass करता/करती हूँ, लेकिन classifier ही एक चीज़ है जिसे paid flash पर fixed रखा है। Sonnet-स्तर का full इस्तेमाल करना मेरे लिए भी customer-facing में भारी पड़ता है... इसलिए classification पर ही पैसा खर्च किया, suggestion बनाना free पर छोड़ा, और risk approval gate को absorb करने दिया।
आखिरकार मुझे लगा कि key यही था कि cost और safety को एक ही axis पर n रखा जाए। Model सस्ता हो सकता है, लेकिन gate सस्ता नहीं होना चाहिए।