Ihr KI-Workflow läuft gerade.
Sie wissen nur nicht, dass er vor drei Tagen aufgehört hat zu funktionieren.
Er feuert immer noch. Verbrennt immer noch API-Guthaben. Sendet immer noch Ausgaben, die niemand liest. Der Agent, den Sie zwei Wochenenden lang gebaut haben, produziert Müll zu 0,40 $ pro Müllhaufen – und Sie werden es erst erfahren, wenn ein Kunde einen Screenshot macht und Ihnen dienstags schickt.
Das ist kein Pech. Das ist der Standardfall.
Speichern Sie das. Sie werden es zweimal lesen.
Der 30-Tage-Friedhof
Jede Woche bauen hunderte Gründer KI-Workflows und posten sie auf Twitter.
Die Demo sieht sauber aus. Der Thread bekommt Likes. Die Antworten sagen: »Das ist die Zukunft.«
Dreißig Tage später ist der Workflow tot.
Nicht gelöscht. Nicht ersetzt. Tot und läuft immer noch. Belastet die Karte. Produziert nichts Nützliches. Der Gründer ist weitergezogen. Der Agent hat die Nachricht nicht bekommen.
90 % der heute erstellten KI-Workflows überleben ihren ersten Monat in der Produktion nicht. Nicht, weil die Modelle schlecht sind. Nicht, weil die Ideen falsch sind. Sondern weil die Entwickler drei Fehler gemacht haben, die das Scheitern garantieren – und niemand hat ihnen vor dem Start gesagt, welche Fehler das sind.
Das ist dieser Artikel.
Warum sie sterben
So sieht die Anatomie eines Workflow-Todes aus. Es ist immer die gleiche Abfolge.
Tag 1: Sie bauen ihn. Er funktioniert perfekt in der Demo. Sie haben das Gefühl, etwas entdeckt zu haben.
Tag 3: Er funktioniert immer noch. Sie überprüfen ihn nicht mehr so genau.
Tag 9: Etwas ändert sich. Ein API-Antwortformat verschiebt sich leicht. Eine Quelle, die er gelesen hat, verschwindet hinter einer Login-Wand. Das Modell interpretiert einen Randfall anders als am ersten Tag. Die Ausgabe verschlechtert sich leise. Niemand bemerkt es.
Tag 14: Der Workflow produziert jetzt eine Ausgabe, die technisch gesehen eine Antwort ist, aber inhaltlich nutzlos. Er läuft immer noch. Sie zahlen immer noch dafür.
Tag 23: Ein Kunde oder ein Kollege erwähnt, dass etwas nicht stimmt. Sie untersuchen es. Sie finden 12 Tage kaputter Ausgaben, von denen Sie dachten, sie würden bearbeitet.
Tag 30: Sie töten ihn. Sie sagen sich, KI sei noch nicht bereit. Sie ziehen weiter.
Das Modell hat Sie nicht im Stich gelassen. Der Build hat das Modell im Stich gelassen.
Die 3 Regeln, die die 10 % vom Rest trennen
Die Gründer, deren Workflows 30 Tage, 90 Tage, ein Jahr überleben – sie sind nicht schlauer. Sie haben keine besseren Prompts. Sie bauen mit drei Regeln, die alle anderen ignorieren.
Regel 1 – Keine Stellenbeschreibung, kein Agent
Die meisten Leute bauen Agenten mit einem Bauchgefühl.
»Hilf mir bei Inhalten.« »Beobachte Wettbewerber.« »Bearbeite Kunden-E-Mails.«
Das ist keine Stellenbeschreibung. Das ist ein Wunsch. Und Wünsche überleben das Wochenende nicht.
Eine Stellenbeschreibung hat fünf Teile:
- Was er beobachtet. Der spezifische Auslöser oder Zeitplan. »Jeden Montag um 7 Uhr« oder »jedes Mal, wenn ein neues GitHub-Issue mit dem Label ›Bug‹ geöffnet wird« oder »jedes Mal, wenn eine E-Mail von einer Domain ankommt, die nicht in meiner Kontaktliste ist«. Nicht »manchmal« oder »wenn relevant«.
- Was er liest. Die genauen Quellen. Nicht »das Internet durchsuchen«. »Aus diesen drei RSS-Feeds, dieser Airtable-Basis und den letzten 7 Tagen dieses Slack-Kanals holen.« Spezifisch. Begrenzt. Keine Mehrdeutigkeit.
- Was er produziert. Das genaue Ausgabeformat. Nicht »eine Zusammenfassung«. »Ein dreiteiliges Briefing: Haupterkenntnis in einem Satz, drei unterstützende Aufzählungspunkte mit je einer Quelle, eine empfohlene Aktion. Unter 300 Wörtern. In diesem Google Doc.«
- Was er nicht tut. Die Schutzschienen. »Nie eine externe E-Mail ohne menschliche Freigabe senden.« »Nie die Produktionsdatenbank ändern.« »Nie direkt posten. Immer als Entwurf speichern.« Die Dinge, die Sie als offensichtlich annehmen, sind die Dinge, die Sie verbrennen werden.
- Woran Sie erkennen, dass es funktioniert hat. Die Erfolgsbedingung. »Wenn das Briefing leer ist, sende mir eine Slack-Nachricht mit dem Hinweis, dass keine relevanten Aktualisierungen gefunden wurden. Sende kein leeres Briefing.«
Bauchgefühle überleben das Wochenende nicht. Stellenbeschreibungen schon.
Jeder Workflow, den Sie von heute an bauen, beginnt mit einer Stellenbeschreibung. Kein Prompt. Eine Stellenbeschreibung.
Regel 2 – Stille Fehler sind die einzigen Fehler, die dich umbringen
Laute Fehler sind in Ordnung. Laute Fehler senden einen Fehler. Sie stoppen den Workflow. Sie wecken Sie auf. Sie beheben sie.
Stille Fehler sind es, die Unternehmen ruinieren.
Ein stiller Fehler sieht aus wie Erfolg. Der Workflow läuft. Die Ausgabe kommt an. Das Format ist korrekt. Der Inhalt ist falsch – leicht, dann mehr, dann komplett – und weil es richtig aussieht, überprüft es niemand.
So funktioniert stilles Scheitern in der Praxis:
Ihr Content-Agent schreibt 30 Beiträge. Sie haben ihn so eingerichtet, dass er diejenigen automatisch plant, die in Ihrer internen Bewertung über 80 Punkte erzielen. Die Bewertung wurde an Ihren ersten 20 Beiträgen kalibriert. Am Tag 15 beginnt das Modell, Ihre Bewertung anders zu interpretieren. Beiträge, die 82 Punkte erreichen, sind nach Ihrem wahren Standard mittelmäßig. Sie werden trotzdem veröffentlicht. Ihre Engagement-Rate sinkt. Sie geben dem Algorithmus die Schuld.
Ihr Recherche-Agent sendet ein wöchentliches Briefing. Am Tag 11 ändert eine der von ihm gelesenen Quellen ihre URL-Struktur. Der Agent kann sie nicht abrufen – still. Er füllt die Lücke mit älteren zwischengespeicherten Daten und markiert die Lücke nicht. Sie lesen ein auf veralteten Informationen basierendes Briefing und treffen eine Entscheidung darauf.
Ihr Posteingangs-Triage-Agent entwirft Antworten. Am Tag 8 beginnt er, eine bestimmte E-Mail-Art als niedrige Priorität einzustufen, weil der Name des Absenders einem Muster in seinem Training entspricht. Sie verpassen drei wichtige E-Mails von einem neuen Kunden, der zufällig denselben Nachnamen wie ein Newsletter hat, den Sie nie lesen.
In jedem Fall: Der Workflow lief. Es wurde kein Fehler geworfen. Sie haben trotzdem verloren.
Die Lösung ist die obligatorische Ausgabeprüfung. Jeder Agent braucht drei Dinge:
- Eine Kanarienausgabe. Ein Feld in jeder Ausgabe, das einfach zu überprüfen und schwer zu fälschen ist. Ein Zeitstempel der zuletzt gelesenen Quelle. Eine Anzahl der verarbeiteten Elemente. Ein Konfidenzscore. Etwas, das Sie in zwei Sekunden überfliegen können und wissen, dass der Agent tatsächlich gearbeitet hat.
- Ein Alarm für stille Fehler. Wenn der Agent nichts produziert oder etwas unter einer Schwelle produziert, sendet er keine leere Ausgabe. Er sendet Ihnen einen Alarm. »Keine Ergebnisse in diesem Zyklus gefunden – hier ist, was ich geprüft habe und warum ich möglicherweise nichts gefunden habe.« Nichts ist immer nützlicher als ein überzeugendes leeres Ergebnis.
- Eine wöchentliche Stichprobe. Wählen Sie eine Ausgabe pro Woche pro Agent aus. Lesen Sie sie vollständig. Vergleichen Sie sie mit dem, was Sie selbst geschrieben hätten. Das dauert vier Minuten. Es erfasst Drift, bevor Drift zum Scheitern wird.
Agenten scheitern nicht laut. Bauen Sie für die leisen Pannen.
Regel 3 – Ihr Laptop ist keine Infrastruktur
Hier sterben 90 % der Entwickler.
Sie bauen lokal. Die Demo funktioniert. Sie veröffentlichen den Twitter-Thread. Jemand fragt, ob es in Produktion läuft. Sie sagen ja. Was sie meinen: Es läuft auf ihrem MacBook, das gerade geöffnet ist, auf ihrem Schreibtisch, in ihrer Wohnung, mit ihrem Heim-WiFi verbunden, und wird aufhören zu funktionieren, wenn sie den Deckel schließen, um am Donnerstag zum Flughafen zu fahren.
Ihr Laptop ist keine Infrastruktur. Es ist eine Entwicklungsumgebung, die gerade etwas Wichtiges ausführt.
Hier ist, was mit Laptop-gehosteten Agenten passiert:
macOS schiebt um 4 Uhr morgens ein Update. Der Rechner startet neu. Der Agent stoppt. Niemand weiß es bis Montag.
Sie schließen den Deckel auf einem Flug. Sechs Stunden verpasste Workflows. Der Posteingangs-Triage-Agent hat nicht triagiert. Der Bug-Jäger hat nicht gejagt. Der Standup-Agent hat nichts gesendet.
Ihr Heim-WiFi fällt für zwanzig Minuten aus. Der Agent wiederholt es. Scheitert. Macht weiter. Protokolliert nichts. Das Fenster, das er erfassen sollte, ist weg.
Sie fahren in den Urlaub. Der Laptop bleibt zu Hause. Alles bleibt mit ihm zu Hause.
Echte Infrastruktur läuft, wenn Sie nicht zuschauen. Sie läuft, wenn Sie schlafen, im Flugzeug sind, beim Abendessen, ein Wochenende lang nicht erreichbar. Sie braucht nicht, dass Sie den Deckel offen halten.
Die Regel ist einfach: Wenn der Workflow mehr als einmal laufen muss und Sie es sich nicht leisten können, dass er einen Zyklus verpasst, lebt er nicht auf Ihrem Laptop.
Die drei Infrastrukturoptionen, die tatsächlich funktionieren:
- Ein VPS mit einem Prozessmanager. Ein Server für 12 $/Monat mit PM2 oder Supervisor. Ihr Agent läuft als verwalteter Prozess. Wenn er abstürzt, startet PM2 ihn automatisch neu. Wenn der Server neu startet, startet PM2 ihn beim Booten. Günstig. Zuverlässig. Nicht glamourös. Funktioniert.
- Eine verwaltete Agentenplattform. Speziell dafür gebaut. Kümmert sich um Neustarts, Überwachung, Alarmierung. Kostet mehr als ein VPS. Spart Ihnen die Wochenenden, die Sie damit verbringen würden, herauszufinden, warum der Prozess gestorben ist. Lohnenswert, sobald Ihre Agenten echten Wert generieren.
- Serverless mit einem Planer. AWS Lambda oder Google Cloud Functions, ausgelöst durch EventBridge oder Cloud Scheduler. Keine zu verwaltende Infrastruktur. Sie zahlen pro Ausführung. Skaliert auf Null, wenn nicht in Betrieb. Beste Option für Agenten, die nach einem festen Zeitplan und nicht kontinuierlich laufen.
Keine dieser Optionen ist kompliziert. Alle erfordern fünfzehn Minuten Einrichtung. Jede einzelne wird Sie vor dem macOS-Update um 4 Uhr morgens bewahren, das Ihre Agenten und Ihren Montagmorgen tötet.
Schließen Sie den Laptop. Die Agenten sollten weiterlaufen.
Der Workflow, der überlebt
So sieht ein 90-Tage-Workflow aus, wenn alle drei Regeln angewendet werden.
Die Stellenbeschreibung: Jeden Montag um 7 Uhr die letzten 7 Tage Beiträge von diesen 5 Wettbewerberkonten und diesen 3 Branchen-Newslettern lesen. Alle Produktankündigungen, Preisänderungen oder Inhalte mit mehr als 500 Interaktionen extrahieren. Mit dem Briefing der letzten Woche vergleichen. Alles Neue markieren. Ein dreiteiliges Briefing ausgeben: Was sich geändert hat, was an Zugkraft gewinnt, welche Lücke sie offen gelassen haben. Wenn keine Änderungen gefunden wurden, Alarm senden: »Ruhige Woche – hier ist, was geprüft wurde.« An diese Notion-Seite liefern und eine Slack-Benachrichtigung senden.
Die Kanarienausgabe: Jedes Briefing enthält: »Geprüfte Quellen: 8. Verarbeitete Elemente: [N]. Zeitstempel des neuesten Elements: [Zeitstempel].« Wenn N Null ist oder der Zeitstempel älter als 8 Tage ist, sendet es einen Alarm anstelle eines Briefings.
Die Infrastruktur: Läuft auf einem 12 $-VPS. PM2 verwaltet den Prozess. Wenn er abstürzt, startet er in 30 Sekunden neu. Eine wöchentliche Log-Überprüfung dauert 3 Minuten jeden Freitag.
Die Stichprobe: Jeden Freitag wird ein Briefing vollständig gelesen. Dauert 4 Minuten. Hat in sechs Monaten zweimal Drift erfasst.
Dieser Workflow läuft seit sechs Monaten. Er hat zwei Zyklen verpasst – beide Male hat er einen Alarm gesendet, der erklärt, warum. Er hat nie still versagt.
Das ist der Unterschied zwischen einem Workflow, der überlebt, und einem, der am neunten Tag stirbt.
Die unangenehme Wahrheit
Die meisten Leute werden dies lesen, nicken und ihren nächsten Agenten auf dieselbe Weise bauen wie den letzten.
Ein Prompt. Eine Demo. Ein Twitter-Thread. Dreißig Tage Stille. Ein toter Workflow, den niemand offiziell getötet hat.
Die drei Regeln sind nicht kompliziert. Eine Stellenbeschreibung zu schreiben dauert zwanzig Minuten. Die Ausgabeprüfung dauert ein Feld und eine Bedingung. Die Infrastruktur einzurichten dauert fünfzehn Minuten.
Die Lücke ist nicht das Wissen. Die Lücke ist, ob Sie es tun, bevor Sie ausliefern, oder nachdem der Workflow versagt hat.
Jeder Agent, den Sie ohne Stellenbeschreibung bauen, ist ein Agent, den Sie neu bauen werden. Jeder Agent ohne Ausgabeprüfung ist ein Agent, der still versagen wird. Jeder Agent auf Ihrem Laptop ist ein Agent, der stirbt, wenn Sie das nächste Mal den Deckel schließen.
Bauen Sie sie einmal richtig. Sie laufen für immer.
Folgen Sie @sairahul1 für weitere vollständige Playbooks zum Bau von KI-Workflows, die den Kontakt mit der realen Welt überleben.
TL;DR
90 % der KI-Workflows sterben innerhalb von 30 Tagen. Immer die gleichen drei Gründe.
Regel 1 – Keine Stellenbeschreibung, kein Agent. Bauchgefühle überleben das Wochenende nicht. Definieren Sie, was er beobachtet, liest, produziert, vermeidet und woran Sie erkennen, dass es funktioniert hat. Bevor Sie auch nur einen Prompt schreiben.
Regel 2 – Stille Fehler sind die einzigen Fehler, die dich umbringen. Laute Fehler sind in Ordnung. Stille Fehler sehen wie Erfolg aus, bis ein Kunde sie findet. Bauen Sie eine Kanarienausgabe, einen Alarm für stille Fehler und eine wöchentliche Stichprobe in jeden Agenten ein.
Regel 3 – Ihr Laptop ist keine Infrastruktur. Er läuft, wenn der Deckel offen ist. Echte Agenten laufen, wenn Sie schlafen, im Flugzeug sind, ein Wochenende lang nicht erreichbar. VPS, verwaltete Plattform oder Serverless. Wählen Sie eine. Richten Sie sie ein, bevor Sie ausliefern.
Die Agenten, die überleben, sind nicht schlauer. Sie sind richtig gebaut.
