3週間前の最初の Show GN で 5-tier firewall を作っていると共有しましたが、その間の設計修正 + 実際に ship した内容を共有します。1票/1コメントで埋もれましたが、進展があったので再度。
▶ 5-tier → 4-tier に修正（PUSH / QUEUE / SILENT / AUTO）
"Call" tier は外して保留。PoC 進行中のデータで判断しました。
▶ Agent loop の end-to-end を完成
ミーティング依頼メールが到着 → tier 分類 → Klorn がカレンダーの conflict を確認 → 返信 + カレンダーイベントの draft を作成 → PendingAction として待機 → ユーザーが 1-click approve → 発射。すべてのアクションは発射前に payload hash で署名され、ActionReceipt の一致がなければ実行不可です。
▶ 最も時間がかかった部分: invariant test（コード 100 行未満）
send_email のようなアクションがユーザー approval なしで実行されると build が壊れるテストです。誰かが approval check を削除すると → テスト失敗 → build 失敗 → デプロイ失敗。迂回そのものが選択肢になりません。"agent が勝手に送らない" がマーケティング文句ではなく事実になる理由です。
▶ 実際の prod bug も 1 つ潰しました
OpenRouter が :free model SKU を retire して、すべての autonomous cycle が "404 No endpoints found" で落ちていました。既存の failover は 402 / 403 / 429 だけ処理。"モデル消滅" には対応できていませんでした。Multi-model fallback chain を入れて、upstream SKU が 1 つ死んでも agent は死にません。
▶ Day 14+7 retention を測定中
ICP 5人のアクティブ化が PoC 通過基準です。率直なフィードバック一言でも歓迎です。
▶ 60秒動画: https://klorn.ai
▶ コード: https://github.com/k08200/klorn
ベータ無料 + PRO 自動適用。最初の投稿で意見をくださった方々、本当にありがとうございました。
3件のコメント
質問です — agent / SaaS を運用している方々、agent がユーザーの意図なしに動いてしまったとき、最もよく見た failure mode は何でしたか？
私が運用しながら見た頻度順では:
:freeSKU が終了して、fallback もないまま cycle が止まる他の方々のパターンも気になります。
2番が頻発していて、その代案としてフォールバックすると、プロンプト次第で1番が発生し、それに伴って3番が発生していました（笑）
常に高性能モデルを使えばそんなことはないのでしょうが、やはり顧客向けサービスだと、Sonnet級以上は負担が大きいですからね..
笑いました、その流れ本当に共感します。自分も #2 でいちばん痛い目を見ましたし、free に落とすとプロンプトが合わなくて #1 になるのもまったく同じように経験しました。
なので自分は、ある時点でモデルを信じるのをやめて、代わりにモデルが安かろうが高かろうが retire されようが関係なく、メールを送る・消す・外部に渡すといったことはモデルが決められないように止めています。それは必ず人の承認を通してから出すようにしています。自動で回すのは、分類や既読処理、ブリーフィングのような、取り返しのつくものだけです。
こうしておくと、モデルが drift しても最悪でも「自分が見て却下する変な提案」であって、「もう送られてしまった返信」にはならないんですよね。#1 が #3 まで波及しません。
#2 は free SKU の 404 が出るのを毎日のカタログチェックで拾って、fallback チェーンで回避していますが、分類器だけは有料 flash に固定しました。Sonnet 級をフルで使うのは自分も対顧客では負担なので……。分類にだけお金を使って、提案生成は free のままにしつつ、承認ゲートにリスクを引き受けさせる形ですね。
結局、コストと安全性を同じ軸に置かないのが重要だった気がします。モデルは安くてもいいけれど、ゲートは安くしてはいけないので。