Vor 3 Wochen hatte ich in meinem ersten Show GN geteilt, dass ich eine 5-Tier-Firewall baue. Inzwischen gab es eine Designkorrektur + ich möchte teilen, was ich tatsächlich ausgeliefert habe. Damals mit 1 Punkt / 1 Kommentar untergegangen, aber es gibt Fortschritte, also noch einmal.
▶ Korrektur von 5-Tier → 4-Tier (PUSH / QUEUE / SILENT / AUTO)
Die "Call"-Tier habe ich herausgenommen und zurückgestellt. Entschieden wurde das auf Basis von Daten aus dem laufenden PoC.
▶ Agent-Loop end-to-end fertiggestellt
Eine Mail mit einer Meeting-Anfrage trifft ein → Tier-Klassifizierung → Klorn prüft Kalenderkonflikte → Antwort + Entwurf eines Kalendereintrags → Warten als PendingAction → Nutzer gibt per 1-Klick frei → Ausführung. Alle Aktionen werden vor der Ausführung mit einem Payload-Hash signiert; ohne passenden ActionReceipt ist keine Ausführung möglich.
▶ Der zeitaufwendigste Teil: Invariant-Test (unter 100 Zeilen Code)
Ein Test, bei dem der Build kaputtgeht, wenn eine Aktion wie send_email ohne Nutzerfreigabe ausgeführt wird. Entfernt jemand den Approval-Check → Test schlägt fehl → Build schlägt fehl → Deployment schlägt fehl. Umgehung ist damit gar keine Option. Deshalb ist "der Agent verschickt nicht eigenständig" kein Marketing-Spruch, sondern eine Tatsache.
▶ Ich habe auch einen echten Prod-Bug gefunden
OpenRouter hat die :free-Model-SKU eingestellt, wodurch alle autonomen Zyklen mit "404 No endpoints found" abgestürzt sind. Das bisherige Failover behandelte nur 402 / 403 / 429. "Modell verschwunden" war nicht abgedeckt. Ich habe eine Multi-Model-Fallback-Kette eingebaut, sodass der Agent nicht ausfällt, selbst wenn eine Upstream-SKU wegfällt.
▶ Day-14+7-Retention wird gerade gemessen
Die Aktivierung von 5 ICPs ist die Grenze für ein bestandenes PoC. Ehrliches Feedback, auch nur in einer Zeile, ist sehr willkommen.
▶ 60-Sekunden-Video: https://klorn.ai
▶ Code: https://github.com/k08200/klorn
Beta ist kostenlos + PRO wird automatisch aktiviert. Vielen Dank an alle, die beim ersten Post Feedback gegeben haben.
3 Kommentare
Eine Frage — an alle, die Agenten / SaaS betreiben: Was war der häufigste Failure Mode, den ihr gesehen habt, wenn ein Agent ohne Nutzerintention gehandelt hat?
Bei mir war die Häufigkeit im Betrieb in dieser Reihenfolge:
:free-SKU wurde eingestellt, und ohne Fallback starb auch der CycleMich würden die Muster bei anderen interessieren.
Fall 2 trat häufig auf, und als ich stattdessen auf einen Fallback umgeschaltet habe, trat je nach Prompt Fall 1 auf, woraufhin dann Fall 3 folgte, haha.
Wenn man immer ein High-End-Modell verwendet, passiert das wohl nicht, aber bei einem Service für Endkund:innen sind Modelle auf Sonnet-Niveau oder darüber hinaus natürlich ziemlich kostspielig ..
Haha, diese Reihenfolge kann ich wirklich nachvollziehen. Ich habe mir wegen #2 auch am meisten die Finger verbrannt, und wenn man auf free runtergeht, passen die Prompts nicht mehr, sodass #1 auftritt — genau das habe ich ebenfalls erlebt.
Deshalb habe ich irgendwann aufgegeben, dem Modell zu vertrauen, und stattdessen verhindert, dass das Modell entscheiden kann, ob etwas per Mail verschickt, gelöscht oder an externe Stellen weitergegeben wird — egal, ob das Modell billig oder teuer ist oder ob es eingestellt wird. Dafür ist immer menschliche Freigabe nötig. Automatisch laufen nur Dinge wie Klassifizierung, Als-gelesen-Markieren oder Briefings, also nur Sachen, die sich rückgängig machen lassen.
Seitdem ist selbst im schlimmsten Fall bei einem Model Drift nur noch „ein merkwürdiger Vorschlag, den ich sehe und ablehne“ drin und nicht „eine Antwort, die schon rausgegangen ist“. #1 zieht sich dann nicht bis zu #3 durch.
#2 fange ich ab, indem ich das tägliche Katalog-Checking auf free SKU 404 laufen lasse und mit einer Fallback-Kette umgehe; nur den Klassifikator habe ich fest auf das kostenpflichtige Flash gesetzt. Ein Sonnet-Niveau durchgehend zu nutzen, ist für mich im Kundeneinsatz auch zu teuer ... Also zahle ich nur für die Klassifizierung, lasse das Erstellen von Vorschlägen auf free und überlasse dem Freigabe-Gate das Risikomanagement.
Am Ende war der entscheidende Punkt wohl, Kosten und Sicherheit nicht auf dieselbe Achse zu legen. Das Modell darf billig sein, aber das Gate darf es nicht.