Drei Monate nach dem Launch läuft der Agent noch. Der Workflow, den er übernimmt, wird nicht mehr manuell bearbeitet. Nach jedem sichtbaren Maßstab war das Projekt erfolgreich. Dann erwähnt ein Kunde eine E-Mail, die nicht ganz stimmte. Der Agent produziert seit sechs Wochen fehlerhafte Ausgaben bei einer bestimmten Eingabekategorie — die Implementierung wurde ohne Verantwortlichen zurückgelassen, und das ist eine andere Art von Misserfolg.
Wie die ersten neunzig Tage aussehen
Die ersten drei Monate einer KI-Agenten-Implementierung haben eine konsistente Struktur. Es gibt ein klares Ziel: diesen Workflow bis zu diesem Datum zum Laufen bringen. Es gibt eine benannte Zuständigkeit: die Person, die das Projekt vorangetrieben hat. Es gibt sichtbaren Fortschritt — Aufbauten, Tests, Integrationen, die nacheinander live gehen.
Am neunzigsten Tag haben die meisten Implementierungen den Launch abgeschlossen. Der Agent läuft. Der Workflow wird nicht mehr manuell erledigt. Das Projekt ist nach jedem vernünftigen Maßstab ein Erfolg.
Was sich am Tag nach dem Launch ändert
Der Launch ist der Moment, an dem der Implementierungspartner das Projekt als abgeschlossen betrachtet. Dokumentation wird übergeben, eine abschließende Prüfung durchgeführt, und der Partner wechselt zum nächsten Engagement. Der interne Verantwortliche — die Person, die das Projekt vorangetrieben hat — kehrt zu seinen regulären Aufgaben zurück. Der Agent beginnt, selbstständig zu laufen.
Ein paar Wochen lang geht nichts schief. Der Agent übernimmt den Workflow. Die Ausgaben sehen richtig aus. Niemand schaut sich die Protokolle genau an. Das Unternehmen hat andere Prioritäten.
Die Lücke, die das erzeugt, ist nicht dramatisch. Die Lücke ist strukturell. Der Implementierungspartner ist nicht mehr verantwortlich. Der interne Verantwortliche prüft nicht nach. Niemands Aufgabe ist es, den Agenten zu überwachen.
Der Agent bricht nicht zusammen. Niemand ist dafür zuständig, ihn am Laufen zu halten.
Wie Agenten ohne aktive Verantwortung degradieren
Drift ist kein Absturz. Der Agent läuft weiter, produziert weiterhin Ausgaben, sieht weiterhin aus, als würde er funktionieren. Die Fehler sind klein und unsichtbar — bis sie es nicht mehr sind. Bis jemand bemerkt, dass der Agent fehlerhafte Ausgaben produziert, sind bereits wochenlang schlechte Ergebnisse herausgegangen.
Agenten brechen nicht auf offensichtliche Weise zusammen. Agenten degradieren graduell durch drei Fehlermuster, die schwer zu bemerken sind, bis sie eine Weile angehalten haben.
Prompt-Drift tritt auf, wenn sich das Unternehmen verändert, die Anweisungen des Agenten aber nicht. Das Team beginnt, andere Bezeichnungen für Deal-Phasen zu verwenden. Ein Produkt wird umbenannt. Ein neuer Kundentyp taucht auf, für den der Agent nicht ausgelegt war. Der Agent läuft weiter — aber die Ausgaben des Agenten spiegeln die alte Version des Unternehmens wider.
Integrations-Drift tritt auf, wenn verbundene Tools ihre APIs aktualisieren oder ihre Datenstrukturen ändern. Die Verbindung des Agenten zu diesen Tools degradiert still. Ausgaben werden nicht mehr korrekt protokolliert. Datensätze werden nicht mehr aktualisiert. Der Workflow scheint zu laufen, aber der nachgelagerte Effekt fehlt.
Randfall-Akkumulation tritt auf, wenn neue Eingaben ankommen, für die der Agent nicht gebaut wurde. Der Agent verarbeitet diese Eingaben so gut es geht — meistens falsch. Ohne jemanden, der Protokolle prüft, häufen sich diese Fälle unbemerkt an.
Was aktive Verantwortung tatsächlich erfordert
Einen Agenten zu betreiben ist nicht dasselbe wie ihn zu deployen. Ein Agent in der Produktion braucht regelmäßige Aufmerksamkeit: Protokollprüfungen, um Fehlausgaben zu erkennen, Prompt-Aktualisierungen, wenn sich das Unternehmen verändert, Integrationsprüfungen nach Updates verbundener Tools und einen definierten Prozess für Ausnahmen außerhalb des Agentendesigns.
Für die meisten Implementierungen eines einzelnen Workflows sind das ein paar Stunden pro Monat — keine Vollzeitstelle. Das Problem ist nicht das Aufgabenvolumen. Das Problem ist, dass niemand die Aufgabe besitzt. Wenige Stunden undefinierter Verantwortung sind dasselbe wie null Stunden.
Wie man die Klippe vor dem Launch verhindert
Die Neunzig-Tage-Klippe lässt sich verhindern, aber nur vor dem Launch. Nach dem Start der Implementierung wirkt das Zuweisen von Verantwortung wie das Hinzufügen einer Aufgabe, um die niemand gebeten hat. Vor dem Launch ist das Zuweisen von Verantwortung Teil des Plans.
Zwei Entscheidungen verhindern die Klippe. Benennen Sie den Verantwortlichen vor dem Launch — nicht "das Team", sondern eine konkrete Person, deren Aufgaben die Überprüfung der Agentenleistung und die Aktualisierung des Agentenverhaltens bei Unternehmensveränderungen einschließen. Definieren Sie den Überprüfungsrhythmus: einen konkreten Zeitplan — monatlich reicht für die meisten Implementierungen — um Protokolle durchzugehen, den Integrationsstatus zu prüfen und alles zu kennzeichnen, das Anpassungen braucht.
Beide Entscheidungen brauchen zehn Minuten. Keine davon erfolgt automatisch nach dem Launch.